We've taken some time recently to discuss how we're going to handle the upgrade from the Workspace contrib module to the Workspace core module, once it's released. In our setup we have around 20 sites, each with 4 (or more) environments, all with Workspace installed, syncing content between each environments (and sometimes between each site). Therefore this is a task we are taking very seriously and want to make sure we have a super stable approach which will result in no loss of production content.
The Workspace entity was first seen in the contrib module Multiversion on 1st June 2014. Back then the entity type was called "Content repository", it was renamed to "Workspace" in September 2014.
On 22nd Febuary 2016 the Workspace module was created, which built upon the Multiversion module.
The Workflow Initiative was announced in Dries' keynote DrupalCon New Orleans.
Over the weekend I decided it was long overdue that I learnt React, or at least understood what all the fuss was about, so with npm in hand I installed yarn and started my quest.
We're going to use Create React App to setup our base React install. First install then run the command to create a react app called "drupal-react":
npm install -g create-react-app
With each release of Drupal 8 more and more things are being deprecated, which is awesome. It shows innovation, forward thinking, and a thought for backwards compatibility. However throwing notices or warnings when deprecated code is used can cause tests to fail. We already counter this a little by adding
<env name="SYMFONY_DEPRECATIONS_HELPER" value="weak_vendors"> to phpunit.xml.dist in core.
To quote the Symfony documentation:
Since Drupal 8 we've had services. This also brought the concept of a service collector or tagged services. This allows services to be tagged with a specific tag, then a service collector can collect all services with the a given tag and use whichever service "applies".
As you could imagine loaded all of these tagged services when loading the service collector service can be a performance nightmare, which is why Drupal 8.4.0 brought us service ID collector functionality.
We have been extremely hard at work this year with the Workflow Initiative bringing some quite big underlying changes to the Entity API and some great advances in core such as the Content Moderation module. There are now around 8 weeks until feature freeze for 8.3.x and there’s still a number of key things we want to get in. Please take a look at our kanban board and see if there’s anything you’d like to take a look at even if it’s just a quick review, a little feedback, or a +1.
At the time of writing this post there are 8 Workflow Initiative issues in Needs Review:
Which core entities get revisions?
We are looking at making more content entities in core revisionable, this will roll out gradually, but which ones should we make revisionable?
Add a content entity form which allows to set revisions
This is mainly an effort by the Media Initiative, but affects the Workflow Initiative too. The idea is to have a generic entity form for revisionable entities.
Add a publishing status field to BlockContent
Shock horror! Block content entities are currently not able to be unpublished. We need to fix this! This will be a pattern for making other things able to be unpublished too.
Upgrade path between revisionable / non-revisionable entities
This patch has had so many iterations but the current one is looking pretty awesome. It will give ups an upgrade path for entity types such as taxonomy terms and menu links to have revisions.
Introduce sorted set key value store
Before we introduce Workspaces in core we want to store a sequence of entity updates, a sorted set key value store will allow us to do this.
Store revision id in originalRevisionId property to use after revision id is updated
There are a number of bugs in core which require us to know what the revision id of an entity object used to be. This issue solves this by adding a simple property.
Introduce a EditorialContentEntityBase class for revisionable and publishable entity types
When we make more entity types revisionable and publishable it’d be great if they all extended the same base class. This issues does this for Nodes, we will then be able to roll it out to Block content once publishable, and other entities once revisionable.
WI: Content Moderation module roadmap
Content moderation is currently in core as an alpha experimental module. How can we get this to beta then stable?
For the last 18 months I have been working full-time on Drupal workflow solutions, first with the Deploy suite of contrib modules, and now with the core Workflow Initiative.
It turns out core is a lot harder than contrib. Everything we have mapped out in the plan for the Workflow Initiative is already done, and working, in the contrib modules. So getting it all in core should be easy, right. Just port over the code from the modules into core APIs or core modules and it’s done. Well… no.
Everything in core needs to be generic, it needs to work for everyone. In contrib you can choose not to use module X if it’s not compatible with module Y, or if it doesn’t work with your use case, in core there is less of that luxury.
Also in core everything has to be done “properly”. We can’t just get a solution that works well enough and run with it, we need to be sure it is the best (or least worse) solution.
Some examples of the issues we are facing so far is with the Upgrade path between revisionable / non-revisionable entities issue. In contrib we use the migrate module to migrate all content out, make entity types revisionable then migrate everything back. For core this is not stable enough so we need a custom set of update hooks. Then Add StatusItem field type to store archived state in contrib we just add a new base field to all entity types to store the archived state. In core there are performance concerns with a new field and new conditions.
Thankfully there are so many people working and thinking about things that will help some of these areas, and as we continue to develop core we should be able to make things easier.
Drupal 8.2.0 will see a bunch of new experimental modules. Once of these is Content Moderation. This is a port of the Drupal 8 release of Workbench Moderation, with a number of updates to make it suitable for core.
Work is currently underway to get Content Moderation working for Workspaces. Workspaces, defined by the Workspace module and it’s dependency Multiversion, are a way of creating different versions of your site’s content and getting the elusive “full site preview” functionality. With Content Moderation you are able to moderate a whole Workspace. Then once published all content will be deployed to the live workspace.
The screencast below shows adding some content on the Stage Workspace and confirming the content doesn’t exist on the Live Workspace. Then publishing the Stage Workspace results in the content being on both Workspaces.
The Workflow Initiative was announced just over a month ago and since then I have been working on the first phases full-time. Here’s what I’ve touched:
When we make everything revisionable we’ll need all entities to get their base fields from the base class. So from 8.2.x all content entities inherit their base fields.
To help people make sensible decisions Node revisions will now be enabled by default.
We got into a pretty annoying issue when trying to add revision fields to entities which already had data because the revision field couldn’t be set to NOT NULL. Andrei wrote an awesome patch to allow an initial from field to be set. We therefore set the revision id as the entity id.
When we make everything revisionable we’ll need an upgrade path, to test this the Shortcut entity is being upgraded to revisionable by a new service. This has still not been committed, so reviews are welcome.
We’re trying to get Workbench Moderation into core as Content Moderation. Still lots to do to make this happen, but the patch is there with passing tests.
Initial work has also started to get an archive field into all entities. This will allow us to have CRAP (create, read, archive, purge) workflow, create a trash system, and replicate entity deletion through environments.