Latest Blog Posts

Deploy: How it'll work in D8

Submitted by Anonymous (not verified) on Tue, 20/10/2015 - 16:40

<p>Over the last 7+ years working with Drupal, one question always asked by clients is, how do I copy my content from staging to production? Generally the answer has been, “Don’t! Just add it on production”. Another option is to use the deploy module, which allows for the deployment of content between environments. </p><!-- more -->

<p>Drupal core has changed greatly in Drupal 8, the deploy module is following suit.</p><p><b><a href="; target="_blank">Multiversion</a><br/></b>The multiversion module will be the foundation of all this change. It introduces three big changes to the way content is managed in Drupal.<br/>Workspaces - All content is associated with a workspace, you can have multiple workspaces and switch between them. Think of them much like branches in version control systems such as git.<br/>CRAP - Create, Read, Archive, and Purge. This is an alternative to CRUD (Create, Read, Update, and Delete). It means that in multiversion no content is deleted and everything is a new revision. Deleting an entity will just archive it, flagging it as deleted.<br/>Revisions for everything - All content entities are revisionable with multiversion module. This means blocks, user, comments etc all have revisions.</p><p><b><a href="; target="_blank">Relaxed</a></b><br/>The relaxed module is a RESTful API which is aligned to the CouchDB API. It exposes each workspace as a Couch database. This allows it to be replicated to another Drupal site running relaxed, to a native CouchDB database, or to something else that uses the same API, such as PouchDB.</p><p><b><a href="; target="_blank">Deploy</a></b><br/>Finally the deploy module. This is now just a UI module as all the the content deployment is handed with external projects. The relaxed module exposes the API needed, a PHP based <a href="; target="_blank">CouchDB replicator</a> uses a PHP based <a href="; target="_blank">CouchDB client</a> to replicate / deploy the content.</p><p>The current plan is to have a “Deploy” button in the Drupal toolbar, this will open a modal where you can choose which site you want to deploy to and which workspace you want to merge into. It will be possible to deploy to a workspace on the current site. For example, a staging site may have two content editors, both working on different workspaces, then can then deploy / merge their content to the default workspace. This default workspace can then be merged up to the production site’s default workspace.</p><p>Tagging is also an idea being worked on. It will allow you to tag a workspace at a current point in time, then continue to edit content. When deploying from a tag it will only merge up changed until the tag was created.</p><p>These are big changes for the deploy module, but something that will make the content workflow a lot easier.</p>

How can we know if a page in Drupal 8 has changed?

Submitted by Anonymous (not verified) on Fri, 02/10/2015 - 15:27

<p>This was a question I got from a client. So I set to work on finding a solution to alert the team who needed to know when a page has changed.</p><p><b>TL;DR</b>: <a href="; target="_blank">CacheTags</a>.</p><!-- more --><p>Drupal has an awesome caching layer. It makes use of cache tags, these tags can be invalidated when something changes. For example if this is a view called “frontpage”, it would output the cache tag &ldquo;view:frontpage&rdquo;. This view lists a bunch of nodes, each with their own cache tag, &ldquo;node:1&rdquo;, &ldquo;node:2&rdquo; etc. When node 2 is edited, it’s cache tag and the frontpage view cache tag would be invalidated.</p><p>Taking this into account if we want to know what pages have changed, we need to know what cache tags the page has, then what cache tags have been invalidated.</p><p>The client already has a crawler to check their sites, this can look at the <code>X-Drupal-Cache-Tags</code> header and capture the cache tags the page has. So all we need now is a way of telling the crawler what cache tags have been invalidated.</p><p>Welcome to the <a href="; target="_blank">CacheTag Notify</a> module. This has a simple settings page where an endpoint URL can be added. Then every time a cache tag is invalidated it gets POSTed to the endpoint as a JSON string. The crawler will then need to to lookup which pages are using the invalidated cache tags, then it knows which have changed.</p><p>The CacheTag Notify module works by adding <code>CacheTagsInvalidator</code> service. The <code>invalidateTags</code> method is passed an array of invalited tags, this is then POSTed to the endpoint url using Guzzle. Overall a very, very simple, but effective solution.</p>

Planning for CRAP and entity revisions everywhere in core

Submitted by Anonymous (not verified) on Wed, 23/09/2015 - 07:46

