RFC: Move RedirectorPage and VirtualPage into their own modules

[chillu]

I'm just creating a PoC for a website that's using a Decoupled CMS approach. It's built with pages and blocks, which are exposed via a GraphQL endpoint. Since SilverStripe doesn't have anything to do with the routing or presentation of this "Content API", every variation of the types exposed there is additional implementation effort for the consumer of this GraphQL endpoint.

Hence I'm proposing that we move RedirectorPage into silverstripe/redirectorpage, and VirtualPage into silverstripe/virtualpage modules, making them opt-out via composer.

• RedirectorPage isn't the only way to manage redirects in SilverStripe, e.g. https://addons.silverstripe.org/add-ons/silverstripe/redirectedurls is very popular. We shouldn't force conflicting approaches on authors.
• But can't you just disable those classes? That's surprisingly hard, I've tried for an hour to remove them from the "add page" dialog without much luck. For GraphQL, you can opt out of specific auto-generated operations for subclasses, but it's a bit clumsy (https://github.com/silverstripe/silverstripe-graphql/pull/206).
• Won't it make maintenance and releases more complex? We're assembling recipes and releases from so many modules already (over 70 for CWP), that two additional ones won't make a difference any more - we need solid automation anyway.
• It'll be a semver break if we change namespaces That'll make it difficult to apply this to 4.x, although we could look into keeping the namespace in a 4.x compatible module release - composer docs are inconclusive if that's allowed. If it's a 5.x change, it's a lot lower priority for me because it won't benefit my "clean up for Decoupled" agenda.
• Tickets are in the wrong repo We can move them with Github's new feature

/cc @silverstripe/core-team

[sminnee]

But can't you just disable those classes? That's surprisingly hard.

It doesn't invalidate this request, but I think we should fix this too.

Won't it make maintenance and releases more complex?

I believe strongly that a package such as this should have its release number decoupled from core. It's unlikely to change very often and tagging this every time is just... perversely against the spirit of decoupling. This means two things:

• These modules only get new tags when they have changes themselves
• A new 4.x core release doesn't necessitate a new version of these modules (because that would be breaking an API)

It'll be a semver break if we change namespaces

In principle you can retain the same namespace but move to a package. It means there will be 2 folders scanned for classes instead of 1. Untidy, but functional. You could clean up in SS5.

[robbieaverill]

We’d need to be careful of people who don’t use recipes who may lose the packages on a composer update if they don’t know to require them manually. Perhaps you could split the packages and make them cms dependencies until 5.x where they become optional and have their namespaces updated respectively?

I’m +1 for splitting them out

[ScopeyNZ]

This gets my +1

I believe strongly that a package such as this should have its release number decoupled from core. It's unlikely to change very often and tagging this every time is just... perversely against the spirit of decoupling.

+1 (bolded for emphasis)

We’d need to be careful of people who don’t use recipes who may lose the packages on a composer update if they don’t know to require them manually. Perhaps you could split the packages and make them cms dependencies until 5.x where they become optional and have their namespaces updated respectively?

Agreed. People using the existing recipe shouldn't see a change like that while staying on a major version. Developers who would benefit from this functionality are probably more likely to write their own recipes (so to speak)

[chillu]

Perhaps you could split the packages and make them cms dependencies until 5.x

That defeats the purpose. I want to require silverstripe/cms without pulling in those two page types (or new modules containing them). This will come up again I think, and we need to provide some clarity to the community. My take is that we provide semver on a recipe level, which is what you get with composer create-project and the installer download. If you actively opt out of that recipe and require a subset of it directly (e.g. cms and framework only), then you're also expected to read upgrade guides for minor releases carefully. You can still achieve semver as an implementor, but it does require you to manually add those two new module deps.

[maxime-rainville]

I like the general idea. I'm kind of curious if we shouldn't take a step back and try to build a minimalist CMS package. Basically, I would identify the absolute minimum you would need for a CMS to work, move that into one package.

[sminnee]

Shedding some data on the light:

• https://packagist.org/packages/silverstripe/recipe-cms/stats suggests that we're around 420 daily installs in November
• https://packagist.org/packages/silverstripe/cms/stats suggests around 670 for the same period

So 63% of users are using the recipe. Let's call it 2/3. Therefore 1/3 of users would be impacted by Ingo's proposal.

[sminnee]

I'm kind of curious if we shouldn't take a step back and try to build a minimalist CMS package.

I'd be more interested in putting our energy into going the other way and building a more complete package. SilverStripe is already minimalist. If you want to go more minimal you can pick your own packages.

[sminnee]

OK there are lies, damned lies, and statistics. I think including dev branches overstates non-recipe-use.

Digging into the specific download counts of all time for 4.2.2 and 4.2.3:

• 1025 x 7 cms
• 881 x 7 recipe-cms

So that suggests that 86% used the recipe, and 14% did not.

[sminnee]

Source URLs:

https://packagist.org/packages/silverstripe/recipe-cms/stats/4.2.2.json?average=weekly&from=2017-07-11 https://packagist.org/packages/silverstripe/recipe-cms/stats/4.2.3.json?average=weekly&from=2017-07-11

https://packagist.org/packages/silverstripe/cms/stats/4.2.2.json?average=weekly&from=2017-07-11 https://packagist.org/packages/silverstripe/cms/stats/4.2.3.json?average=weekly&from=2017-07-11