Use cases
The jobs you’ve been putting off.
Each of these runs against a private copy of the client’s site first. Nothing reaches the live site until you review it and press publish.
Plugin updates, rehearsed first
Run the update on the copy, click through the site, and find out what breaks before the client does.
You might ask
“Rehearse the latest WooCommerce update and tell me whether the shop and checkout still render.”
- Flux fetches the release from WordPress.org and swaps it into the preview, never the live site.
- The upgrade runs against the site’s real plugins, theme and data, then Flux checks the site still renders without PHP errors.
- You get a verdict with evidence, and the preview’s plugin files are restored afterwards.
- On IPR Medical, rehearsing an Elementor beta on the copy surfaced a fatal error in its database upgrade. The live shop never saw it.
Limits. Rehearsals cover plugins published on WordPress.org; premium plugins sold elsewhere aren’t rehearsed yet. A clean render isn’t proof checkout works, so you still click through it.
Elementor edits and new pages
Find a supported classic section, change it in place, and keep the theme’s own styles. Test new Atomic pages only on a compatible pilot setup.
You might ask
“On the Service page, replace the second testimonial with the new one from Dr. Patel and tighten the heading.”
- Flux inspects Elementor pages as an outline, so it can find the right section on long pages.
- Core widgets and legacy sections, columns and containers can be edited in place.
- The pilot MCP bridge can build new Atomic compositions on bridge-created drafts when Elementor 4.3 beta, WordPress 6.9+ and the Atomic Editor are available.
Limits. Third-party widget controls are generally not editable. The Atomic bridge creates new compatible pages; it does not edit arbitrary existing Atomic pages yet. Flux reports when a capability is unavailable.
Questions about the live site
Ask why a page is slow, what a plugin does, or where a piece of text comes from. Before a preview exists, Flux can read but can’t write.
You might ask
“Where does the “Request a quote” form on product pages come from, and what happens when someone submits it?”
- Read-only exploration of files and WordPress settings over SSH.
- Useful for scoping a job before you quote it.
- A conversation that says “don’t change anything” stays read-only.
Limits. Reads are bounded, so Flux summarises large files and tables instead of loading them whole.
Cloudways staging, handled
Flux finds the staging app for a site, takes a backup, and syncs code or tables when you approve it.
You might ask
“Push the approved changes from staging to production and verify the homepage afterwards.”
- Connect a Cloudways API token; Flux pairs each site with its staging app on the same server.
- Every sync is one explicit approval, with a platform backup taken first.
- Flux waits for the operation to finish, checks the live site and records what happened.
Limits. Staging syncs need a Cloudways token with staging permissions. Other hosts use the standard preview and publish flow.
WPBakery pages
Inspect and edit WPBakery rows, columns and elements without regex surgery on shortcodes.
You might ask
“Swap the hero image on the About page and update the intro paragraph.”
- Nested shortcodes are read as a structure, with unknown theme add-ons preserved as they are.
- Divi 4 and 5 follow WPBakery.
Limits. In progress. Today, WPBakery pages run in the preview, but Flux won’t edit their layouts.
Not on the list?
Theme file edits and questions about any part of the site work today. See what’s coming next on the roadmap.