<figure class="tmblr-embed tmblr-full" data-provider="youtube" data-orig-width="459" data-orig-height="344" data-url=""><iframe width="540" height="405" id="youtube_iframe" src=";enablejsap…; frameborder="0"></iframe></figure><p>At DrupalCon Barcelona this year I presented with <a href="; target="_blank">Dick Olsson</a> outlining a plan for CRAP (Create Read Archive Purge) and revisions (on all content entities) in core.</p><!-- more --><h2>Phase 0</h2><p><b>For Drupal 8.0.0</b><br/>Enable revisions by default (<a href="; target="_blank"></a&gt;) on content types in the standard install profile and when creating new content types.</p><h2>Phase 1</h2><p><b>For Drupal 8.1.0</b></p><ul><li>Improve the Revisions API performance, some of this will come from moving elements from the multiversion module into the entity API.<br/></li><li>Enable revisions by default for all content entity types. So not just nodes anymore but blocks, comments, taxonomy terms etc.</li><li>Introduce a revision hash, parents and tree. Each revision needs to have a parent so you know where it’s come from, each parent can have multiple child revisions.</li><li>Data migration - Moving all 8.0.0 sites to 8.1.0 will mean moving their data to the new revision system.</li></ul><h2>Phase 2</h2><p><b>For Drupal 8.2.0</b></p><ul><li>Remove the ability to not have revisions. To simplify the API and the data stored it makes sense to remove the ability to disable revisions. This will allow us to remove all the conditional code around if an entity has a revision or not.<br/></li><li>Delete is a new flagged revision. When deleting an entity a new revision will be created and this revision will be flagged as deleted. This is the archive element of the CRAP workflow.</li><li>Introduce purge functionality. There may be times when an entity needs to be completely deleted.</li><li>Commit trash module to core. Trash is just a UI for the delete flag. It displays all entities marked as deleted. It then allows these to be restored by creating a new revision not flagged deleted, or purged by removing the entity.</li></ul><p>Simple right?</p>

Trashing Drupal

Submitted by Anonymous (not verified) on Fri, 11/09/2015 - 09:20

<p>At heart Drupal is an awesome CMS. The reason I would advise going for Drupal over any other framework is it’s ability to manage a scalable amount of content entities.</p><!-- more --><p>Earlier this week I discussed <a href="…; target="_blank">revisions in Drupal 8</a>. Specifically the use of <a href="; target="_blank">Multiversion</a> module to allow Drupal to use a CRAP (Create Read Archive Purge) workflow for content management.</p><p>Since then I have been working on the archive and purge aspects of this workflow. The <a href="; target="_blank">Multiversion</a> module is pretty astonishing in how it revolutionises the way revisions are handled and content is managed but so far there has been little focus on the archive and purge process. When entities are deleted they are simply flagged as “deleted”, they exist in the Drupal database but are gone from any where on the site’s UI. Until now&hellip;</p><p>The all-new <a href="; target="_blank">Trash</a> module builds on the <a href="; target="_blank">Multiversion</a> module provide a place where users can see all their deleted entities, listed by entity type, then restore them along with all their revisions. The first commit on the 8.x-1.x branch was only done 3 days ago on September 8th, so it’s still early days, but the MVP is available as a dev release to have a play with.</p><p>Now, this is more or less the archive process working, next up is purge. So what do we purge? Well, ideally, nothing. It’d be great if we never need to truly delete any entities, but instead purge specific revisions. This is something that will be getting a lot of thought over the coming weeks.</p><p>Another step to look at is compaction. <a href="; target="_blank">Multiversion</a> has been following CouchDB’s API and coupled with the <a href="; target="_blank">Relaxed web services</a> module it allows entities to be replicated to CouchDB and other platforms following the same API. <a href="; target="_blank">CouchDB has a notion of compaction</a> via the “_compact” endpoint. How harshly should the content be compacted? remove all revisions apart from the current one?</p><p>All of this will be discussed by <a href="; target="_blank">Dick Olsson</a> and I, in our session <a href="…; target="_blank">Planning for CRAP and entity revisions everywhere in core</a> at <a href="; target="_blank">Drupalcon Barcelona</a>.</p>

Revisions in Drupal 8

Submitted by Anonymous (not verified) on Mon, 07/09/2015 - 09:56

<p>I’m sorry to say that on the surface little has changed with revisions in Drupal 8, but there is some work still being done.</p><!-- more --><p>The first step, for me, is to get <a href="; target="_blank">revisions enabled by default</a>. I was interested to hear from <a href="; target="_blank">webchick</a> that this <a href="; target="_blank">came up indirectly during user testing</a>. Most Drupal sites I have worked on have been large enterprise organisations. These types of companies all want an audit trail and all want to effectively manage their content. This is easily achievable by using revisions. It looks as though many new to Drupal are in a way scared by revisions. Enabling revisions by default will take away the reasoning for being scared and give this awesome feature out of the box.</p><p>The current revisions system isn’t perfect, it’s pretty good, but not perfect. There’s a lot of work being done to improve upon in. In Drupal 7 we had the <a href="; target="_blank">deploy module</a>, which allowed users to move content from one site to another, such as from staging to production, this built upon the existing revisioning platform. In Drupal 8 we have the <a href="; target="_blank">multiversion</a> and <a href="; target="_blank">relaxed web services</a> modules. These were both <a href="; target="_blank">demoed</a> by <a href="; target="_blank">dixon_</a> at <a href="; target="_blank">Drupalcon Los Angeles</a>.</p><p>Although <a href="; target="_blank">multiversion</a> builds upon Drupal 8′s core revision system it’s vastly different with an awesome direction. One key feature is it enables revisions for every entity, users, comments, everything. The way it displays revisions as a tree also makes it clear and understandable as to how the revisons work and how the relate.</p><p>The <a href="; target="_blank">relaxed web services</a> module builds upon a similar ethos as the <a href="; target="_blank">deploy module</a>, but it makes use of an API based on the <a href="; target="_blank"> protocol</a> to handle bi-directional content replication. This means it can replicate content to any other <a href="; target="_blank"> protocol</a> source such as <a href="; target="_blank">couchdb</a> or <a href="; target="_blank">pouchdb</a>.</p><p>Step by step Drupal 8 is getting more amazing.</p><p>To find out more about all this head along to the <a href="…; target="_blank">Planning for CRAP and entity revisions everywhere in core</a> session at Drupalcon Barcelona on Tuesday 22nd September at 11am in room 122-123 “Interoute”.</p>

Update module the next generation

Submitted by Anonymous (not verified) on Wed, 02/09/2015 - 13:48

<p>In a post last week I discussed <a href="…; target="_blank">versioning in Drupal</a> and briefly touched on version numbers in info files. A lot of my focus over the last few months has been around composer and Drupal, one issue for Drupal when using composer for contrib modules is that the info file is pulled from git and therefore doesn’t have the version number, project name or datestamp in the info.yml file that is added by the packager.</p><!-- more --><p>I am <a href="; target="_blank">currently working on a patch</a> for the update module which will get the project name from the module’s composer.json. This is just the first step because the project name is what’s needed for the module to show on the update status page.</p><p>The patch adds a composer parser service, which like the info parser service that parses the info.yml file of a module, this parses the composer.json file of a module. From here we can get the project name such as “drupal/devel”, then by exploding that we can get the project name from the second element in the array.</p><p>Composer.json files sometimes include a version number so we could use that too, but this is vary rare. The only real option for the version number is the git branch or git tag, this is how the <a href="; target="_blank">git deploy module</a> works.</p>

Versioning in Drupal

Submitted by Anonymous (not verified) on Tue, 25/08/2015 - 16:59

<p>Currently Drupal has <a href="; target="_blank">naming conventions</a> for branches and tags in git for contrib module. These are based on the core version then the module version, for example 7.x-1.x would create a dev version 1 for Drupal 7, 7.x-2.3 would create a stable release version 2.3 for Drupal 7.<br/></p><!-- more --><p>As we head towards Drupal 8 there has been a lot of talk about versioning for contrib. Core has already moved to using <a href="; target="_blank">semantic versioning</a> (semver), which is widely adopted by a lot of software now. Contrib is still on the old version numbering format. There is a <a href="; target="_blank">lot of discussion</a> about switching to something like semantic versioning for contrib. It’d be ideal to keep the core version somewhere in the number, there have been many suggestions, some of which are:</p><ul><li>2.3.0-d8<br/></li><li>2.3.0#d8</li><li>2.3.0@d8</li><li>d8.2.3.0</li><li></li></ul><p>My preferred, and it seems the favourite so far is, this is much like semver but the major version has been bumped down to make way for the core version, therefore core.major.minor.patch. The only possible issue here is if using composer for contib modules, composer will think the core version number is the major version number, and it will think the major version number is the minor version number. I feel that this is an ok compromise and we as developers can take this into account when using the syntax in composer.json.</p><p>Another versioning related issue is that we currently add the version number into the contrib info file as part of the packager that creates the module zip or tarball files. If more people pull modules straight from git (via composer) they won’t have this version number, causing the core update module not to work.</p><p>I say we should start asking module maintainers to add the version number to the info file. They already have to add the version number to the tag or branch, surely it’s no extra effort to add it to the info file, and saves so much effort trying to find a fancy programatic solution.</p><p><b>Update:</b><br/>As part of this I have opened <a href="; target="_blank">another issue on d.o</a> to discuss how we can make update module work for modules installed via git (including via composer).</p>