Summary
When a site bundle is exported and later imported (restore), data_rows are recreated but no data_row_versions entries are created and active_version_id is never set. Any collection loop that renders rows (e.g. a projects grid on the homepage) resolves zero rows after a restore, even though every row exists in the admin with status: published.
Environment
- Instatic v0.0.20 (commit f92e8dc)
- Self-hosted via Coolify (built from source, ARM64)
Steps to reproduce
- On a site with a collection (table) and documents with
status: published that are rendered via a loop component:
- Export a site bundle (Backup → download
.zip).
- Import that bundle into a fresh instance (or after wiping data).
- Import completes successfully — pages render, media works.
- Open the homepage: the collection loop renders nothing.
- In the admin, the documents are all still there and marked published.
Expected behavior
Import restores rows in a renderable state: each imported row should get a data_row_versions entry and its active_version_id should point to it, so loops resolve immediately without manual intervention.
Actual behavior
data_rows are inserted but the version chain is never rebuilt. Loops that resolve rows via active_version_id return 0 rows until each row is manually re-published.
Root cause (from source)
In the import path, rows are written via replaceDataRow (server/repositories/data/rows/import.ts). It inserts into data_rows (status, publishedAt, cells, …) but:
- never inserts into
data_row_versions, and
- never sets
active_version_id.
Related area: #534 (publish path producing active_version_id rows with site_snapshot_id = NULL) suggests this version-chain area is fragile in more than one way.
Workaround we use
Manually re-publish every imported document (content_set_document_status → published) and then call site_publish. That regenerates version rows and the loop renders again. It works, but for a site with many documents it is tedious and easy to miss — and nothing in the import result hints that anything is wrong.
Suggested fix
During bundle import, after inserting rows, either:
- create a
data_row_version per imported row from the imported cells payload and point active_version_id at it, or
- persist and restore the original version chain in the bundle (export
data_row_versions too, which would also make restores more faithful), or
- at minimum, detect rows with
status = 'published' but no active version after import and surface a warning in the import report.
Summary
When a site bundle is exported and later imported (restore),
data_rowsare recreated but nodata_row_versionsentries are created andactive_version_idis never set. Any collection loop that renders rows (e.g. a projects grid on the homepage) resolves zero rows after a restore, even though every row exists in the admin withstatus: published.Environment
Steps to reproduce
status: publishedthat are rendered via a loop component:.zip).Expected behavior
Import restores rows in a renderable state: each imported row should get a
data_row_versionsentry and itsactive_version_idshould point to it, so loops resolve immediately without manual intervention.Actual behavior
data_rowsare inserted but the version chain is never rebuilt. Loops that resolve rows viaactive_version_idreturn 0 rows until each row is manually re-published.Root cause (from source)
In the import path, rows are written via
replaceDataRow(server/repositories/data/rows/import.ts). It inserts intodata_rows(status, publishedAt, cells, …) but:data_row_versions, andactive_version_id.Related area: #534 (publish path producing
active_version_idrows withsite_snapshot_id = NULL) suggests this version-chain area is fragile in more than one way.Workaround we use
Manually re-publish every imported document (
content_set_document_status → published) and then callsite_publish. That regenerates version rows and the loop renders again. It works, but for a site with many documents it is tedious and easy to miss — and nothing in the import result hints that anything is wrong.Suggested fix
During bundle import, after inserting rows, either:
data_row_versionper imported row from the importedcellspayload and pointactive_version_idat it, ordata_row_versionstoo, which would also make restores more faithful), orstatus = 'published'but no active version after import and surface a warning in the import report.