#drupal-planet

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.

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.

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.

Last week I presented the plan for the Drupal Workflow Initiative at DrupalCon New Orleans. Please review the ever evolving plan at: https://www.drupal.org/node/2721129.

Single site content staging with Deploy

This demo shows creating content on a stage workspace then deploying it to live. Once deployed an edit is made on the live workspace and an update is done on stage to pull from live.

Cross site content staging with Deploy

This year I have proposed three sessions for the North American DrupalCon based on the topics I have been working on for the last 9 months.

Please take a look, ask questions, make comments, and share.

Building sites with Composer If you have been keeping up to date with by blog you will notice I have been working a lot with Drupal and Composer. In this session I will share this knowledge and look from a site builders perspective. https://events.drupal.org/neworleans2016/sessions/building-sites-composer

Managing and staging your content In Barcelona and Mumbai, Dick Olsson and I, presented on content management and content staging solutions. We have been continuing to work on improving these solutions and wish to give an updated session in New Orleans. https://events.drupal.org/neworleans2016/sessions/managing-and-staging-your-content

As of 1:23pm GMT on Febuary 3rd 2016 there are no dependencies in the Drupal 8.1.x git branch.

Why?

There was no reason to have them there. It makes the repository bigger, and therefore takes longer to download. No one else does it.

What does it mean?

Not much really.

If you download Drupal via the zip file or tarball then the drupal.org packager will run composer so the dependencies will be there for you.

If you submit a Drupal core patch on drupal.org then DrupalCi testbot will run composer install.

It’s only if you clone Drupal 8.1.x or higher directly from git, you will need to run composer install in the Drupal root directory

Drupal 8 is out, Drupal 8.1 will be out before we know it, but it seems contrib is still catching up. One question that seems to keep coming up is around installing a Drupal 8 module. In this post I will look at the different ways to install a module and resolving dependencies.

Deploy, Search API Solr Search, and Commerce are just a few of the modules with Drupal 8 releases that require dependencies loaded via composer. This means you can’t just download the module’s ZIP file, unzip it in your modules directory, and enable it. You need to install the dependencies.

One simple way to do this is the Composer Manager module. This module has extensive documentation on how to use it. Essentially what it does it merge the composer.json that ships with core and the composer.json files from all the contrib module you have, then downloads the dependencies. You may notice that this will also update core dependencies, but this is a good thing! The core composer.json has been written in such a way that it won’t introduce API breaking dependencies and only uses stable releases. So you will benefit from any bug fixes or security fixes rolled out in these dependencies before they’re rolled out with Drupal.

The two other ways we’re going to look at involve directly using Composer.

Just the dependencies It’s possible to carry on installing Drupal modules exactly as you always have, download the zip or tarball, then unzip it into your modules directory. As mentioned earlier this will not install the dependencies, therefore you will need to look inside the module’s composer.json file, see what the dependencies are, and install them manually. Let’s take Deploy module as an example, this depends on the dev-master version of relaxedws/replicator. So, go to your Drupal docroot and run the command composer require relaxedws/replicator:dev-master. This will add relaxedws/replicator to Drupal’s composer.json, download it, and put it in the vendor directory ready for the module to make use of. This will not change any other other dependencies you have. Then to update the dependencies you can either run composer update to update relaxedws/replicator and all core dependencies or composer update relaxedws/replicator to just update the relaxedws/replicator package.

The module too If you install all you Drupal modules via composer, all of the dependencies will automatically be installed too. First you will need to add a new repository, so run composer config repositories.drupal composer https://packagist.drupal-composer.org in your Drupal docroot, this will add the https://packagist.drupal-composer.org repository to your drupal composer.json. Now you can install any module from Drupal.org via composer. So going back to the example of Deploy you can run composer require drupal/deploy:8.1.0-alpha5 in your Drupal docroot and it will install Deploy in the modules directory. It will also install key_value, multiversion, and relaxed, which are all Drupal modules required by Deploy. Furthermore it will install relaxedws/replicator as we know is a PHP package needed for Deploy, and doctrine/couchdb which is a PHP package needed for releaxedws/replicator.