Will It Work With My Plugin?

Three ways a plugin is covered

The honest answer to "does it support my plugin?" is that there are three different levels of coverage, and most plugins land on the second one without you doing anything.

1. A native integration. The plugin has a purpose-built manifest, so its own configuration and definitions are understood directly.
2. Auto-discovery. No manifest exists, but the plugin's content lives in post types, taxonomies and post meta, which WPChangeSync picks up automatically.
3. A custom data source. Nothing is picked up automatically, so you point WPChangeSync at the plugin's own options, tables, post types or taxonomies yourself, without writing code.

Knowing which level applies tells you what to expect, and it is usually the difference between a smooth first sync and a surprise.

Level 1: native integrations

WPChangeSync ships 39 native manifests. In summary:

• Bricks core (22): templates, components, settings, global classes, theme styles, variables, colours, typography, breakpoints, custom CSS and code, fonts and icons, sidebars, element defaults, global elements and queries, and more.
• WordPress core (7): posts, pages, media, menus, widgets, categories, tags.
• Builders: Gutenberg.
• Fields: ACF, ACF Post Types, ACF Taxonomies, Meta Box, ACPT. These move field definitions, not just values.
• CSS frameworks: Automatic.css, Core Framework.
• Bricks ecosystem: Advanced Themer, Bricksforge.

The full breakdown lives in Integrations, and the searchable integration directory lists every plugin and theme covered, including the ones you can add yourself.

Level 2: auto-discovery, which covers most plugins

Every public custom post type and custom taxonomy registered on your site gets its own Library section automatically. No configuration, no manifest, no request to us. Post meta is included when posts are exported, which is the part that matters most.

That is how plugins without a dedicated integration still move. A WooCommerce product, an Elementor or Divi page, a Pods-defined entry: each travels as its post type with its meta attached. Page-builder structural meta is treated as sacred, so an overwrite import will never prune the layout data belonging to Bricks, Elementor, Divi, WPBakery, Beaver Builder, Oxygen or Brizy.

Be clear about the boundary, because it is where expectations break. Auto-discovery moves content. A plugin's own global settings are only understood natively for the integrations listed above. If you need a plugin's settings screen to travel too, that is level 3, and it takes about two minutes to set up.

Level 3: build a source for anything else

When a plugin keeps things somewhere auto-discovery cannot see, such as its own options or its own database tables, build a custom data source under Settings, then Data Sources. Add a part per data type: an options prefix, a table prefix, a post type, or a taxonomy.

The result behaves exactly like a built-in integration: it appears in the Library, exports and imports as JSON, pushes to remotes, and can be selected in workflows. Secrets are filtered out automatically, and if you are a plugin author you can export the finished configuration so the integration ships with your own plugin. See Extending WPChangeSync.

Checking your own stack

Rather than guessing, look at what your site actually reports:

• Open the Library and see which sections exist. Anything listed there is syncable today.
• The panel listing integrations detected on this site also explains why something is hidden, which is usually just that the plugin it belongs to is not installed.
• Integrations are labelled stable, beta, or alpha. Stable and beta are visible by default; alpha ones can be switched on under Settings, then General.
• Run a dry run against a staging site before committing to a workflow. It reports exactly what would move without writing anything, which is the fastest way to confirm coverage for your particular stack.