The jobs you’ve been putting off.

Plugin updates, rehearsed first — then applied

Prove the update on the copy, then apply the exact rehearsed build with one reviewed click.

• Flux fetches the release from WordPress.org and swaps it into the preview first, 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; a safe rehearsal is stored with the package’s fingerprint.
• Apply installs that exact build on the live site — byte for byte the version that proved safe — behind its own approval.
• On Cloudways, Flux takes a platform backup before touching anything. Everywhere, it holds a pre-update database dump and private file backups.
• If the live check fails, Flux puts it back: files first, then the database — with your approval covering that maintenance window up front.
• 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. Updates cover plugins published on WordPress.org; premium plugins sold elsewhere aren’t covered yet. Every apply cites a safe rehearsal of the exact version, and 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.

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

Pages and menus

Create standard WordPress pages and add them to an existing classic menu as one reviewed change.

• New pages start as drafts in the preview and are created normally through WordPress when you publish.
• Flux maps preview IDs to the new live IDs, so menus and later edits point at the right records.
• Pages and menu items that depend on each other are published together.

Limits. Creations can’t be reverted automatically after publishing; removing them is a manual, reviewed step.

WooCommerce store operations

Inspect the store and safely change existing catalog, inventory, order workflow and coupon data through WooCommerce itself.

• Products and variations include descriptions, pricing, sale dates, SKUs, stock, tax, shipping, images, categories and tags.
• Orders and customers can be inspected; approved order status and customer-note changes are supported with a warning before normal store hooks can run.
• Existing coupon rules can be updated, and non-secret store settings and sales summaries can be inspected.

Limits. Payments, credentials, refunds, deletes, customer writes and arbitrary metadata stay outside the bridge. New product and coupon creation are separate future workflows.

Forms and campaign sliders

Keep customer-facing Formidable forms and Slider Revolution campaigns current without hand-editing plugin data.

• Formidable form names, descriptions, labels, help text, required state, defaults, placeholders and choice lists are editable.
• Slider Revolution 6.x slide copy, links, images, backgrounds and publish state can be updated; slides can also be duplicated or reordered.
• Flux snapshots the complete managed record, reads the write back and checks the page embedding the form or slider.

Limits. Form entries and automation are never exposed. Slider animation and responsive positioning remain in the plugin editor.

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.

• Read-only exploration of the files and WordPress data exposed by your selected connection.
• Useful for scoping a job before you quote it.
• A conversation that says “don’t change anything” stays read-only.

Limits. Reads are bounded by the selected connection’s capabilities. Flux summarises large files and tables instead of loading them whole. Flux Connector is a preview path assessed during assisted host review.

Cloudways staging, handled

Flux finds the staging app for a site and syncs code or tables when you approve it, with a platform backup enabled by default.

• Save a named Cloudways account with an API access token, then choose an app from that account. Flux retrieves its connection details without asking you to copy SSH credentials.
• Keep client accounts separate in the account picker. Flux identifies staging apps on the selected site’s server.
• Every sync requires explicit approval. Review the scope and backup option before proceeding; a platform backup is enabled by default.
• Waiting for completion is enabled by default. With that option on, Flux checks the live site after the operation and records what happened.

Limits. App connection needs a Cloudways access token permitted to read application credentials; staging syncs also need staging permissions. Other hosts use a supported connector or SSH/SFTP connection for the preview and publish flow.

WPBakery pages

Inspect and edit WPBakery rows, columns and elements without regex surgery on shortcodes.

• Nested shortcodes are read as a structure, with unknown theme add-ons preserved as they are.
• Targeted updates, allowlisted insertions, removals and full section rebuild plans use digest checks and one reviewed write.
• Each change is followed by a screenshot of the page so verified markup is also judged visually.

Limits. Unknown shortcodes are preserved rather than edited, and raw HTML elements are read-only targets. Divi 4 and 5 need separate bridges.