WPVibe – WordPress MCP Server. Connect Claude, ChatGPT & Any AI Agent via MCP

Changelog

1.17.4

• Fix: the site information request no longer fails with a server error on sites where WordPress has not loaded its plugin helpers for REST requests (seen on WordPress 6.4). Approvals on those sites could not complete because WPVibe could not read the plugin version.
• Fix: when a draft theme has been activated as the live theme, the draft conflict message now says so, names both themes, and explains how to recover, instead of telling you to continue editing a draft that WPVibe will not touch.
• Improvement: the connection check message for a password gate in front of WordPress (staging protection or HTTP Basic Auth) now tells you to let the WPVibe relay IP address through the gate and links to where that address is listed.

1.17.3

• Fix: Administrator accounts can read and edit protected (underscore-prefixed) meta through content edit and content search, matching what the CLI already allowed. Keys a plugin guards with its own auth callback stay refused, with a message that names the owning plugin’s path.
• Fix: updating WPVibe from within WPVibe no longer fails with an undefined function on sites where the automatic updater runs outside wp-admin.
• Fix: a staging or cloned site no longer displays the production site’s verified connection status; saved connection observations are tied to the site address.
• Fix: saving through Bricks, Breakdance, Elementor and Beaver Builder keeps a page template the active theme no longer offers instead of resetting it to default.
• Fix: a draft theme copy that fails partway is cleaned up, and a leftover draft directory that is an unmodified partial copy is removed automatically; anything else is named so it can be removed by hand.
• Hardening: search-replace refuses to rename an option into or out of a protected name, or to a non-ASCII name. Background operation records are signed and any record not written by WPVibe on this site never runs.

1.17.2

• Fix: Signed operation approvals recover from stale per-site proof keys after updating, without reconnecting the site.
• Fix: creating a classic theme preserves existing unpublished drafts and refuses conflicting files instead of replacing them.
• Fix: interrupted draft creation cannot overwrite leftover draft files on retry. Failed deletion retains the draft record for recovery.
• Fix: publishing a new classic theme keeps its name and accurately reports whether a previous theme was backed up. Apostrophes in new theme names no longer break generated PHP.
• Hardening: draft creation, editing, publishing and deletion coordinate their file changes. Unsafe paths and drafts manually activated as the live theme are refused.
• Hardening: authenticated safety checks let WPVibe verify draft-preservation support before enabling new classic-theme creation.

1.17.1

• Fix: saving Elementor data into an existing draft page or template no longer publishes it. The post keeps its status unless you ask for a change.
• Fix: Allow for WPVibe now applies to the Approve click itself. Sites where a security plugin turns off Application Passwords passed the connectivity check but still refused the approval; both now agree.
• Fix: WP-CLI commands that spell an apostrophe inside a single-quoted value the POSIX way (closing quote, backslash apostrophe, reopening quote) now reach the handler byte for byte, and post meta values keep their backslashes. Shortcode values written that way lost their quotes. Two backslashes outside quotes now collapse to one, as in a shell.
• Security: the background-run and self-update hand-off records can no longer be written with option add, option update, option patch, or raw SQL sent by an AI, so a seeded record cannot start a run through the public loopback route. Reading them for status still works.
• Fix: editing a page whose saved template no longer exists (theme switched, builder canvas template with the builder off) failed with “Invalid page template” and a misleading crash hint. Content edits and post updates now leave the stored template alone.
• Security: wp-content diagnostic reads redact the connection proof key and bare 64-character hex secrets that a failed database write can leave in debug.log.
• Hardening: the Allow for WPVibe setting can no longer be changed through WP-CLI commands sent by an AI; only the button on the WPVibe page changes it.

1.17.0

• New: Four-step setup page. Add WPVibe to your AI, connect the site with one prompt, and confirm with a read. Steps turn green on their own as WordPress approves and your AI reads the site.
• New: Check site connectivity tests the site from inside and out before you open your AI: HTTPS, Application Passwords, a staging password gate or REST-blocking plugin, a maintenance page answering the API, a host that strips the Authorization header, and WPVibe reaching the site. Failures name the cause and the fix; the report carries the exact Cloudflare rule when a firewall is challenging WPVibe.
• New: Allow for WPVibe permits Application Passwords for WPVibe requests only when a security plugin turns them off site-wide.
• New: A signed confirmation when your AI completes its first read, plus a copyable report for support.
• New: Administrators can read wp-content files for diagnostics (read-only, secrets redacted, audited); wp-content writes remain blocked.
• New: The dashboard widget shows the same connection status as the setup page, with a Check connection link.
• New: The setup page says when the site address is http:// and WPVibe needs https://, and links to Security and the DPA in the footer.
• Change: Sites already connected read as connected from their recent activity after updating. Nothing to redo.
• Fix: The approval page explains when this WordPress account cannot create Application Passwords, or has them disabled, instead of a generic error.
• Fix: Check site connectivity runs when wp-admin is open at a different address than the site URL, such as with or without www.
• Fix: live reload polling is bounded with timeout and backoff and stops after repeated failures instead of polling forever.
• Hardening: reconnecting keeps the existing Application Password until the replacement verifies; the browser-approved credential can seed the proof key only once.
• Fix: proof key provisioning, reset and rotation work on SQLite-backed sites (WordPress Studio, Playground, the SQLite integration plugin).

