Changelog

• Fixed editor iframe styling by sharing content CSS with the frontend.
• Added editing, removal, deduplication, and explicit text/block scope for CSS classes.
• Improved class suggestions, keyboard navigation, accessibility, and malformed catalog handling.
• Added theme-palette colors, contrast feedback, badge presets, and color reset.
• Added translatable UI and documented theme CSS variables.
• Corrected the minimum WordPress version to 6.6 for the generated JSX runtime.
• Added clean handling of incomplete source installations.
• Updated build tooling and added regression checks, deterministic ZIP packaging, and stable-only deployment guards.

Cache serving

Purging

YouTube previews

Administration and WP-CLI

Removed

• The page-cache drop-in never read GTPERF_SAFE_MODE, so already-cached pages kept being served with safe mode on. It now falls through to WordPress, which reports X-GT-Cache: SAFE-MODE.
• A cache hit sent only six fixed headers. CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, the cross-origin policies, X-Robots-Tag, Content-Language, and Link headers set in PHP disappeared from cached pages, including a noindex X-Robots-Tag. Capture stores an allowlist of them (at most 20 lines of 8 KB) and the drop-in replays them after re-validating each line. Pages cached before this release get their headers when they are rebuilt; purge once to refresh them all.
• Any client could send X-GT-Preload and turn every stale page into a full WordPress render. Preload requests now carry a ten-minute HMAC token derived from AUTH_KEY, which the drop-in verifies without a database.
• X-GT-Cache-Reason uses one sanitizer in the drop-in and in WordPress, so path:/cart/ no longer arrives as pathcart or path:cart.
• The edge modules load only for admin, cron, AJAX, REST, CLI, and signed-in requests, so a purge from an anonymous request (a visitor's auto-approved comment, a classic WooCommerce checkout that sells a product out) cleared the origin while Cloudflare and xCloud kept serving the old page. The plugin now loads them the moment a purge fires.
• WordPress core, plugin, and theme updates purge the cache. Translation updates and plugin installs do not.
• --page-url for cache purge|explain|verify and cloudflare purge must be on one of the site's canonical hosts. verify fetched any URL, and purges handed foreign URLs to the edge.
• In a theme with responsive embeds, a YouTube embed block showed an empty band the height of the video above the preview. Core reserves the 16:9 box with a padding ::before on the block wrapper and pins the iframe over it; the preview kept its own inline 16:9 box, so it stacked under the reserved one. Its styles now live in one stylesheet in the head, which pins the preview over the wrapper with core's own selector, and nothing is inline except the thumbnail, so a theme's embed wrapper can position it too.
• The preview shows YouTube's red play button instead of a browser-styled "Play" button, and a click anywhere on the thumbnail starts the video. Pages cached before this release keep the old preview until they are rebuilt.
• Tools → Explain this page is new: wp-admin had no view for it, and the admin-bar link opened Tools with a URL nothing read. The panel shows the decision and reason, the origin copy's state and times, the cache key, and whether Cloudflare agrees, with a link to the page in per-request safe mode. The admin-bar link now encodes the URL and jumps to the panel.
• wp gt-performance database run ignored "Scheduled revisions to retain" and deleted every revision, which is how a server cron calling it behaved. It now keeps them; --all-revisions matches the Run cleanup button.
• wp gt-performance doctor and health exit 1 when a check fails. Warnings, such as an integration that is not in use, exit 0.
• The autosave interval setting never took effect: WordPress defines AUTOSAVE_INTERVAL right after plugins_loaded, and the plugin defined it on init.
• The credential-name guard dropped bloat.disable_password_strength_meter from settings exports, read-only abilities, and proposals. A reviewed exception keeps it; any new credential-like key is still hidden.
• Corrected the Diagnostic logging description (entries are kept in the database, not a log directory) and the Purge GT cache description (it removes stored pages, not generated assets).
• Commerce\PolicyAudit, Optimization\Css\SelectorObservation, and uncalled methods left from removed features.

Background queue

Cache warming

Smarter purging

Settings history

Health and diagnostics

AI assistants (optional)

Frontend

Database cleanup

Fetch important CSS classes

Unused CSS status

Fixes

• Queue claims are conditional, so two workers can never take the same job, and a worker that lost its lease cannot record completion or publish generated files and CSS reports. Attempts count at claim time; a job whose worker keeps crashing fails after three claims instead of retrying forever.
• Duplicate requests for the same target return the existing job. Failed jobs can be retried and pending or running jobs cancelled from Tools and wp gt-performance queue status|list|pause|resume|retry|cancel; queue alone still runs jobs.
• Optional work can be paused without stopping cache invalidation. Waiting jobs age toward higher priority, so a steady backlog can no longer starve warming (a production site had a warm run waiting 18 days); purges always run first. Scheduled runs process up to 25 jobs a minute (was 5), still within a 20-second budget.
• The queue schema upgrades in bounded admin/CLI batches under a lock, never on visitor requests. One queue runner runs per site. WordPress Studio and Playground (SQLite) are supported.
• Warm runs resume across bounded background jobs instead of stopping after 20 child sitemaps. They read up to 10 sitemap sources you choose, or the WordPress sitemap plus sitemaps listed in robots.txt; follow nested indexes and same-site redirects five levels deep; skip foreign, private, and already-visited URLs; and cap a run at 50,000 targets.
• The home page and recently modified pages warm first, in batches. A run stops at the cache entry budget instead of evicting pages to finish, and warms mobile copies with a phone user agent when a separate mobile cache is on.
• Each preload records whether the origin stored a fresh page, only Cloudflare answered, or nothing was stored. HTTP 200 alone no longer counts as warm. Progress is in Tools and wp gt-performance cache warm-status.
• Cached pages record the posts, listings, reusable blocks, and navigation menus they were built from. Updates purge those pages as well as the usual related pages: listings a post joins or leaves (including its old category and later pages), query loops, grids, and widgets that show it, pages embedding an edited reusable block or menu, and shop listings after price or stock changes. Renamed terms purge their old archive URL. Unrelated pages stay cached.
• wp gt-performance cache preview --post=<id> lists what an update would purge and why.
• Related-page purges no longer include URLs on another host (for example an author link to a personal site), which were also sent to the Cloudflare purge.
• Every save keeps the non-secret values it replaced: the last 20 saves, up to 90 days. Tools → Settings history shows differences and restores them; settings export to and import from JSON with a preview. The same is available in wp gt-performance config.
• Credentials, Cloudflare and xCloud identity, Redis, and AI agent access are never stored, exported, imported, or restored. A shared settings lock and preview checks stop one administrator, CLI command, or connection flow from overwriting another's change.
• Tools → Health combines queue backlog and age, runner heartbeat, WP-Cron, storage, drop-ins, edge ownership, configuration publication, purge verification, unused-CSS failures, and warming, each with its source and time. It also appears as a Site Health test, in wp gt-performance health [--format=json], and as a redacted support-report download.
• On WordPress 6.9 and later, abilities let an external AI assistant read status, URL cache explanations, health, jobs, CSS reports, non-secret settings, purge previews, and operation results, through the WordPress REST API or the official WordPress MCP Adapter. Off by default and for administrators only; see the AI & MCP tab or wp gt-performance abilities status.
• "Read and operate" access also lets an assistant purge or preload up to 20 URLs, regenerate unused CSS for a URL, and retry failed preload, warming, CSS, or image jobs. Each request carries an ID, so retrying after a timeout never repeats the work. Limits: 60 requests a minute per user and 100 outstanding operations per site. Purge results report the origin, the edge provider's response, and what a public request returned afterwards. Queued work is cancelled if access is turned off or the user stops being an administrator.
• Assistants can propose (never apply) changes to cache warming, JavaScript defer and delay, critical images, unused-CSS rollout, and the CSS safelist. Proposals wait 15 minutes on the AI & MCP tab or in wp gt-performance operations for an administrator to apply or reject, and are refused if settings changed in the meantime.
• Optional in-admin AI adviser (WordPress 7.0+, off by default). It explains a page, diagnoses the queue and warming, reviews settings, or explains a purge, using the AI provider configured in WordPress. Before anything is sent it shows the exact redacted report and the recipient. Answers must cite that report; numbers not in it are flagged, and suggestions can only become a proposal. Limited to one request at a time and 20 a day per site. GT Performance stores no AI credentials.
• Unused CSS keeps the state styles page builders add after the page loads: open menus, active tabs and accordions, sticky headers, popups, sliders, and entrance animations. Covered: Elementor, Bricks, Divi and Extra, Beaver Builder, Oxygen, Breakdance, WPBakery, Brizy, Kadence Blocks, Spectra, GenerateBlocks, and SiteOrigin, plus the carousel, lightbox, and animation libraries they bundle. Where the builder is freely available, the state classes were taken from its shipped front-end scripts. GT Page Blocks Builder and Thrive Architect styles are left whole. Protection applies only while the builder is active and "Automatic conflict protection" is on.
• JavaScript defer now follows WordPress's script registry, the same rule core uses. A script stays blocking when inline code runs right after it, or when a script depending on it must. Previously, turning on defer also deferred jQuery and broke inline jQuery(...) code. Delay applies to a selected script together with the scripts that depend on it, or to none of them. Scripts WordPress did not register are no longer deferred, because their order is unknown; they can still be delayed by naming them. Debug mode explains every decision in an HTML comment.
• Per-page options in the editor: turn off script delay or all script changes, and name the page's hero image.
• Hero image rules by post type, template, or front page choose the image that gets high priority, instead of document order. Optional responsive preload is never duplicated. Background heroes can be declared and preloaded. Attributes set by the theme or WordPress still win.
• Speculative loading (WordPress 6.8+) keeps cart, checkout, account, and every other cache-bypass path out of prefetching. Modes: WordPress default with exclusions, prefetch on press only, or off. When the Speculative Loading plugin is active, it keeps control of the mode.
• Manual cleanup runs in the background. The button returns at once, the Database tab shows each task's count as it works, and a run can be stopped after its current batch. Deleting 1,000 items no longer holds the admin request open until the end.
• A manual run goes ahead of cache warming and preloads in the queue, but never ahead of cache purges. At the old priority it waited behind a whole warm run on a production site.
• Scheduled cleanup uses the same background run. wp gt-performance database run now finishes every task instead of stopping after 1,000 items per task.
• Keeping recent revisions now works across all posts. A post with too many revisions was missed when earlier posts in the scan were within the limit.
• Emptying the trash or deleting spam and trashed comments no longer purges pages. That content was never public, and each trashed post used to purge the homepage and its listings again.
• Unused CSS reads the HTML the server sends, so parts that JavaScript adds after the page loads (a table of contents, an ad, a slider) looked unused and lost their styling. After you change unused CSS settings, CSS Status now opens two recent pages from each public post type in your browser, on desktop and mobile, and records the classes, IDs, and CSS rules those scripts need. Builds for that post type keep them. The check shows its progress, says what it found, and links to the next step; it can also be run from CSS Status at any time. IDs and rules seen on only one page, such as numbered heading anchors, are ignored, and post types hidden from search are skipped.
• Each result says in plain language what visitors get for that page and what to do, instead of codes such as critical_budget_exceeded. A Hybrid build that was over its inline limit is marked "Ready, one file": the page is styled correctly and loads like Generated file mode.
• Hybrid builds record how much CSS the top of the page needed. CSS Status uses that to suggest an inline limit that fits three in four pages, or recommends Generated file when the top of a typical page needs more than 50 KB.
• Totals count only the current delivery mode. Results from before a mode change are noted separately instead of inflating the stale count. Out-of-date results explain why they are out of date and what visitors get meanwhile.
• Bricks 2 pages lost their base styles when Bricks' own stylesheets were optimized. Bricks opens its framework CSS with a layer-order statement (@layer bricks.reset, …;), which the CSS parser read into the next rule, nesting the rest of the file inside it. Leading layer statements are now kept apart and restored; a layer statement after any rule leaves that stylesheet untouched. On anantamias.com this also let the framework file shrink from 33 KB to 8 KB per page.
• Icon-font rules written with a single colon (.ion-ios-add:before, as Ionicons, Font Awesome, and most minified CSS do) were all kept whether or not the page used the icon: 696 Ionicons rules on a Bricks page that shows one. They are now tested like ::before.
• Posts and other pages that print their own address (the comment form's cancel-reply link, login redirects, pagination) were never served their unused CSS. The build request's token appeared in that address, so the page a visitor got never matched the build. The token is now taken off the request before WordPress renders the page.
• Pages with an Akismet-protected comment form were never served their unused CSS either, and every uncached visit queued another build: Akismet puts a random number in each form. Builds are now matched on the markup that decides which rules apply, ignoring hidden form values, inline script contents, HTML comments, and CSP nonces.
• Unused CSS no longer changes which stylesheet wins. All generated CSS used to go at the end of <head>, so when a theme's stylesheets were excluded, WordPress's global styles moved behind them and overrode the theme's fonts and link colours. Each run of consolidated stylesheets is now replaced where it stood.
• GT Performance no longer loads its bundled libraries on every request. Composer's autoloader, with the 1,176 functions of the Safe library that the CSS parser depends on, was included for every uncached page view, admin screen, and REST call, even though the libraries are only used while CSS is pruned or JavaScript minified. They now load the first time one of their classes is needed: 201 fewer files per request on gatilab.com, and about 10 ms less start-up in a warm-cache benchmark.
• The plugin package no longer ships its libraries' README and changelog files or the Safe library's Rector migration configs (13 files, 90 KB), and the GitHub README stays out of it.
• CSS builds no longer fail on hosts that make the origin's no-store response cacheable (Hostinger's Site Optimizer did, and Cloudflare then answered later builds of the same page with a stored copy). Every build request now has a URL no cache has seen.
• Hidden tooltips no longer widen admin pages on phones. Report tables no longer widen the page on phones either: a visually hidden column heading escaped the table's scroll area.
• The settings screen has four new tabs. AI & MCP holds agent access, the adviser, and assistant proposals. Object Cache holds the Redis settings, the connection test, the drop-in installer, and the wp-config.php overrides. CSS Status holds the unused CSS build results and the regenerate controls. Database holds manual cleanup with live counts and the scheduled cleanup settings, which used to be split between Tools and Optimization. The Cache tab is now Page Cache, and Integrations keeps plugin, host, and commerce coordination. The xCloud cache status panel appears only when the xCloud integration is enabled.
• Admin tables no longer draw a second border inside their panel, and the summary cards above them are inset like the rest of the panel.
• Posts created or updated through the REST API with an Application Password (no login cookie), for example by automation tools, now purge the Cloudflare and xCloud edge as well as the origin.
• Plugin Check reports no warnings. The dependency lookup prepares each (type, ID) pair on its own, so every query has a fixed number of placeholders. The AI & MCP tab reads the MCP endpoint from the server the adapter actually registered instead of calling the adapter's filter itself, so a customized route is shown correctly too.
• An unwritable cache directory no longer floods the error log with PHP warnings while saving settings; the failure is still reported.

• Fixed individual Cloudflare purges by allowing internal PURGE requests in the managed cache rule while preserving checkout, session, and query exclusions.
• Wait for Cloudflare before verifying or reporting manual cache purges; show partial failures and retain the latest purge result even with debug logging disabled.
• Purge desktop, mobile, and tablet cache variants when separate device caching is enabled.
• Retry temporary Cloudflare transport, rate-limit, and server failures up to three times, preserving unprocessed batches and honoring Retry-After.
• A successful full purge supersedes queued URL purges and retries. Failed verification requests no longer appear successful, and receipt details display correctly.
• After upgrading, use Connect/sync Cloudflare once to update the existing managed rule. Unrelated Cloudflare rules are preserved.

Validation includes 43 unit tests/94 assertions, PHP lint/static analysis, database/API and import checks, last-seat and concurrent-edit races, desktop/mobile checks, package installation and upgrades. The hosted demo disables payment and outbound email. Provider acceptance remains specific to each merchant's configuration.

• Keep a service-wide default and override individual starts from 0 to 100 seats.
• Show remaining seats and use the chosen session's maximum in the booking form.
• Prevent capacity edits below confirmed bookings or active payment, approval and waitlist holds.
• Enforce current limits during booking, payment confirmation, rescheduling, waitlist claims and imports.
• Preserve limits in format-2 exports while continuing to accept format-1 imports.
• Add a guided hosted demo with custom/default/closed sessions, a last-seat example and service-editor access.
• Keep demo dates and per-session overrides aligned across the daily reset.

FluentCart requires version 1.6.5+ and currently collects full payment. Deposits and session packs remain on Stripe. Partial refunds for combined orders require allocation review. Validate provider connections on staging before accepting customer bookings.

Validation: PHP lint, 38 unit tests/67 assertions, PHPStan, isolated integration and transfer checks, native FluentCart checks, concurrency tests, upgrade/uninstall checks, desktop/mobile review, and CI across PHP 8.3–8.5 plus WordPress 6.9/current.

• Allow selected services to overlap for the same staff member while preserving capacity within each service.
• Add customer profiles with registered metadata, permission-checked REST access and durable lifecycle hooks.
• Offer embedded Stripe Payment Element alongside hosted Checkout.
• Combine bookings and optional extras in native FluentCart checkout. GTFC is optional.
• Protect new bookings, waitlist requests and email sign-in with optional Turnstile.
• Send Brevo templates with up to five reminder steps and per-step template selection.
• Preserve guest bookings, optional Core Forms intake, scoped assets and existing data during schema 4 upgrades.

Validation: 45 currency boundary checks, a failing 2.6.2 baseline, authenticated settings save/readback on FluentCart 1.6.6, existing checkout regression checks, PHP/JavaScript syntax, generated assets, and package integrity.

The FlowMattic imports are under docs/flowmattic/. Open the imported Plugin Actions trigger, enter its hook, capture a sample, configure its action, and enable it after testing. The invoice draft template also requires the GTFC integration key and form-specific field mappings. See the bundled setup guide.

Requires FluentCart. Invoice and newer store modules require FluentCart 1.6.4 or later.

• Add six invoice designs: Amount First, Letterhead, Ledger, Catalog Cards, Project Statement, and Tax Detail. Preview each layout without creating an invoice, and choose a layout per invoice or as the store default. The editor groups project name, period, and customer-facing scope beside the template choice.
• Add project names, service periods, and item descriptions. FlowMattic invoice items can choose a bundled icon or a public HTTPS image URL; the image follows the invoice into FluentCart's order and checkout.
• Expand Back-in-stock alerts with status totals, per-option demand and stock state, product/SKU search, and status filtering.
• Give invoice controls clearer action groups and icons, better manual-tax field spacing, and help text that explains what customers see and how totals are calculated.
• Add a paused FlowMattic import for turning completed Core Forms submissions into reviewable invoice drafts. The form event ID prevents duplicate drafts on workflow retries. Drafts create no native order and send no customer email until a merchant issues them.
• Add the gtfc/lifecycle WordPress action for quote requested, quote accepted, invoice issued, and invoice paid transitions. One flat payload carries an event type and stable event_id, with no private proposal or payment URL. A paused FlowMattic trigger import is included.
• Point the in-plugin guides and training links to the current customer portal lesson routes.

Requires FluentCart. Invoice and newer store modules require FluentCart 1.6.4 or later. See the bundled readme.txt and docs/INVOICE-AUTOMATION.md for details.

• Invoice improvements
• Create invoices from FlowMattic through the keyed, idempotent gtfc_create_invoice PHP function. Paused import templates for webhook and WordPress custom-action triggers are included under docs/flowmattic/.
• Edit unpaid invoices while preserving their invoice number. Reissuing creates a new native FluentCart order and revokes the old payment link. Paid, partially paid, and refunded invoices stay locked.
• Choose a template per invoice, configure the default layout and invoice numbering, and edit or hide the company registration label.
• Apply a custom tax amount to a custom invoice item, or use FluentCart's configured tax calculation. Billing address fields are available to automation.
• Improve dark-mode admin text contrast and add the bundled invoice icon.
• Included since the previous GitHub release
• The 2.5.0 general-store modules: custom invoices and quote proposals, five checkout designs, service products, wishlists, back-in-stock alerts, checkout fields and add-ons, delivery scheduling, and saved carts.
• Multi-currency checkout and gateway routing refinements, customer and seller invoice profiles, contextual documentation, and conditional minified assets.

Core Tables 0.1.1 is an early-access update focused on the Block Editor. Core Chart now selects a usable category and numeric value automatically for existing blocks without explicit mappings. Table and chart previews use native WordPress editor controls and quieter table styling.

The package retains the accessible chart data-table alternative, dedicated dataset tables, shortcodes, and opt-in AI Abilities/MCP support.

Early-access limits: 500 rows, 30 columns, and 2 MB per dataset; bar charts only. Google Sheets sync, line charts, and automatic cache purge are not yet available.

Core Tables 0.1.0 is the first early-access release. It stores reusable datasets in dedicated WordPress tables and publishes searchable, responsive tables through Block Editor blocks or [coretable id=123] shortcodes.

This release includes CSV and HTML table imports, rich text and Media Library image cells, public-column controls, appearance settings, bar charts with table alternatives, saved revisions, recoverable Trash, six permission-checked WordPress abilities, optional MCP exposure, and a FluentCart-bound licensed updater.

Early-access limits: 500 rows and 30 columns per dataset; 2 MB per import or snapshot. Google Sheets sync, line charts, and automatic full-page cache purging are not included. Purge a page cache manually if it retains old table HTML after publishing or trashing.

Requires WordPress 6.9+ and PHP 8.3+. The plugin continues to render installed tables when a license is inactive; protected updates and support require a valid license.

Validation: PHP 8.3 and 8.5 source CI passed on the tagged commit. The package passed 98 dataset integration checks and 21 licensing checks on a disposable WordPress 6.9 installation, plus 13 PHPUnit tests (38 assertions).

• Added recoverable dataset Trash with owner-scoped restore, preserved revisions and publication pointers, and exclusion from public queries and embeds.
• Added Trash and Restore dashboard actions with bundled icons and a confirmation before hiding published embeds.
• Kept all dataset data in the existing dedicated tables; no WordPress post-data migration is involved.