Does restoring a Sulu page version preserve properties removed from the current template?

Restore Behavior for Removed Template Properties

In Sulu 2.x, restoring a page version retains the data in the database (as orphaned data) but does not render it in the Administration UI if the property has been removed from the current template XML. The restore operation does not block the process, nor does it automatically purge properties that are no longer defined in the template.

Likely Technical Explanation

Sulu versions store snapshots of page content. When a restore is triggered, the system loads the versioned data and applies it to the page entity. However, the Sulu Administration UI is dynamically generated based on the current template XML definition. Because the UI only renders fields defined in the active template, any restored properties that are absent from that XML become "invisible" to the editor, even if the values persist in the underlying Doctrine entity or database columns.

The outcome depends heavily on how the property was "removed":

• Template XML Removal Only: The data is restored to the database, but remains orphaned and inaccessible via the UI.
• Database Column Removal (via Migration): If a Doctrine migration dropped the physical column from the database, the restore cannot reinstate that data; the value is effectively lost regardless of the version snapshot.

Draft vs. Published Versions

The restore operation typically targets the working copy (draft) of the page. The restored state—including any orphaned data—remains in the draft state until the editor explicitly publishes the page. This allows for a manual review of the page content before the restored (and potentially outdated) structure goes live.

Verification Steps for Sulu 2.x

To confirm the exact mapping logic in your specific installation, investigate the following areas of the PageBundle:

1. Service Analysis: Inspect Sulu\Bundle\PageBundle\Version\VersionService. Trace the restore method to see how version data is mapped back onto the Page entity.
2. Mapping Logic: Review the PageManager or PageRepository update methods to determine if there is a filtering mechanism that explicitly drops properties not present in the current template during the save process.
3. Database Audit: Perform a controlled test in a staging environment: create a property, save a version, remove the property from the XML, restore the version, and query the database directly to see if the value persists.

Diagnostic Requirement: To provide a more definitive answer on whether data is purged during the save cycle, please specify if your project uses custom Page entities or standard Sulu PageBundle entities.