1.16.5

• Fix: publishing Tailwind themes now collects source files in one request, reducing host rate-limit errors on themes with many templates.
• Hardening: publishing stops if source files cannot be collected completely or if the draft changes during preparation, preventing incomplete or stale compiled styles from going live.

1.16.4

• Fix: approved long-running commands (a live search-replace, mutating db query) no longer depend on WP-Cron to run in the background. On some hosts WP-Cron never fires, so from 1.16.0 to 1.16.3 those commands could sit for 30 minutes and then report an unknown outcome without ever running. The request now answers immediately and keeps running the command in the same PHP process after releasing the connection (PHP-FPM and LiteSpeed); where PHP cannot release a connection early, the site hands the job to itself over a one-time token, and where it cannot reach itself either, the command simply runs inline. Jobs that an earlier version left queued for WP-Cron are expired if that cron ever fires, never run late.
• Fix: a fatal error during a background run (memory, an engine time limit that could not be lifted) is now recorded in the operation receipt instead of leaving it open.
• Fix: plugin update vibe-ai (WPVibe updating itself) uses the same hand-off and no longer depends on WP-Cron either.

1.16.3

• Fix: sites on XSERVER with the WAF “Command” rule enabled can connect again. That rule blocks any URL containing “ping”, which was the name of the route WPVibe checks before connecting. The check now also answers at /wpvibe/v1/health, and the plugin’s own self-update loopback moved off that word too. The /ping route stays for older connections.

1.16.2

• Fix: on sites that lock the file editor (DISALLOW_FILE_EDIT or DISALLOW_FILE_MODS), the read-only theme tools work again: listing files, reading a file, previews, and page HTML. Reads come from the draft theme when one exists and otherwise from the active theme, so a site can be inspected before an edit is proposed. Writes and draft creation stay locked.
• Improvement: the reminder that deactivating or deleting WPVibe does not disconnect the site has moved off the Plugins screen and onto the WPVibe settings page, shown once the site is connected. The confirm on Deactivate stays.
• Hardening: once a site has a proof key, the routes that require one refuse a request without it instead of falling back to plain authentication, including the window between a reconnect and the first signed call.
• Hardening: after a reconnect, only the application password that reconnect created can register the next proof key, so a credential entered by hand cannot seed one.
• Hardening: the proof-key options are blocked from option get, option update, and option delete.

1.16.1

• Fix: uploading a file type WordPress does not allow (or an empty file) now says so, with the extension and where to allow it, instead of reporting a filesystem error that sent people checking folder permissions.
• Fix: reading a translated page’s HTML on a WPML site with language directories now returns that language’s page instead of the default one.
• Feature: the WPVibe row on the Plugins screen explains that deactivating or deleting the plugin does not disconnect the site or revoke its application password, with links to do both, and a confirm on Deactivate says the same before the plugin’s code stops running.
• Fix: comment create now applies WordPress’s comment filtering for authors who lack the unfiltered_html capability (non-super-admins on multisite, sites with DISALLOW_UNFILTERED_HTML), matching what core does for those users.

1.16.0

