Changelog

Everything we ship, in one place: the WPVibe platform at mcp.wpvibe.ai and the WPVibe WordPress plugin. Platform improvements ship continuously; plugin releases are versioned below and install through normal WordPress updates.

1.21.0 — October 23, 2026

• Security: Pending plugin, theme and WordPress updates can no longer be pointed at a different download through an option change. WordPress’s update records are now read-only to your AI.
• Security: The list of user roles is now protected on every site, including sites with a custom database table prefix and every multisite subsite.
• Security: The draft theme file tools only ever work inside a draft theme WPVibe created, never in your live theme or its parent theme.
• Security: The SeedProd builder sign-in that WPVibe opens to compile your pages can no longer switch on “Dangerously bypass approvals”.
• Security: The approval preview for a database query no longer runs statements the query itself would refuse, such as file reads or queries on protected tables.
• Security: With “Allow for WPVibe” on behind a security plugin that blocks application passwords, only the WPVibe password of an account connected to WPVibe gets through. Other accounts, and the same account’s other application passwords, stay blocked.
• Fix: Draft theme editing works on Windows hosts and local Windows installs (for example Local). Reading, editing and outlining existing files no longer fail with a path error.
• Fix: Your AI can no longer delete the WordPress user WPVibe is connected as, which used to break the connection until you reconnected by hand. It is told to reconnect as another user first.
• Fix: Post meta and user meta writes follow WP-CLI’s –format option. JSON text stored by plugins such as SeedProd and Elementor stays text instead of being turned into an array, and –format=json or –format=plaintext picks either one.
• Fix: User meta saved through WPVibe keeps escaped quotes, so JSON text in user meta stays valid.
• Improvement: option pluck supports –format=json, so your AI can tell true, 1 and “1” apart. Undoing an Astra setting change uses it.

1.20.5 — October 14, 2026

