Deploying a model

A typical setup keeps the model in JSON files in your theme, edits it on a local site, and deploys the files like any other code.

On your local site

1. Build or change objects in the dashboard.

2. For a new object, open its Source tab, choose Save to project, and pick your theme's vx-config folder to keep the file with your theme. VX gives you the file's path and JSON to save there, and Sync does the same for later changes. With VX Framework Pro, VX writes the file to your theme's vx-config folder, or any folder you register, itself, and Direct mode works there too.

   The list also offers the Uploads folder (wp-content/uploads/vx-framework/vx-config). VX writes files there itself, so it supports Direct mode, but the folder belongs to the site rather than your theme, so it isn't deployed with it. See JSON files.

3. Commit the files.

On staging and production

1. Deploy the theme with its vx-config folder.
2. The objects appear automatically, read-only in the dashboard.
3. Optionally lock the site (below), so nobody can change them outside version control.

Content isn't part of this: entries and field values stay in each site's own database.

When someone changed production in the dashboard

On an object in Default mode, a dashboard edit creates a database copy on top of the file, and the Source tab shows that they're out of sync. From there you can:

• Sync the change back into your project, by writing it to the file locally or, for PHP registrations, copying the generated PHP.
• Reset to the file, which discards the database copy. The discarded version is kept as a revision.

wp vx-framework config status lists every object that's out of sync.

Lock production

Add this to production's wp-config.php:

define( 'VXFRAMEWORK_CONFIG_LOCKED', true );

While locked, VX refuses every change to where configuration comes from: no overrides, resets, writes to files, imports, mode changes or detaching. Code-defined objects are forced to Read only. Objects that only exist in the database can still be edited as normal. The lock freezes the link between code and database, not the dashboard.

The Source tab shows Configuration locked on this site while it's on.

Check before you ship

Add this to your CI or deploy script:

wp vx-framework config status --strict

It exits with an error if any object is out of sync, any file is invalid, or a file loads with errors or warnings, such as a misspelled field type. A script that talks to VX over MCP or the abilities API can ask vx-framework/get-config-conflicts instead: an empty conflicts list means there is nothing to fix, and each entry says whether it is an error or a warning.

Technical details for LLMs

• Lock: VXFRAMEWORK_CONFIG_LOCKED constant or vxframework/config/locked filter. Refused operations return config_locked. Code-backed objects forced to locked mode; db_native objects unaffected.
• Sync/reset abilities: vx-framework/get-config-diff, vx-framework/write-config-to-project (overwrite, no undo), vx-framework/reset-config (discard copy; recorded as a revision), vx-framework/override-config (copy code into the database).
• Changed permalink bases in deployed files need a rewrite flush (vx-framework/flush-permalinks, or visit Settings → Permalinks).
• Hooks: vxframework/config/file_written, vxframework/config/file_deleted, vxframework/config/db_copy_discarded.