• Feature: WPVibe can now update itself through your AI assistant. plugin update vibe-ai schedules the update to run out-of-band (the same model WordPress core uses), so the connection serving the request is never the one replacing the plugin’s files. Where available, WordPress’s automatic updater runs it, with its post-update fatal check and rollback for active plugins. Progress and the outcome are recorded in a status option your AI can read back.
• Feature: plugin auto-updates enable|disable|status commands, matching real WP-CLI behavior, so your AI can enroll any plugin (including WPVibe) in WordPress auto-updates. Also fixes auto-update enrollment on multisite, where the setting lives in a network option.
• Feature: theme update --all with --exclude and --dry-run, and multiple theme slugs in one command, matching the plugin update family.
• Feature: --expect-version on plugin update and theme update (a WPVibe extension): the update refuses if the available version is not the one you named, closing the race where a newer release lands between review and execution.
• Fix: publishing a draft theme whose functions.php fatals now rolls back to the theme the site was actually running, and only ever activates a theme that is really installed, instead of leaving the site pointed at a directory that no longer exists.
• Fix: raw SQL that writes to a protected identity table (users, usermeta, blocked options), including through a JOIN from another table, is now refused when submitted instead of after a human approves it, and the refusal names the protected table.
• Fix: theme install --version=<version> now installs the version you asked for. The themes API ignores a version argument, so the flag was silently dropped and the latest release was installed instead; an unavailable version is refused by name.
• Feature: comment moderation from your AI assistant: comment create (replies via --comment_parent), comment approve, unapprove, spam, unspam, trash, untrash, and comment delete. Deleting without --force moves comments to the trash; --force permanently deletes and pauses for approval. comment list gains --format=ids|count, --orderby, --order, --offset, and --comment__in.
• Feature: approved long-running commands (a live search-replace, mutating db query) can run in the background: the request answers immediately, a one-shot WP-Cron job (or a token-authenticated loopback when cron is disabled) runs the command as the approving user, and the outcome is recorded in the operation receipt your AI polls. No more connection timeouts on big search-replace runs.
• Feature: post list and user list accept --paged=<n> / --offset=<n> so large sites can be enumerated page by page; the truncation notice names the next page.
• Security: the approval-only routes (cli/run-approved, code-snippet) now verify a per-operation proof signed by WPVibe with a key provisioned per site, so an approved operation can only be executed by the approval flow that showed it to you, never by a request that merely holds the application password. Sites without a key keep working as before until WPVibe provisions one.
• Fix: operation receipts now accept the fleet runner’s operation ids, so background jobs can recover the outcome of a call that timed out mid-flight instead of re-probing.
• Feature: core update and core update-db. Updating WordPress core pauses for browser approval and shows the exact version change; the approval is re-verified against the site at execution, and a leftover .maintenance file is cleaned up so a failed update cannot strand the site.
• Fix: when a security plugin filters WordPress core update data, core check-update and core update now say so instead of reporting “no update available” as a certainty.
• Fix: Elementor pages saved through WPVibe are verified after the save. If Elementor stored the layout empty, WPVibe writes the requested structure directly, removes the empty autosave the editor would otherwise open, and never reports success on a page that is still empty.
• Fix: a content edit whose old text differs from the stored value only by whitespace now applies when it is the one unambiguous match, and a miss says what was tried instead of a bare “not found”.
• Hardening: PHP file writes are refused when they would redeclare a function or class the running site already has, and publishing a draft theme renders the front page afterwards and rolls back to the backup on a fatal, keeping the draft for editing.
• Fix: the Approve click on the connection screen now creates the application password through WPVibe’s own route with your logged-in session, so hosts that block the core users endpoint as “user enumeration” no longer stop the one-click connect.
• Fix: when the connection check fails, the connected page now says what actually came back (a firewall page, a redirect, a server error) and what to do about it, instead of one generic message.

1.15.5

• Fix: when WordPress rejects the application password it created seconds earlier, the plugin now reports whether that user has any application passwords stored at all, plus the install facts that explain a lost one (persistent object cache, shared user tables, wp-content drop-ins). WPVibe uses this to say “your site did not keep the password” instead of blaming the host for stripping the Authorization header.
• Fix: the Approve page no longer leaves an empty red bar when the site’s REST API answers with a firewall page or nothing at all. It now says what came back (status, page vs JSON, the security vendor if recognisable), the two fixes, and where to get help, and warns before you click when the same request is already blocked. Advisory only; the Approve form is never changed. Disable with the WPVIBE_DISABLE_AUTHORIZE_NOTICE constant or the wpvibe_authorize_notice filter.

1.15.4

• Fix: sites running WPCode with Error Logging turned on no longer hit a “Class WPCode_File_Cache not found” fatal on WPVibe requests when a snippet emits a warning. WPCode only loads that class inside wp-admin, so WPVibe now loads it for its own requests. This restores code snippet creation and WP-CLI reads on affected sites.

1.15.3

• Fix: services that authenticate with WooCommerce REST API keys (TrackShip, Metorik, and similar) no longer receive a 401 Unknown username error on sites where another plugin resolves the user early in the request.

1.15.2