• Security: User meta changes that need your approval can no longer be slipped past it with a key the database treats as the same as a protected one (for example a different letter case, an accent or a hidden character). Keys like that are refused, and a write is refused whenever WPVibe cannot confirm which stored key it would touch. Thanks to Mahesh Bohara (https://github.com/maheshbohara) for reporting it.
• Improvement: WPVibe’s own updates are safer. An update waits while WordPress is running its own background updates, a failed or rolled-back update is always reported as failed (with the reason when the site could not reach itself to check the new version), maintenance mode is cleared if an update is interrupted, and WPVibe records a note whenever it had to switch itself back on.
• Fix: Approved database writes no longer fail with “Multiple SQL statements” when a quoted value contains a semicolon, such as serialized data or CSS. Anything the check cannot read with certainty is still refused.
• Fix: When another plugin or theme crashes while WPVibe saves an edit, administrators see the PHP error with its file, line and the plugin or theme it came from, instead of WordPress’s bare “critical error”. Your AI is told to check whether the change was saved rather than send the same edit again.
• Fix: An upload your site refuses because of its file type (for example an SVG blocked by an SVG plugin) is reported as an unsupported file type with the site’s own message, not as a disk error, so your AI stops retrying it.
• Fix: Menu changes no longer fail on sites whose plugins look up the admin screen when a menu is saved (for example Ocean Extra).
• Fix: The plugin page now names the right Wordfence screen (All Options, Brute Force Protection) for the setting that turns off application passwords.
• Fix: Astra child themes are recognized in the dashboard widget and when WPVibe picks the right Astra tools.
• Improvement: When a site refuses WPVibe’s sign-in, the connection check reports a few more facts about why (whether the server passed the credentials through and whether WordPress’s application password check ran), never the credentials themselves.

1.20.4 — October 13, 2026

• Fix: When WPVibe updates itself, it stays switched on. Before, an update WPVibe ran on its own (from your AI or a fleet job) could leave the plugin deactivated until someone turned it back on. The update now runs the way WordPress’s own background updates do, so WordPress also checks the new version for errors and restores the previous one if it would break the site.
• Improvement: Beaver Builder pages save on Beaver Builder versions before 2.6. When a save hits a PHP error, administrators see the error with its file and line, and a page the failed save created is removed.
• Feature: Bricks header and footer templates built through WPVibe now show on the site. Before, they were saved where Bricks does not read them.
• Improvement: Other plugins can log WPVibe’s activity: the new wpvibe_operation_executed action fires each time an approved operation runs, with the command and the preview you approved.
• Fix: WPVibe’s SeedProd-only login route no longer appears in the plugin’s route list, so AI agents stop calling it on sites without SeedProd.
• Improvement: WPVibe can turn off a WPCode snippet it created, with no approval needed, because turning it off loses nothing and you can turn it back on in WPCode. It can also delete one of its own snippets after you approve it on the approval page (or at once, if you turned on “Dangerously bypass approvals”). A deleted snippet goes to the trash in WPCode, where you can restore it. WPVibe never turns off or deletes snippets you created, and it does not delete one of its own snippets after you changed its code. Turning a snippet off also stops it running when it was moved to the trash while still on, and clears the page caches WPVibe supports.
• Fix: Draft theme previews work on sites that use the SeedProd Website Builder. Before, the preview showed the live SeedProd site instead of the draft. The preview and the publish result say that the live site keeps showing the SeedProd site until the Website Builder is turned off.
• Fix: Preview pages tell hosts, caching plugins and CDNs not to cache them, so a page cache no longer serves a stale preview after an edit.

1.20.3 — October 6, 2026

• Fix: Approved database writes that are long (over about 8 KB) and wrapped in double quotes no longer fail with a syntax error on some hosts.
• Fix: File listings with a name pattern such as *.php now find matching files in every folder, and a pattern used with a folder now matches inside that folder. Before, *.php found only top-level files, and with a folder it found nothing.
• Fix: Saved Site Editor changes on the live theme no longer override a published draft theme by default. Publishing sets aside the live theme’s saved global styles, and its saved templates and template parts that the draft also has. Set-aside changes are kept and can be brought back, and you can ask to keep them instead. Changes saved in the Site Editor during the preview now go live with the theme, unless you keep a live change with the same name. Deleting a draft sets its saved changes aside too.
• Feature: The preview and the publish result warn when the theme’s folder name belongs to a theme on WordPress.org, because a WordPress.org update could replace a custom theme. Adding “Update URI: false” to style.css stops this.

1.20.2 — October 3, 2026

• Fix: Live reload puts much less load on your server. It checks for changes every five seconds instead of every two and a half. When a check times out, every open tab of the site stops checking, so it cannot tie up the server’s PHP workers; reload the page after five minutes to turn live reload back on.
• Fix: When an approved database change fails, the Approval Log now records the error message instead of an empty result, and the change is labelled as a write.

1.20.1 — October 2, 2026

• Improvement: Claude users can add WPVibe from Claude’s connectors directory. The “Add to Claude” button on the WPVibe settings page and a new link in the dashboard widget open the listing. The server address is still there for Claude Code, Cursor and other clients.
• Hardening: Turning on white label mode always asks for approval, even when “Dangerously bypass approvals” is on. White label hides the Approval Log, so a person confirms it each time. Sites that already use white label are not affected.

1.20.0 — September 30, 2026

• Feature: Dangerously bypass approvals. A new per-site checkbox on the WPVibe settings page in wp-admin, off by default. When it’s on, WPVibe asks for no approvals on that site: deletes, SQL, WP-CLI, REST writes, abilities and fleet jobs run right away. Only a logged-in administrator can turn it on or off, from wp-admin. WPVibe’s tools can’t change it. A red banner shows on every admin page while it’s on, and turning it on or off, plus every operation that ran without approval, is recorded in the Approval Log. Code snippets are still saved disabled, so enabling one stays a click in wp-admin.
• Improvement: Fewer SQL prompts. Approving a database row change (UPDATE, INSERT, DELETE or REPLACE) can now cover the rest of your session on that site, for 30 minutes or 25 statements. Schema changes, code snippet tables, WPVibe’s own tables and WooCommerce API keys still ask every time, and remembering stays off on multisite and on databases with triggers, views, stored routines or custom database drop-ins.
• Security: Remembered SQL writes run inside a transaction, and any change to code snippet storage rolls the write back. If the database connection drops mid-write, WPVibe reports an error instead of replaying the statement.
• Security: Database reads now run inside a read-only transaction, so a query that looks like a read can never change data. Reads with unusual quoting that used to be refused now run.
• Fix: Approving a connection no longer fails on sites whose server labels REST answers as HTML. WordPress used to hand back an unreadable password, and the connect link failed with a misleading hint.
• Improvement: The Approval Log header now says it lists approved and bypassed operations.

1.19.2 — September 29, 2026

• Security: WPCode snippets and their storage (the active-snippet cache, the site-wide header and footer scripts, snippet posts) can only change through WPVibe’s code snippet flow, which saves new code disabled for you to review. Content edits and page builder saves that would reach them are refused.
• Security: Raw SQL can no longer write to the users, user meta or options tables, even with approval. WPVibe points the AI to the matching WordPress command instead, which runs WordPress’s own checks.
• Improvement: Fewer approval prompts. Clearing expired transients runs without one, and snippet saves that land disabled no longer ask, because enabling a snippet in wp-admin is the real approval.
• Improvement: A domain migration with search-replace can change the site and home addresses again after approval, with a clear warning. Other protected settings are skipped.
• Fix: WPVibe refuses to activate its own working draft of a theme, which would serve the site without its compiled styles. Uninstalling WPVibe keeps an active draft or backup theme in place.
• Fix: When another plugin or theme prints warnings or errors during a WPVibe request, the response stays clean, so a command that succeeded is no longer reported as a failure.

1.19.1 — September 28, 2026

• Fix: Opening a draft theme preview can no longer crash wp-admin. On some hosts a preview could run out of memory on every admin page until the browser’s site data was cleared, and a broken draft theme could take the whole admin area down with it.
• Fix: Sites whose server garbles the standard login header now connect. WPVibe falls back to its own copy of the header when WordPress can’t read the standard one.
• Fix: Content search answers instead of refusing. Searching a field a post doesn’t have returns 0 matches, list-type fields are searched as text, and short field names like “title” and “content” work.
• Fix: Content edits inside page builder data (for example Elementor) and block settings now escape quotes and special characters safely instead of being refused.
• Improvement: WPVibe can read basic site settings such as the site address, home address, active theme and active plugins. Changing them is still blocked.
• Improvement: When a site has never saved an Application Password, WPVibe now says so, so the connection message can name the cause and offer a fresh connect link.
• Improvement: The connection check no longer claims WordPress accepted the Application Password when it only confirmed the header arrived.
• Improvement: The WPVibe admin page links to reviews on WordPress.org.

1.19.0 — September 24, 2026

• Feature: WPVibe can now add SVG images to your Media Library and write SVG files in a draft theme. Every SVG is cleaned before it is saved, including for administrators: scripts, event handlers, links to other sites, embedded web pages and styles that could load or run anything are removed. A file that cannot be cleaned safely is refused, with a suggestion to use PNG or WebP instead.
• Improvement: SVG uploads are allowed for that one file only. Your site’s own upload settings do not change, so SVG uploads in wp-admin work exactly as before.
• Improvement: SVG images added to the Media Library get their width and height from the file, so they show at the right size in the editor and as featured images.

1.18.0 — September 23, 2026

• Feature: new WP-CLI command theme mod get reads one or more theme settings by name, or all of them with –all. Settings that are not set come back empty, and values keep their stored types.
• Feature: cache purge now clears Super Page Cache (its own cache and the Cloudflare cache it manages) and Rank Math’s sitemap cache, so an updated sitemap shows right away.
• Improvement: when no supported cache plugin is found, cache purge now says a cache plugin WPVibe does not support may still hold the page, and to purge it from that plugin’s settings.
• Improvement: the connection check now spots a second login (HTTP Basic Authentication) in front of WordPress. That login makes WordPress refuse to approve the connection, so the check now tells you to turn it off before you connect, instead of showing all green and failing at the Approve step.
• Improvement: the site information WPVibe reads now includes the WordPress address, so WPVibe can warn you when a site was connected under a different address than WordPress uses. Such a connection makes signed approvals fail.
• Fix: the draft theme preview no longer changes the layout of themes WPVibe did not build, such as Astra. The preview was loading WPVibe’s own styling tools on every draft, and on WooCommerce stores they turned a 4 column product grid into a row of narrow cards. They now load only for WPVibe themes. Your live site was never affected.
• Hardening: the one-time sign-in link WPVibe uses to open the SeedProd builder can now be used exactly once, even if two requests arrive at the same moment. This holds on sites with a persistent object cache such as Redis or Memcached too. Links still expire after two minutes.
• Hardening: when a security plugin has turned off file editing, WPVibe now tells your AI to ask you before changing that setting, instead of suggesting it turn file editing back on itself.
• Fix: on Divi sites, editing a post’s text through WPVibe now also clears Divi’s saved excerpt, so category archives and the blog index show the new wording right away. Editing a Theme Builder header, footer or body layout the same way now refreshes the styles of the pages that use it, so a module newly added to the layout shows with its full styling.
• Fix: on Divi sites, pages, posts and projects that the AI updates through the WordPress REST API now get the same excerpt refresh, so category archives and the blog index show the new wording instead of an old saved copy.
• Fix: on hosts that do not allow WordPress to create PHP files (WP Engine and some other managed hosts), creating a draft theme or a classic theme now says so and that changing file permissions will not help, instead of a bare “Failed to copy file”. Other copy and write failures now include the reason PHP gave, with paths shortened to start at wp-content.
• Fix: when creating a draft theme or a classic theme fails partway, the message now says whether the partial folder was removed, and names it if it could not be.
• Fix: when WPVibe’s record of a draft theme outlives the draft folder itself (the folder was removed by hand, by the host, or by an interrupted operation), creating a draft no longer fails with a conflict that no tool could resolve. Create draft theme and delete draft theme now clear the leftover record and continue. They only do this when nothing exists at the draft folder’s path, so no files are ever deleted, and the live theme is never touched.
• Fix: when a draft folder from an earlier WPVibe draft is still on disk but its record was lost, creating a draft of the same active theme takes that folder back as the draft (no files are changed) instead of refusing. In any other case both create and delete name the folder and leave it untouched, instead of saying there is no draft.
• Improvement: previewing, publishing or editing a draft whose folder is gone now names the missing folder and the one step that recovers, instead of returning a preview link to a theme that no longer exists.
• Fix: two theme file edits sent at the same moment (for example an edit and a preview on the same draft) no longer fail with a “could not exclusively lock” conflict. The second one now waits up to 5 seconds for the first to finish, then runs.
• Fix: when WPVibe cannot lock the themes folder, the message now says why and whether retrying helps: another operation still running, no write access to the .wpvibe-draft.lock file in the themes folder, a server that does not support file locking, or a lock file replaced by a symbolic link. Each one names the lock file.
• Fix: adding an image from a URL that returns a web page (an error, login or hotlink protection page) instead of the image now says the URL did not return an image and names what it returned, such as text/html. It no longer says your site does not allow .jpg files. When the image really is a type your site does not accept, the message names that type instead of the one in the URL.
• Fix: theme mod list on a theme with no saved settings no longer returns one empty row.
• Fix: the approval error messages can now be translated.

1.17.5 — September 22, 2026

• Fix: a db query SELECT whose quoted text contains a write word (for example ‘delete’ in a value, or REPLACE(name, ‘a’, ‘update’)) no longer asks for approval and then refuses to run. A statement that starts with SELECT, SHOW, DESCRIBE or EXPLAIN SELECT is a read and runs as one.
• Hardening: a db query that calls SLEEP, BENCHMARK, GET_LOCK or RELEASE_LOCK now needs approval, and read queries stop after 30 seconds instead of holding a database connection open.
• Fix: the db query statement is sent to MySQL exactly as typed. Quote marks inside the statement are quote marks to MySQL and can no longer be turned into extra SQL.

1.17.4 — September 21, 2026

• 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 — September 18, 2026

• 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 — September 17, 2026

• 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 — September 16, 2026

• 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 — September 15, 2026

• 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 — September 9, 2026

• 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 — September 5, 2026

• 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 — September 4, 2026

• 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 — September 3, 2026

• 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 — September 2, 2026

• 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 — September 2, 2026

• 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 — August 29, 2026

• 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 — August 23, 2026

• 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 — August 18, 2026

• 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 — August 15, 2026

• 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 — August 14, 2026

• 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 — August 13, 2026

• 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 — August 11, 2026

• 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 — August 10, 2026

• 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 — August 8, 2026

• 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 — August 6, 2026

• 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 — August 5, 2026

• 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 — August 4, 2026

• 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 — July 28, 2026

• 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 — July 28, 2026

• 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.

1.13.1 — July 27, 2026

• Security: WordPress settings that WPVibe protects can no longer be changed through the content editing route. WPVibe keeps a list of settings that are never writable, including the ones controlling whether anyone can register and what role new accounts get, plus your site’s security keys and salts. The WP-CLI commands honoured that list, but the content editing route wrote settings directly and did not, so an AI acting on your site could change them without the usual approval step. That route now enforces the same list, and the security keys can no longer be read back through it either. Ordinary settings are unaffected.
• Fix: commands no longer report success for work they did not do. Some WP-CLI options were accepted and then quietly ignored, so a request could come back successful while part of what you asked for never happened, which is the one kind of failure your AI cannot notice. Those options now return a clear error naming what is unsupported. If a command you rely on has been dropping an option, you will see an error where you previously saw a false success. The error is the accurate answer, and the earlier success was not.
• Fix: search and replace can no longer damage stored passwords. The user_pass column is now always excluded, even if it is explicitly requested, so a replacement that happens to match text inside a password hash cannot corrupt it and lock someone out.
• Fix: listing a post’s custom fields now matches WP-CLI. A field with more than one stored value was folded into a single entry using field names WP-CLI does not use, so your AI could not tell how many values existed or reliably remove just one of them. Every stored row is now listed separately, using the standard post_id, meta_key and meta_value names. Nothing about how values are stored has changed.
• Improvement: two more edits that cannot be undone now ask first. Removing a key from inside a setting, and removing every stored value of a custom field when the protected-field guard is overridden, now show a preview and wait for your approval. WordPress keeps no trash for settings and no revision history for custom fields, so page builder layouts and template settings cannot be recovered afterwards. Removing one specific value still runs without a prompt, because that only affects the row you named.
• Improvement: long lists now say when they were cut short. Listing options, users, or posts stops at a row limit, and the reply had no way to signal that more existed, so an AI could work through what looked like a complete set and quietly miss the rest. Those listings now warn when the limit was reached and say not to treat the result as complete.
• Improvement: reporting options behave as WP-CLI does. –format=ids and –porcelain now return the bare values they are meant to, which makes them usable for chaining one command into the next.

1.13.0 — July 26, 2026

• Fix: WPVibe now works on hosts that strip the login header. On some servers, commonly Apache running PHP as CGI or FastCGI and some LiteSpeed setups, the web server removes the Authorization header before WordPress can read it. Every WPVibe request then arrived as a logged out visitor and failed with a permission error, even though the site was connected and the password was valid. WPVibe now sends the same credentials a second way that these servers pass through, and the plugin hands them back to WordPress before it checks who you are. Who is allowed to do what does not change, and sites that were already working are unaffected. To turn this off, define WPVIBE_DISABLE_AUTH_FALLBACK as true.
• Improvement: permission errors now name the real cause. A request WordPress could not authenticate used to report a missing capability, which sent people off to reconnect with a different account when the actual problem was the server dropping the header, or Application Passwords being switched off. WPVibe now reports which of those it was, so the fix matches the problem.

1.12.0 — July 23, 2026

• Fix: safer settings edits. Option values are now treated as plain text unless your AI explicitly asks for JSON (matching the real WP-CLI), and WPVibe refuses any write that would silently change a setting’s stored type, which could previously corrupt cache plugin settings or take a site offline. Reading an option now tells your AI when a value is one string that merely looks like a list.
• Fix: theme and code edits no longer fail on hosts whose security firewall mistakes legitimate code for an attack. Some hosting firewalls inspect the content of save requests and block anything that looks like PHP or SQL, which made edits to files like functions.php fail intermittently with a 403 error. When that happens, WPVibe now automatically resends the same edit in an encoded form the firewall does not misread, and the plugin decodes it before any of its usual security checks run. Nothing changes about what gets saved or who is allowed to save it.

1.11.0 — July 22, 2026

• New: White label mode for agencies. One click on the WPVibe admin page (or one ask to your AI) hides WPVibe everywhere in the WordPress dashboard: the admin menu, dashboard widget, Plugins list entry, and editor sidebar. The site stays fully manageable through your AI. WordPress auto-updates keep the plugin current while hidden, and if the site goes 30 days without WPVibe activity the plugin reappears on its own, so it can never be lost.
• Fix: Content edits now match straight and curly quotes interchangeably. WordPress converts quotes to the curly kind when it saves, which could make an edit fail with “no match” on text your AI had just written.
• Fix: The WPVibe theme header is now registered on every request, so site_info correctly detects AI-built themes over REST. Props to Nick Kimuli for finding it and opening the fix on our GitHub mirror.

1.10.0 — July 20, 2026

• New: Beaver Builder support. Your AI can now build and edit real Beaver Builder pages, landing pages, and layouts. The result is a native Beaver Builder layout: open it in the builder and every row, column, and module is there and individually editable, exactly as if you built it by hand. Works with both the free Beaver Builder (Lite) and the paid plugin.
• New: Beaver Themer support. Build site-wide headers and footers (navigation menus included), plus archive, 404, and single-post layouts, each wired to the right location rules. Themer headers and footers need a Themer-compatible theme (the Beaver Builder Theme, Astra, GeneratePress, Kadence, and similar); WPVibe tells you up front when the active theme cannot render one instead of leaving a layout that shows nowhere.
• New: “post meta add” appends a row to multi-value post meta, and “post meta delete” accepts an optional value to remove only the matching row. Previously update replaced every row of a key and delete wiped them all, which made multi-value metas effectively untouchable. Divi’s Theme Builder links its templates through exactly this kind of meta, so your AI can now add a second Theme Builder template without destroying the first.

1.9.1 — July 16, 2026

• Fix: uninstalling a plugin, updating a plugin, or deleting a theme through WPVibe no longer fails with a 500 error. These commands ran WordPress’s own delete and upgrade functions without first loading wp-admin’s filesystem bootstrap, which wp-admin pre-loads but WPVibe’s REST context does not. All file-modifying commands now load it up front.
• New: update several plugins at once. plugin update now accepts multiple slugs or --all (with --exclude and --dry-run), previews the full list before you confirm, and reports a per-plugin result. WPVibe itself is skipped automatically, since it cannot replace its own files over its own connection.
• Fix: Google Site Kit (and other plugins that read the logged-in user early) now see the correct user on WPVibe requests. WordPress resolves Application Password logins later than plugins that initialize on init, so Site Kit read an empty Google authorization and rejected every Analytics, Search Console, and PageSpeed request with missing_required_scopes. WPVibe now tells WordPress that REST requests are API requests from the start, so the login resolves before those plugins load.

1.9.0 — July 14, 2026

• New: WPVibe dashboard widget. Your wp-admin Dashboard now shows whether the site is connected, the last few changes your AI made, and a short list of cookbook recipes matched to the plugins you actually run, each with a copy-ready prompt. Not connected yet? The widget gives you the one-line prompt that connects your site.
• New: recipe suggestions are filtered on your own site against your installed plugins. The widget fetches one small public recipe list from wpvibe.ai (nothing about your site is sent, same pattern as the WordPress Events and News widget) and picks locally.
• Improvement: recent AI-made changes are now kept in a small activity log (last 10 entries) so the dashboard can show them; the full record remains in the Approval Log.

1.8.1 — July 13, 2026

• Fix: SeedProd landing pages now render on your site automatically after WPVibe builds or updates them. The automatic render step added in 1.8.0 only recognized SeedProd theme templates and coming-soon or maintenance pages, so regular landing pages still asked you to open the SeedProd builder and click Save yourself.

1.8.0 — July 10, 2026

• New: SeedProd pages and theme templates that WPVibe builds now render on your site automatically, without you opening each one in the SeedProd builder and clicking Save yourself. WPVibe triggers the builder’s own save step for you through a single-use sign-in link that expires in two minutes and is scoped to that one page, so nothing else on your site is exposed.
• Improvement: Elementor pages can now set their WordPress page template at save time (new page_template field on the save-page endpoint): “elementor_canvas” for standalone landing pages, “elementor_header_footer” to keep the theme’s header and footer without the page title. Previously every AI-built page rendered with the theme’s default template, which prints the raw page title above the design on most themes. Unknown template names are saved but flagged in the response warnings.
• New: Code snippets, safely. Your AI can now draft a code snippet (PHP, JavaScript, CSS, HTML, universal, or text) through the free WPCode plugin. You approve the exact code, type, and placement in your browser before anything is written, and every snippet is saved switched off: you review and enable it yourself in wp-admin, where WPCode runs its own fatal-error check. PHP snippets are also syntax-checked at write time, so a typo is caught before it ever reaches the enable switch. Requires WPCode; without it the feature says so clearly instead of failing cryptically.
• Hardening: WP-CLI commands can no longer create or edit WPCode snippet posts (including their custom fields and type/location terms). Snippet code always goes through the code approval panel, and enabling a snippet remains something only you can do.
• New: “post term set”, “post term add”, and “post term remove” assign existing taxonomy terms to a post (by slug, or by id with –by=id), including private taxonomies the REST API cannot reach. Terms are never created implicitly; a missing term is reported with how to create it first.
• New: “option pluck” reads a single nested key out of a large settings option (plugin settings arrays, JSON blobs) instead of fetching the whole option into the conversation.
• Improvement: “theme list” now reports update availability (update and update_version fields, plus –update=available), matching what plugin list has done since 1.5.2, so “any theme updates?” is one command instead of probing each theme.
• Improvement: “cache purge” now detects the official Cloudflare plugin and purges its edge cache alongside the other cache plugins, so a purge actually reaches visitors on Cloudflare-fronted sites.
• Fix: post create/update accept –post_content_base64 for content that mixes single and double quotes. The plain –post_content flag silently dropped colliding quote characters; the new flag round-trips the content byte for byte, backslashes included.
• Hardening: “db query” now rejects MySQL executable comments (/*! … */), which could hide a blocked keyword from the query validator.
• New: “cache purge –url=” purges specific pages instead of the whole cache, on every cache plugin with a URL purge API (LiteSpeed Cache, WP Rocket, W3 Total Cache, WP Super Cache, SiteGround Speed Optimizer). Plugins without one still flush fully, and the result says which happened. “–skip=” leaves named layers alone (for example Cloudflare or the object cache).
• Fix: “cache purge” no longer reports the Cloudflare cache as purged when the Cloudflare plugin’s Automatic Cache Management toggle is off. The plugin silently ignores purge requests in that state; the result now says so and points at the setting.
• Improvement: cache purges now run origin caches first and Cloudflare last, so the edge cannot re-cache stale pages mid-purge.
• Improvement: publishing a draft theme now flushes every detected cache as part of the publish itself, so visitors see the new design immediately on every cache plugin, not just the ones that react to a theme switch.
• Fix: deleting a user by email address now shows the real account details in the approval preview. Previously the preview claimed the user would not be found while the deletion itself would still proceed after approval.
• Fix: the “transient delete –all” approval preview no longer claims site transients are included; only regular transients are deleted, and the preview now says so.
• Fix: “widget list” reads sidebars through the WordPress core accessor, so sites upgraded from very old WordPress versions no longer see a bogus “array_version” row.
• Fix: search-replace always quotes primary-key values in its row queries. On plugin tables with text primary keys, numeric-looking key values could previously match the wrong row and copy one row’s content into another.
• Fix: “option list –search” and “transient list –search” treat underscores in your search text as literal characters instead of single-character wildcards, so searching blog_* no longer matches unrelated options.
• Improvement: truncated previews of long post, comment, and option values now cut cleanly on multibyte (emoji, accented, CJK) content.

1.7.1 — July 9, 2026

• Fix: CLI commands that carry punctuation inside a quoted value (a serialized setting, an SEO title with a pipe) are no longer rejected as unsafe. Quoted values are treated as data; the safety checks on command structure are unchanged.
• Fix: Publishing a draft theme now works on hosts that block deleting the live theme folder, by swapping the folders instead of deleting and recopying. If anything goes wrong mid-publish, a complete backup is kept and the message says exactly where.
• Improvement: When a draft theme action finds no draft, the message now says whether the last draft was published or deleted and when, so your AI stops trying to recreate a draft you already finished with.
• Improvement: Every error the plugin reports now includes structured facts about what went wrong (the cause, whether retrying can help, and whether the connected account is an administrator), so AI assistants stop guessing at remedies and stop repeating fixes that cannot work.
• Fix: Permission denials when creating content or editing custom fields through the CLI tools now surface as a proper permission error naming the post type and capability, instead of a quiet command failure that error tracking never recorded.

1.6.3 — July 8, 2026

• Fix: Administrators were blocked from editing content that belongs to plugins with their own permission schemes (WPForms forms, some LMS and e-commerce post types). Content search and edit now work for administrator accounts on those post types. Post types that explicitly forbid editing (such as order records) stay locked, and protected fields keep their existing safeguards.
• Fix: The error shown when an account lacks permission for a specific post now names the post and its type, and no longer suggests reconnecting when reconnecting would not help.
• Improvement: Site info now reports which WordPress account is connected and its role, so your AI assistant can spot a limited account up front instead of failing mid-task.

1.6.2 — July 8, 2026

• Improvement: The plugin now displays as WPVibe, matching the product brand at wpvibe.ai. Same plugin, nothing else changes.
• Fix: “plugin update vibe-ai” no longer tries to replace the plugin’s own files over its own connection, which failed with an unhelpful server error. It now explains that WPVibe should be updated from the wp-admin Plugins screen or via auto-updates.

1.6.1 — July 7, 2026

• Fix: “option list –autoload=on|off” returned no rows on WordPress 6.6+ (the query only matched the legacy yes/no autoload values). It now matches the current on/off/auto-on/auto-off/auto values as well.
• Fix: “option update” and “option patch” no longer report a false failure when writing a numeric or boolean value (JSON decoding produced an int/bool while WordPress stores scalars as strings; setting an option to its current value also tripped this).
• Fix: “user list” now includes user_registered, so account age is available to site-audit workflows.
• Fix: WP-CLI commands no longer have HTML tags silently stripped from their values (a value like “<b>x</b>” was stored as “x”, and script blocks vanished entirely, surfacing as a confusing usage error). Commands containing angle brackets are now rejected with a clear message pointing to the content editing tools, which handle HTML safely.
• Fix: “post list” was silently ignoring targeting flags (–s, –year, –monthnum, –author) and returning the full unfiltered list, which is dangerous when a listing feeds a bulk operation. Those filters now work, and unsupported flags are rejected with a clear message instead of ignored.
• Fix: “post create” now honors –post_date (site-local time, matching WP-CLI) instead of silently creating the post dated today.
• Fix: “post list” now accepts a comma-separated –post_type (e.g. post,page) instead of returning an empty list.
• Fix: draft themes can now be deleted on hosts that block the HTTP DELETE method at the server (a POST alias was added; previously the cancel action failed with a 405 on many hardened hosts).
• Improvement: “option get” now allows reading users_can_register and default_role (writes remain blocked). Security-audit workflows need to check whether open registration is enabled.

1.6.0 — July 2, 2026

• New: WP-CLI checksum verification. “core verify-checksums” and “plugin verify-checksums” (single plugin or –all) compare installed files against the official WordPress.org checksums and report modified or missing files, so an assistant can run a file-integrity check when investigating a possibly compromised site.
• Improvement: core verify-checksums also reports unknown files inside the core directories (the “File should not exist” check from real WP-CLI, the half that catches injected malware) and supports –include-root, –exclude, –version, and –locale. plugin verify-checksums skips readme.txt/readme.md by default (WordPress.org regenerates readmes after release) with –strict to include them, and reports files added to a plugin folder that are not part of the official release.
• New: Read-only WP-CLI commands assistants ask for most: core version, core check-update, db tables, db prefix, post-type list, menu location list, theme mod list, and plugin get.
• Feature: Unified cache purge. “cache purge” detects the installed cache plugin (LiteSpeed Cache, WP Rocket, SG Optimizer, WP Super Cache, W3 Total Cache, Breeze, plus the Elementor CSS cache) and calls each plugin’s own purge API, then flushes the object cache. The plugin-specific spellings assistants guess first (litespeed-purge, elementor flush-css, rocket clean, sg purge, super-cache flush, w3-total-cache flush, breeze purge) work as scoped aliases.
• New: “config get <constant>” reads a single configuration constant (and table_prefix) for diagnostics like WP_DEBUG or DISALLOW_FILE_EDIT. Credentials and secrets (database credentials and anything matching KEY, SALT, SECRET, PASSWORD, or TOKEN) are blocked outright, and config list/set/edit remain blocked.
• New: “option patch insert|update|delete” makes surgical changes to one key inside a nested settings array (plugin settings like Rank Math) without rewriting the whole option.
• Hardening: Deleting an option now pauses for browser approval with a preview of the stored value, since options have no trash and a plugin’s entire configuration can live in one. The AI’s own temporary options (wpvibe_task_ prefix) and transients stay approval-free, and the session-bypass checkbox covers repeated cleanup.
• Feature: Role and capability editing, the gap core REST cannot fill (the reason role-editor plugins exist): cap add/remove on roles, role create (with –clone), role delete, role reset (restore WordPress defaults), and user add-cap/remove-cap. Every change pauses for browser approval with the literal grant spelled out, administrator-equivalent capabilities are flagged in the preview, and lockout protections refuse removing core capabilities from the administrator role, deleting the administrator role, or deleting the last administrator user. role reset is the escape hatch back to WordPress defaults.
• New: “cron event run <hook>” and “cron event delete <hook>” (both approval-gated) complete the stuck-cron debugging loop alongside cron event list and cron test.
• New: “theme install”, “theme update”, and “theme delete” (delete approval-gated; refuses the active theme and the parent of an active child theme), symmetric with the existing plugin management commands.
• Feature: search-replace is now implemented (previously a stub). It performs serialized-data-aware replacements (nested arrays and objects are unserialized, replaced, and re-serialized with correct lengths, so widget settings and theme mods survive a domain migration), works table by table in primary-key chunks, skips the guid column by default (–include-guids to opt in), supports –dry-run, –skip-tables, –skip-columns, and explicit table arguments, and reports completed vs remaining tables if it hits the time budget. Live runs pause for browser approval with per-table match counts, and the preview warns loudly when the replacement would change the site URL; –dry-run runs without approval.
• New: Permission diagnostics. “cap list <role>” (with –show-grant) and “role list” let an assistant show exactly which capability a role is missing instead of hand-waving at a permission error.
• New: “maintenance-mode status” reports the effective maintenance state from all three sources: the core .maintenance file (honoring the 10-minute expiry), the wp-content/maintenance.php drop-in, and known maintenance/coming-soon plugins (SeedProd, LightStart, Under Construction, CMP, Maintenance) with their enable state.
• New: “cron test” verifies WP-Cron spawning end to end (DISABLE_WP_CRON, ALTERNATE_WP_CRON, and a live loopback spawn check), so stuck-cron debugging has a first step.
• New: Symmetric read commands: media image-size, transient get (with –network), menu item list, user get, and theme get.
• New: Command discovery. “help” returns the full supported-command catalog (name, tier, usage, approval requirements) generated from the security allowlist, and “help <command>” filters it, so an assistant discovers what is supported instead of burning calls guessing. “cli version” and “cli info” return honest emulator identity (plugin version, WordPress and PHP versions) instead of an error, so an assistant probing the environment gets accurate expectations rather than concluding WP-CLI is broken.

1.5.2 — July 1, 2026

• Fix: The WP-CLI plugin list command now reports update availability. It exposes “update” (available/none) and “update_version” fields and honors the –update=available filter, so an assistant can reliably see which plugins have updates instead of getting blank update info.
• Fix: Permission-denied errors now name the specific missing WordPress capability (e.g. “edit_theme_options”) instead of WordPress’s generic “not allowed” message, so an assistant connected with a lower-privilege account gets an actionable next step instead of a dead end.

1.5.1 — June 30, 2026

• Hardening: Image imports now pin the download to the exact IP address that passed the security check, closing a DNS-rebinding window where a hostname could switch to an internal address between validation and download.
• Hardening: Content meta edits and searches now enforce WordPress per-key meta permissions, so a user can no longer read or change protected post meta they are not authorized for, even on posts they can otherwise edit.
• Hardening: The WP-CLI post meta update and delete commands now guard every protected meta key (not just core internal keys) behind the same explicit –force override.
• Fix: Image imports no longer fail with “you are not allowed to upload this file type” when the source name has dots before the extension (e.g. macOS screenshots like “…14.45.58@2x”). The importer now derives the extension from the file’s actual type instead of trusting the parsed name.

1.5.0 — June 25, 2026

• Feature: Surgical content edits. WPVibe can now make targeted find-and-replace changes to a post’s content, excerpt, or title, to post meta, and to site options without rewriting the whole value. Two new endpoints (content search and content edit) locate the exact text first and then replace a single match (or all matches), so large posts no longer have to round-trip through the AI in full. Serialized values are refused so they cannot be corrupted.
• Feature: Bulk cleanup commands. The post update, post delete, user delete, and plugin uninstall commands now accept several targets in one call, so the AI can tidy up a batch of posts, users, or plugins in a single step.
• Feature: Approval previews now list every affected item. When an irreversible action touches more than one target (permanently deleting posts, deleting users, uninstalling plugins), the confirmation screen enumerates each one so you can review the full list before approving. Reversible actions (moving posts to trash, updating posts) continue to run without interruption.
• Hardening: Clearer database change previews. Update queries now show a sample of the rows that will change (previously only deletes did), and long values are trimmed in the preview so a wide table stays readable.
• Hardening: The approval gate for direct SQL now also covers REPLACE, CREATE, RENAME, and GRANT/REVOKE statements, so those route through the same human confirmation as other database writes.
• Fix: Frontend edit affordances now render only for registered WPVibe fields/settings, preventing accidental edit markers on unrelated template attributes.
• Fix: Classic starter theme front-page hero fields now resolve against the configured static front page, so the hover-to-edit links point to the correct page fields.
• Maintenance: Classic starter theme declares responsive-embeds support so embedded media scales correctly on mobile.

1.4.0 — June 1, 2026

• Feature: Field API for theme authors — register editable custom fields and global settings from a theme’s functions.php via wpvibe_field_register(), wpvibe_setting_register(), and wpvibe_field_group_register(). The plugin handles admin meta box rendering, save handlers, and sanitization across 12 field types (text, textarea, number, email, url, date, checkbox, color, image, gallery, wysiwyg, post_select, repeater). Templates read native get_option() / get_post_meta() so they keep rendering when the plugin is deactivated.
• Feature: “WPVibe AI” meta box on every post edit screen for themes that declare WPVibe: yes in their style.css header — surfaces registered fields for the current post type plus a “Connect Claude / ChatGPT” CTA when no MCP client is paired to the site.
• Feature: Frontend hover-to-edit affordance — registered fields render with a dashed outline + edit pin during draft preview, click to jump to the wp-admin edit screen for that field.
• Feature: Hybrid classic starter theme — Tailwind v4 (browser CDN at draft time, compiled dist/styles.css at publish) + Gutenberg color/typography integration driven by the same theme.css @theme tokens. Bundles Alpine.js v3.15.12 for interactivity (modals, dropdowns, tabs, accordions, sliders). No theme.json — single source of truth.
• Feature: Cookie-based draft preview that survives wp-admin navigation. Admins with edit_themes see the draft theme across the whole admin so the field API works in wp-admin without needing the preview-token query string on every URL.
• Feature: Elementor integration with four new REST endpoints — GET /wpvibe/v1/elementor/widgets (list installed widgets + structural elements), GET /wpvibe/v1/elementor/schema?slug= (control schema discovery for a widget or element), POST /wpvibe/v1/elementor/save-page (atomic create or update of an Elementor page), POST /wpvibe/v1/elementor/save-template (Elementor Pro theme builder templates with display conditions). All routes return 404 with elementor_inactive when Elementor isn’t installed.
• Feature: Per-request REST timing — every WPVibe REST response now carries an X-WPVibe-PHP-Time-Ms header so MCP clients can break down “why is this slow?” by Worker overhead, network round-trip, and time spent in WordPress PHP.
• Feature: Human-in-the-loop approval for destructive operations. AI-initiated db query mutations (DELETE/UPDATE/DROP/etc.), user deletes, plugin uninstalls, and --force trash bypasses now pause and surface an approval URL the user must open and confirm in their browser before WPVibe executes them.
• Feature: New WP-CLI-style commands so the AI can clean up after itself — option add, option delete, transient delete (with --all / --expired modes), and transient list. Non-blocked option/transient deletes auto-execute; protected core options (siteurl, active_plugins, auth_*, etc.) remain hard-blocked.
• Feature: Approval Log admin tab (WP admin → WPVibe → Approval Log) — append-only audit of every destructive operation WPVibe has executed on this site, including the dry-run preview the user saw before approving and the post-execution result summary.
• Feature: New /wpvibe/v1/cli/run-approved, /wpvibe/v1/audit-log, and /wpvibe/v1/registered-meta REST endpoints.
• Hardening: Destructive operations classified by command/SQL keyword rather than a default-deny allowlist. The narrow list (mutating SQL, user delete, plugin uninstall, post delete --force) returns approval_required with a row-count preview when the operation hits the database; all other commands continue to auto-execute behind the existing per-command capability checks.
• Fix: Custom post types now auto-receive the 'custom-fields' post type support when fields are registered via wpvibe_field_register() — was silently dropping meta on REST writes for CPTs that lacked it.
• Fix: First write to a new subdirectory of the draft theme (e.g. dist/styles.css) no longer fails with “Resolved path is outside the draft theme” — path-safety check walks up to the nearest existing ancestor for the realpath validation.
• Fix: publish_draft_theme now tolerates a missing live theme directory (interrupted prior publish, manual delete) and creates the live from the draft instead of fatal-ing inside RecursiveDirectoryIterator.

1.3.0

• Feature: New unauthenticated /wpvibe/v1/ping endpoint returns plugin and WordPress version so the WPVibe MCP server can detect plugin presence before generating an OAuth magic link. Cuts the “magic link works but plugin is missing” failure mode that strands users mid-onboarding.

1.2.3 — May 15, 2026

• Fix: Draft theme name no longer accumulates “(WPVibe Draft)” on every publish cycle — the suffix is now stripped on both create and publish, and the theme header cache is invalidated after restore. Thanks to J. Hoon Yu for the report.

1.2.2 — May 11, 2026

• Security: SSRF hardening on /upload-media — validate every resolved A and AAAA record against private, loopback, link-local, and reserved ranges; re-validate redirect hops
• Security: Server-side user scoping on /last-change so a lower-privilege user can’t read change summaries from an admin session
• Security: Require edit_theme_options or edit_posts in addition to the x_wpvibe header before bumping the admin “Connected” indicator
• Security: 24-hour TTL on the draft theme preview token so a leaked URL can’t be used indefinitely
• Security: Remove SVG from the file-write allowlist (SVG can embed script and isn’t needed for classic-theme scaffolding)
• Fix: Resolve an undefined variable when building the “View Trash” admin URL in the change tracker
• Maintenance: Uninstall now clears wpvibe_last_active, wpvibe_preview_token_issued, the activation-redirect transient, and any leftover *-wpvibe-draft / *-wpvibe-backup theme directories on disk
• Thanks to Rob Weaver for the responsible disclosure

1.2.1 — April 20, 2026

• Compliance: Migrate inline styles and scripts to wp_enqueue_style / wp_enqueue_script
• Compliance: Replace direct PHP file I/O with the WP_Filesystem API across theme and file operations
• Compliance: Replace exec()-based PHP syntax validation with in-process tokenizer
• Feature: Unsplash stock photo search with third-party service disclosure
• Fix: Allow SQL comparison operators in db query and honor the –limit flag; add {prefix} placeholder
• Fix: Detect an active WPVibe connection via last-active timestamp instead of the auth token
• Fix: Custom CLI command sanitizer that preserves angle brackets used by SQL queries

1.1.0

• Expanded WP-CLI dispatcher with 16 new commands (34 total)
• Security: Block sensitive options (auth keys, salts) from being read via option get
• Security: Whitelist post get return fields (excludes post_password)
• New read commands: plugin search, option list, taxonomy list, term list, post meta get, media list, comment list, comment count, sidebar list
• New write commands: post create, post update, post delete, post meta update, post meta delete
• Plugin install and update with two-phase confirmation flow
• Content truncation for large post_content and post_content_filtered fields
• Flag normalization: hyphenated flags (–per-page) auto-convert to underscored (–per_page)

1.0.0

• Initial release
• WordPress site connection with one-click authorization
• Full WordPress REST API access for AI content management
• WordPress Abilities API support (WP 6.9+)
• WordPress theme file browsing (list, search, outline)
• WordPress theme editing via draft-preview-publish workflow
• Classic WordPress theme builder
• WordPress WP-CLI native dispatch
• WordPress media uploads from URL
• Unsplash stock photo search
• Smart live reload with context-aware navigation
• Progressive skills system for guided AI WordPress workflows