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:
At 12:54pm on January 15th 2008 (based on the created time stamp of "1200401651") I signed up for my Drupal.org account while working for International Baccalaureate. Before my interview there I had never heard of Drupal, but managed to ace the interview and get the job, no idea why I didn't bother signing up for Drupal.org until after I started the job, but hey, that's just how it was. It was jamesfk who introduced me to Drupal there and who I worked with building a bunch of community sites in Drupal 5, then 6.
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.
Last week I switch from years of using Chrome to Firefox 57 because of all the hype about it being fast, and that I'd been suffering from Chrome using up to 10GB of ram. The big issue I hit though was I didn't have Dreditor and there seemed to be no way to install it. I decided to go on using Firefox without Dreditor, and loading Chrome every time I needed to do an in depth patch review.
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?