• Security: hardened the protections on WPVibe’s raw database access so a disguised query cannot slip past them. WPVibe already refuses to change your site’s core web addresses, touch the users table, read your site’s secret keys, or read and write files on the server, even on a command you approve. This release closes several ways a specially crafted query could hide those actions from the safety checks, such as using SQL comments or unusual spellings of a protected setting’s name.
• Fix: read-only database queries that use REPLACE() to count or inspect content (a common reporting pattern) are no longer refused by mistake.

1.15.1

• Hardening: your page builder’s site-wide settings and global presets (such as Divi’s design presets) now require your approval before any write, on every path including option writes and raw SQL, and the approval screen shows exactly which settings change. This closes a route where a bulk edit could overwrite a builder’s global styling and break its editor across the whole site.
• Hardening: a content edit that would corrupt a page’s block markup (leaving a block’s settings unreadable, so the block vanishes from the editor) is now refused before it saves.
• Hardening: WPVibe no longer creates a draft copy of a page builder parent theme (such as Divi or Avada), which would leave the builder unable to load. It points you to the correct path instead.
• Fix: when a builder value cannot be edited directly, the guidance now names a command that actually works instead of one that dead-ends.

1.15.0

• Feature: your AI assistant can now manage navigation menus with WP-CLI style commands (menu create; menu item add-custom, add-post, add-term, update, and delete; menu location assign), no raw database access needed.
• Feature: category and tag management commands (term create, term update, term delete). Deleting a term asks for your approval first and shows how many posts and child terms are affected.
• Feature: theme mod set for changing theme customizer values, and rewrite structure for permalink settings.
• Feature: user account commands (user create, user update, user set-role, user add-role, user remove-role) plus a full user meta family (get, list, add, update, delete).
• Security: user changes that grant or remove administrator level access, or change a password or email address, always require your approval first. WPVibe also refuses to demote your connected account or the last user holding the administrator role.
• Security: capability and session storage keys can never be written through user meta commands, closing off role changes that would bypass the permission system. Session hashes, application passwords, and plugin stored secrets (such as two factor seeds and API keys) are withheld from user command output.
• Hardening: passwords set through user commands are hidden from approval screens, logs, and analytics.

1.14.3

• Fix: page builder compatibility. The live-refresh script no longer loads inside Divi, Elementor, Beaver Builder, Bricks, or Breakdance editing sessions, where it could interrupt the builder while your AI assistant was making changes (fixes the “Edit with Divi” endless spinner).
• Hardening: approved plugin replacements re-verify the installed version and active state at execution, and refuse to run if the site changed after the approval was granted (for example an auto-update during the approval window).
• Fix: clearer guidance when eval and eval-file commands are blocked. The denial now points to the code snippet workflow instead of a dead-end help lookup.
• Hardening: the approval gate and the install handler now derive “is this replacing an existing plugin” from one shared check, so they can never disagree.

1.14.2

• Feature: plugin rollback. plugin install <slug> --version=<version> --force now replaces an installed plugin with the exact version you name, so your AI can walk a broken update back to the last working release. Replacing an existing install pauses for browser approval and shows the version change before anything runs; if the plugin was active it stays active afterward.
• Fix: plugin install on an already-installed plugin now explains the two ways forward (update, or force-replace with a specific version) instead of failing with a raw folder error, and unsupported install flags are refused with the supported list instead of being silently ignored.
• Fix: a version that does not exist on WordPress.org is refused with a clear error instead of silently installing the latest release, and replacing a single-file plugin now switches the active copy cleanly instead of leaving the old file active.
• Hardening: the force-replace approval also covers directories WordPress can no longer read as plugins (broken installs), and WPVibe refuses to replace its own files over its own connection.

1.14.1

• Improvement: approved operations now leave an execution receipt on your site. If the connection drops right after you click Approve, WPVibe can check the receipt and tell your AI exactly what happened (it ran, it was rejected, or it never arrived) instead of reporting the outcome as unknown.
• Improvement: an approved operation can never run twice. If the same approved request is ever re-sent, the site returns the recorded result of the first run instead of executing again.

1.14.0

