Silverstripe-framework: RFC: Create silverstripe/versioned and silverstripe/campaign-admin module

[sminnee]

Acceptance criteria

• Versioned, ChangeSet, and any related versioning-model classes are split into a new silverstripe/versioned module.
• CampaignAdmin and associated webpack/react client code is moved into a silverstripe/campaign-admin module
• versioned is a dependency of silverstripe/cms
• campaign-admin is a dependency of silverstripe/installer

---

Versioning & campaign management is current part of framework. This isn't a good long-term approach.

The accepted RFC is that we split the following key components (and any more minor that relate to thsese) into a new module, e.g. silverstripe/versioned:

• Versioned
• ChangeSet

This module would be a dependency of cms and of silverstripe-assets—we're not looking to create a working model of the CMS that functions without Versioning.

In addition, there will be a new module called silverstripe/campaign-admin, containing:

• CampaignAdmin

[robbieaverill]

IMO the more you can modularise a system the better, so if this component can be moved out of the core framework it's always going to be a good thing. Of course you need to ask "where do you draw the line?" - I don't think Silverstripe needs to draw the line at this point, plenty of room for separation still!

[kinglozzer]

Ideally I think we should go one further - by splitting out the UI part. Obviously it’s difficult to measure, but I would wager that a not insignificant part of SilverStripe’s install base is the stereotypical, 5-page “brochure” site. This kind of site likely has no requirement for campaigns - the “immediate publish” option discussed in #4932 would still serve these sites perfectly. Given that the changesets API is opt-in, that could still sit quite comfortably in the versioning module.

As far as I can make out from these mockups (I appreciate these are quite old now, I couldn’t find any more recent ones that showed page editing!), “Add to Campaign” is an extra action - so it should just be an integration with updateCMSActions() right? Hopefully that, and the work with React (which I’m entirely out of my depth with, so I may be wrong) with will mean that it won’t be too difficult to break off the UI code.

So my suggestion:

• silverstripe/versioning - Includes versioned and changeset APIs. CMS requires this
• silverstripe/campaignadmin - Adds “Campaigns” admin area and extra action to page edit actions. Requires silverstripe/versioning

[nedmas]

I think it would be really nice to have this in it's own module. I totally understand the desire to keep this as a dependancy of the CMS and think that it makes sense in the medium term, although depending how heavy the campaign functionality becomes it might be nice to separate that out for simpler sites like @kinglozzer suggests.

My question is: "Will the versioning module support versioning DataObjects?"

It's always been a bit frustrating that Versioned was clearly intended to work with DataObjects but has never done so out of the box. If this is going to a be separate module it would be really nice to include support for DataObjects. However if that's not possible, and this is just going to be for pages, then I'd suggest the name needs to make that clear. So silverstripe/sitetree-versioning for example.

[sminnee]

My question is: "Will the versioning module support versioning DataObjects?"

Yes. That's a big focus of the current work on versioning. We're initially applying it to File, but the goal is to make it easy to apply to, for example, content blocks. The Content Ownership & Campaign Admin stuff has mainly arisen because of the increased number of publish-steps that such a model would require, and so we wanted to have a better user experience for publishing groups of related chagnes.

[tractorcow]

I'm in favour of splitting versioning into its own module, but keeping the campaign admin together with that code. It's a self-contained feature, in that case. A model by itself would (in the vast majority of cases) require a user interface, so it would be minimal benefit to split it further at this stage.

I feel perhaps further down the line that could happen.

CMS relying on versioning is fine; Making versioning an optional component of page editing would be a much harder task, but it can be done one day if the will is there.

Framework not relying on versioning MIGHT be ok... we'd have to make that a negotiable goal. :D

[sminnee]

@kinglozzer spinning out the CampaignAdmin might make sense, but I would still keep the ChangeSet model with silverstripe/versioning. This is because I don't see it as optimal to have two different execution paths for how content gets published—it increases the risk of bugs—and so I'd like to see things internally changed so that every publish involves a ChangeSet object.

In that light, we'd be creating one module that contains the data model, and other that contains the UI. Unless swappable-UIs is a high-priority use-case, this seems like overcomplicating things.

As an alternative, we could simply have a config flag that turns the CampaignAdmin UI off.

[kinglozzer]

A model by itself would (in the vast majority of cases) require a user interface, so it would be minimal benefit to split it further at this stage.

You’re correct in that models almost exclusively require a user interface of some sort, but do all of those also therefore require the CampaignAdmin interface?

@kinglozzer spinning out the CampaignAdmin might make sense, but I would still keep the ChangeSet model with silverstripe/versioning. This is because I don't see it as optimal to have two different execution paths for how content gets published—it increases the risk of bugs—and so I'd like to see things internally changed so that every publish involves a ChangeSet object.

Exactly what I was suggesting :)

In that light, we'd be creating one module that contains the data model, and other that contains the UI. Unless swappable-UIs is a high-priority use-case, this seems like overcomplicating things.

As an alternative, we could simply have a config flag that turns the CampaignAdmin UI off.

Yeah, my thinking wasn’t around swapping out the CampaignAdmin UI for an alternative, rather having the option to omit it entirely from a CMS project and only have the current “Save & Publish” workflow available. CampaignAdmin would be a relatively small module (mostly JS/CSS, only one PHP file I can spot currently!), but it instinctively feels better than bundling everything in with framework or “silverstripe-versioned” and hiding it with a flag.

[mspacemedia]

My two pence, I'm with @kinglozzer, definitely keep CampaignAdmin and its UI out of the CMS/Framework dependencies, although a fantastic addition to the arsenal of tools in SS, My fear is it would/could over complicate the CMS end user experience for the vast majority of installs. Better to install it where necessary along with those dependencies.

Built in versioning of all/any DataObjects would be a huge plus though, not to go off topic but is this likely to be included or will heyday/silverstripe-versioneddataobjects be the way forward for those still?

[chillu]

Don't forget to update docs which explain which modules are considered "SS core" - for example the second paragraph in https://github.com/silverstripe/silverstripe-framework/blob/master/docs/en/05_Contributing/01_Code.md

[tractorcow]

Ok, similar to what we did on https://github.com/silverstripe/silverstripe-framework/issues/5289, let's do a vote?

[tractorcow]

VOTE: versioning module containing both campaign-admin and versioned model

Please use 👍 and 👎 on this comment to vote for this.

[tractorcow]

VOTE: separate versioned module and campaign-admin module

Please use 👍 and 👎 on this comment to vote for this.

[tractorcow]

I'm pretty easy either way... maybe I'll sit on my vote for a while. :)

Please only vote if you are @silverstripe/core-team , by the way!

[chillu]

Damian: A model by itself would (in the vast majority of cases) require a user interface, so it would be minimal benefit to split it further at this stage.

I've used Versioned before to implement a simple audit trail for devs with database access, no user interface required there. I've also built a simple GridField showing versions as another tab in a ModelAdmin. So there's a small case for using versioned models with different (nor no) UIs.

[tractorcow]

First PR for versioned module at https://github.com/silverstripe/silverstripe-framework/pull/6725

[sminnee]

Versioned split has been merged!