Adding Versioned extension to DataObjects should create published records

[ScopeyNZ]

There was discussion about this issue in silverstripe/silverstripe-widgets#169 for context.

Problem

When adding the Versioned extension to existing data object, often during the upgrade path from 3 -> 4 you are left with all your existing records in draft state. Ideally they should create published records instead or at least perform a publish of the existing records.

Steps to reproduce.

• Create a data object
• Make some records of that data object
• Show them on a page in some way
• Add the Versioned extension to that data object
• dev/build
• Go back to the page you're showing those records on

For frameworktest you can:

• publish a company,
• observe that the employees show under a company page,
• add Versioned extension to Employee,
• dev/build
• See that employees no longer show on the published page

Workaround

Technically you can work around this by writing a quick script:

foreach (Employee::get() as $employee) {
    $employee->publish();
}

but I think this shouldn't be a manual step.

[sminnee]

This becomes a barrier to people adding Versioned to their content models, which makes it more likely for people to hit edge-cases of mixed Versioned and non-versioned content, such as https://github.com/silverstripe/silverstripe-framework/issues/8813. Suggest we dump its impact to medium.

[andreaslindahl]

When adding the Versioned extension to existing data object, often during the upgrade path from 3 -> 4 you are left with all your existing records in draft state.

My experience is that the records are indicated as Archived, instead of Draft, when the Versioned extension is added. So, in my case, your workaround script would have to look like this:

foreach (Employee::get() as $employee) {
    $employee->forceChange();
    $employee->write();
    $employee->publish();
}

Just doing publish() on them, would not move them from Archived to Published

[sminnee]

Alternatively, one could take the approach of cloning the content of, say, the SiteTree table to SiteTree_Live.

[taoceanz]

Has there been any change or progress on this bug?

[sunnysideup]

I think Sam's approach is great.... Basically: delete MyTable_Live, copy MyTable to MyTable_Live - then you have a perfectly identical set to start with. Without doing the whole "publish()" thing:

• slow
• triggers writes / publish hooks with all sorts of consequences

[taoceanz]

Is the delete and copy something that could be reliably made into a task for the SS upgrade-tool?

[sunnysideup]

maybe something like:

if MyTable_Live is empty, copy all records from MyTable? and run that for all tables in the database?

[NightJar]

Live the dream. https://gist.github.com/NightJar/eb0565d6d3ad41a5c5e6fcbfe6a54f4b No tests, so gist not PR

[doougal]

I get this in SS5 when adding versioned to a data object that already has instances in the database. +1 to andreaslindahl's comment; my experience is that the content is archived, not unpublished.

Objects also aren't showing up in the archive tab so they can't be manually restored from the CMS. I also wrote a dev task same as NightJar, mine is just a little smaller and object specific, but easily adaptable for a couple of objects. https://gist.github.com/doougal/e6951652ad9981a60f788d7d52e279b2

[NightJar]

I'm somewhat sure (without checking) that the objects showing as archived is due to there being no versions. They shouldn't disappear from the CMS, as they remain in the draft table.

My GIST steamrolls every class that meets that criteria. There is an option to exclude some though, as opposed to include only some. It's good to have options, nice one @doougal :)