• Feature: Bricks support. Your AI can now build and edit Bricks pages through Bricks’ own save pipeline, with the theme’s element security checks applied and page CSS regenerated on every save (external file mode included). Layouts open in the Bricks editor exactly like hand-built pages.
• Feature: Breakdance support. Your AI can now build and edit Breakdance pages, including the blank canvas template for landing pages. Saves go through Breakdance’s own data format and refresh its CSS cache, so pages render correctly on the first load and open cleanly in the Breakdance editor. Writing a layout requires Breakdance builder access, the same permission Breakdance uses for its own editor, so connect as an administrator or a role you have granted Breakdance access.
• Fix: text values written to post fields by the AI now store exactly what was sent. Words like true or false used to be converted before saving, which could silently break theme and plugin settings that expect the literal text (found with GeneratePress page layout options). Structured JSON values are unaffected.
• Fix: sites that lock the theme and plugin file editors (a common managed-hosting setting) are now reported as locked instead of “a security plugin removed your permissions”, so your AI explains the real reason and what to do about it.
• Security: saving an Elementor or Beaver Builder page as private or scheduled now requires the same publish permission WordPress requires for publishing. Previously a user who could edit but not publish could reach those states through the builder endpoints. Publishing itself was always checked.

1.13.5

• Improvement: editing page-builder content now works through the safe content-edit path. Elementor stores a page’s text inside a protected field, so surgical text edits used to fall back to direct database writes. Those edits now go through the normal content-edit tool, which also refreshes Elementor’s cached styles so the change shows on the front end right away.
• Fix: a content edit that would have broken a builder layout’s stored data is now refused before saving, with the original left untouched, instead of writing a corrupted value.
• Fix: content search and edit now match text the way it appears on the page when the database stores HTML entities. A search for “R&D” finds stored “R&D”, and ordinary spaces match non-breaking spaces, so an AI reading rendered HTML can edit the real stored value without a no-match miss.
• Security: direct database writes to protected site settings (site address, active plugins, user roles and capabilities, the users table) are now refused even after approval. These already could not be changed through the normal commands, and raw SQL can no longer be used to get around that. Everyday content edits are unaffected.

1.13.4

• Fix: draft theme preview no longer breaks on sites running a child theme. The preview pointed WordPress at the draft for both the child theme and its parent, so the parent theme’s code never loaded and the page stopped rendering partway through. The preview now keeps the parent theme in place and layers your draft on top of it, the way WordPress expects a child theme to work. The live site was never affected. Thanks to Ryan De La Uz for the detailed report.
• Improvement: the WP-CLI command layer is reorganized under the hood so new commands can ship in smaller, safer pieces. Which commands you can run and how they behave are unchanged.

1.13.3

• Fix: updating a single plugin no longer leaves it deactivated. WordPress silently deactivates a plugin before replacing its files, and the update command did not turn it back on, so a plugin that was active before an update could end up switched off without any error. Updates now use the same method as the WordPress dashboard and the WP-CLI tool, which keeps the plugin active the whole time.
• Improvement: the update result now states whether the plugin is active or inactive after the update, verified against the site rather than assumed, so your AI assistant reports the real state instead of guessing.
• Fix: an update that failed to replace the plugin files used to report success. It now reports the failure and says the installed version is unchanged.

1.13.2

• Fix: cache purge –url=… was stripped before dispatch, so a surgical purge silently became a full cache flush. The flag now reaches the purge dispatcher for cache purge and its engine aliases; bare or empty –url errors instead of over-purging. When every detected page cache refuses a URL, the command now fails and names each engine’s reason instead of claiming there was nothing to purge.
• Fix: content search now finds text regardless of quote style. WordPress displays straight quotes as curly ones, and a search for the plain version used to come back empty even though the editing route would have matched it. That mismatch sent AI assistants hunting in the wrong place or rewriting whole posts when a one-line edit was intended. Search and edit now follow the same matching rules, so anything search returns is guaranteed to work as an edit.
• Fix: search results now say when a long line was shortened. Results were silently trimmed at 400 characters, so on long paragraphs and page builder layouts an AI could be handed a shortened snippet with no way to know text was missing. Results are now centered on the matched text and clearly flagged whenever they or their surrounding context were trimmed.
• Improvement: a failed edit now shows what is actually stored nearby. When an edit misses because the text is not quite what is stored, the error includes the closest matching passages from the real content, so the retry is informed instead of a guess. When an edit matches more than one place, the error now lists those places instead of only counting them.
• Improvement: edits now report what was actually saved. WordPress filters and security plugins can quietly alter content as it is saved. After every edit the plugin re-reads the stored value and says so when the site changed what was written, so an AI never builds its next edit on a version of the content that no longer exists.
• Improvement: theme editing denials now name their real cause. On multisite networks only network super admins can edit theme files, and some security plugins remove that ability even from administrators. In both cases the old error advised reconnecting with a more privileged account, which cannot work; the error now says which situation applies and what actually helps.

Older versions

WP.org caps the changelog at 5,000 words. For the full release history back to 1.0.0, see https://wpvibe.ai/changelog/