drupal core

Workspace upgrade path

Submitted by timmillwood on Thu, 07/06/2018 - 10:03

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.

Drupal core Workspace module

Submitted by timmillwood on Fri, 04/05/2018 - 15:46

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.

What is Drupal?

Submitted by timmillwood on Sun, 30/04/2017 - 12:28

In his keynote at DrupalCon Baltimore 2017, Dries talked for some time about how Drupal is now for Ambitious Digital Experiences. There has been a lot of talk over the last few years, especially since Drupal 8 was release, that Drupal is now an enterprise CMS. With this keynote it seems as though Dries is, in a way, acknowledging this. Ambitious Digital Experiences reads as something more complex than a blog, a brochure site, or sites for SMEs.

Core development is frickin’ hard

Submitted by timmillwood on Tue, 06/09/2016 - 14:25

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.