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.
Did you know Drupal 8 has a new system to manage config? sure, everyone does by now.
But, did you know you can validate the import of config? Maybe not, that's a bit more of a hidden gem.