Spectra MCP for popups, block activation and Google Fonts delivery

A new Spectra popup is a draft, but already marked enabled

spectra-create-popup saves a draft by default, with the locked popup builder root block, popup_type modal and repetition 0. It also sets the enabled flag to true. While the post is a draft that flag does nothing visible, so the trap comes later: publishing the popup with spectra-edit-popup, or from the editor, makes it live at once, and on a site without Spectra Pro display rules a live enabled popup appears on every page.

The safe order for a Spectra MCP popup is to create it, call spectra-disable-popup straight away, write the content and, with Spectra Pro, the trigger and inclusion rules, publish, check it on a staging page, and only then call spectra-enable-popup. Enable and disable are ordinary writes that can be repeated safely. spectra-edit-popup is classed destructive because it can rewrite a live popup's content and status in one call, so on Production Safe it waits for confirm.

Pruning unused Spectra blocks without breaking old pages

Switching off blocks a site never uses is a common Spectra tidy-up, done with spectra-set-block-activation against the _uagb_blocks registry. The risk is a block that is unused in new work but still sitting in old posts: once disabled, Spectra stops loading its CSS and JavaScript, and those old copies render as unstyled HTML. Before disabling a block, have the agent run search-content for its block name, for example uagb/countdown, and list every hit; it covers public content types, so reusable blocks and private content deserve a look of their own. spectra-list-form-blocks does the same job for forms, capped at five hundred posts with a truncated flag.

Block activation is destructive in GoBuildWP's classification, so each toggle waits for confirm, and the write reads, modifies and saves the single registry option. That helper has no lock or compare-and-swap guard, so avoid concurrent admin toggles and read the registry again afterwards. Spectra's front-end and editor caches are flushed afterwards; a page cache in front of the site still needs its own purge.

Changing a Spectra block inside a page goes through the Gutenberg queue

The Spectra module manages popups, settings, fonts and the block registry. It does not edit a Spectra block that sits inside a page. That is the job of the core Gutenberg abilities: gutenberg-get-content reads the page's parsed block tree, spectra-get-block-schema shows a block's attributes, and the change is queued with gutenberg-add-pending-change and finalised in the Block Editor Queue page, because static blocks need the editor's JavaScript to save valid markup. Most static Spectra blocks define their attributes only in JavaScript, so the schema read is most useful for dynamic blocks such as forms and post grids; for the rest, copy the attributes from a block already on the page.

Spectra settings, fonts and the confirmation they need

spectra-set-editor-settings and spectra-set-google-fonts-mode are both destructive in GoBuildWP's terms, because they change CSS for every page at once. Switching fonts to local makes Spectra serve them from wp-content/uploads/spectra/; after the switch, check one page's network requests for any call still going to Google, which usually means a theme or another plugin loads the same family. Under Read Only, the agent can still read every setting, list fonts by source and list popups. The Spectra reference lists the whitelisted setting keys.

• "Create a disabled exit-intent popup for the ebook, scoped to blog posts, and show me its conditions before anything goes live."
• "Which Spectra blocks are active but never used in any published content?"
• "Read only: is Spectra loading Google Fonts locally, and from which of the three sources?"