Deep Export & Dependencies

Dependency-aware export

Content is rarely self-contained. A template leans on custom fields, media, menus, global classes, and often other posts. Deep export exists so a release moves the whole shape of a change rather than the one item you happened to select.

WPChangeSync resolves those dependencies for you, then rewrites the references so they point at the right things on the destination: attachment IDs are remapped to the target's media library, post and term IDs are remapped, and nested references inside builder JSON are followed rather than copied blindly. That is why an imported page arrives with its images, its fields, and its parent still attached.

Related data concerns

• Media and attachment references need remapping.
• Post, term, menu, and field IDs may differ by site.
• Builder JSON can contain nested references.
• CSS framework tokens and global classes may need to move together.

Most of this is handled for you on a cross-site sync. Widget settings that store source-site IDs (image, gallery, audio, video, navigation menu, and page list widgets) are reconnected to the destination own media, menus, and pages, and menu items relink to their page in any import order, so a menu that imports before its target page still ends up pointing at the right place instead of back at the source site.

When your content depends on custom-field definitions, the related-data dialog offers an opt-in Include ACF Field Groups option. It bundles the ACF field group definitions your content relies on, which is what makes synced ACF values actually appear on the target. On import the groups are added only when missing, so a push never overwrites the field configuration already on the destination.

Practical use

Match the export to the size of the change:

• A small edit, such as one page or one template, is best moved selectively. Check the items you mean and leave the rest alone.
• A reusable section or a design-system change should include the related integrations, since a template without its classes and fields is not much use on the other side.
• A full release is worth assembling as a bundle or a workflow so the same set moves the same way every time.

Whatever the size, read the generated JSON before committing a deep export. It is designed to be reviewable, and the diff is the cheapest place to catch a mistake.

Reference checklist

Treat a deep export as one reviewed release unit: the related templates, fields, media, menus, classes, variables, and any custom code that belongs with them. Moving those pieces separately is what produces a half-broken target site, and it is also much harder to roll back.