Darren Mothersele - Drupal Planet Feed Darren Mothersele's Drupal Planet Feed http://www.darrenmothersele.com Introducing Stylex: Atomic design, style guides, and prototyping with Silex and Twig <p>I&#39;ve been working a lot with Atomic design (component-based design) with Drupal recently, and I&#39;ve witnessed huge improvements on projects where it has been introduced. The main advantage being the decoupling of the development of the back-end from the development of the front-end code. </p> <p>I&#39;ve covered this in more detail <a href="http://www.darrenmothersele.com/blog/2015/03/06/atomic-drupal-workshops/">previously</a>, I&#39;m running some workshops on <a href="http://www.darrenmothersele.com/blog/2015/03/06/atomic-drupal-workshops/">Atomic Design in Drupal</a>, and I have more to say on this in the future. Today I want to tell you about a simple tool I&#39;m using to speed up the process. <a href="https://github.com/darrenmothersele/stylex">Stylex</a>.</p> <!--break--> <p>The main purpose of this tool is to simplify the construction of prototype sites or style guides for front-end code. There are several tools already available, including the excellent <a href="http://patternlab.io/">Pattern Lab</a>, but I wanted something incredibly simple. </p> <p>I basically just wanted to make use of the power of Twig templates for mocking up front-end code, with an easy way to load in demo content (from yml files). </p> <h2> Barebones project</h2> <p>I&#39;ve created a <a href="https://github.com/darrenmothersele/stylex-barebones">barebones Stylex project</a> on GitHub that demonstrates this, but you probably want to follow along in the setup, so you know what&#39;s going on...</p> <h2>Basic setup</h2> <p>I&#39;ve packaged this for Composer so getting started is easy. Assuming you already have <a href="https://getcomposer.org/doc/00-intro.md#globally">Composer installed globally</a> all you need to do is create a folder for your project and run the following command:</p> <div class="highlight"><pre><code class="language-text" data-lang="text">composer require darrenmothersele/stylex dev-master </code></pre></div> <p>This will download Stylex from Github and all the dependencies. It creates the <code>composer.json</code> file for you and downloads all the code for the dependencies into a <code>vendor</code> folder. </p> <p>As a bare minimum you will need to create a <code>index.php</code> to run the application, and a starter template <code>templates/index.html</code>. </p> <p>Create a file in the project root (same location as the generated <code>composer.json</code> file) called <code>index.php</code> with the following code:</p> <div class="highlight"><pre><code class="language-text" data-lang="text">&lt;?php require_once __DIR__ . &#39;/vendor/autoload.php&#39;; $app = new Stylex\Application(); $app-&gt;run(); </code></pre></div> <p>Then create a <code>templates</code> folder and create the first page template, <code>templates/index.html</code> in this folder:</p> <div class="highlight"><pre><code class="language-text" data-lang="text">&lt;html&gt; &lt;head&gt; &lt;title&gt;Hello!&lt;/title&gt; &lt;/head&gt; &lt;body&gt; {% block content %} &lt;h1&gt;Hello, world!&lt;/h1&gt; {% endblock %} &lt;/body&gt; &lt;/html&gt; </code></pre></div> <p>You can run the application with PHP&#39;s build in web server. Simply run the following command:</p> <div class="highlight"><pre><code class="language-text" data-lang="text">php -S localhost:8000 </code></pre></div> <p>Now, browse to <code>http://localhost:8000</code> to see the website.</p> <h2>Adding pages</h2> <p>You can add more pages, and make use of Twig&#39;s awesome template inheritance feature. For example, to create an &#39;About us&#39; page, create a new file in the <code>templates</code> folder called <code>about.html</code> with the following content:</p> <div class="highlight"><pre><code class="language-text" data-lang="text">{% extends &#39;index.html&#39; %} {% block content %} &lt;h1&gt;About us&lt;/h1&gt; {% endblock %} </code></pre></div> <p>This inherits the whole template from index.html but replaces the <code>content</code> block with a new block of content specific to this page. Browse to <code>http://localhost:8000/about</code> to see the result (make sure PHP&#39;s web server is running - see above).</p> <h2>Using data</h2> <p>You can create YAML data files and then use them in your templates. Create a folder called <code>data</code> and then add <code>*.yml</code> files with your data. In any template these are then available using the filename. For example, to create a data file for your navigation links, create a file called <code>data/main_menu.yml</code> with the following content:</p> <div class="highlight"><pre><code class="language-text" data-lang="text">- title: Home path: / - title: About Us path: /about </code></pre></div> <p>Because the filename is <code>main_menu.yml</code> this data is now available to read in template files using <code>{{ main_menu }}</code>. Let&#39;s add a component template to style the menu. See my posts on Atomic design in Drupal to find out more about component templates. For now, just create a file in <code>templates/components/menu.html</code> with the following content:</p> <div class="highlight"><pre><code class="language-text" data-lang="text">&lt;ul&gt; {% for item in main_menu %} &lt;li&gt; &lt;a href=&quot;{{ item.path }}&quot;&gt;{{ item.title }}&lt;/a&gt; &lt;/li&gt; {% endfor %} &lt;/ul&gt; </code></pre></div> <p>Now you can include the menu in your page template, by adding the following to your <code>index.html</code> file:</p> <div class="highlight"><pre><code class="language-text" data-lang="text">{% include &#39;components/menu.html&#39; %} </code></pre></div> <h2>Using sample content</h2> <p>Stylex supports creating sample content using Markdown format with YAML front matter. This is a simple way to manage blobs of content with associated metadata. By using Markdown and YAML together to create sample content you can keep the sample content out of your front-end mockups and prototypes. This is another useful decoupling that makes life easier. </p> <p>In this approach sample content is stored in subfolders under a <code>content</code> folder. You can have multiple types of content, and organise them into subfolders under a main <code>content</code> folder. Let&#39;s create a first article as an example. First create your <code>content</code> and then <code>content/articles</code> folder, then create a sample file called <code>content/articles/first_post.md</code> with the following content:</p> <div class="highlight"><pre><code class="language-text" data-lang="text">--- title: My First Post excerpt: Lorem ipsum dolor sit amet, consectetur adipisicing elit. image: http://placebee.co.uk/640x480/1 --- Lorem ipsum dolor sit amet, consectetur adipisicing elit. Voluptas ipsam veritatis officia unde incidunt doloribus veniam eligendi ea maiores delectus excepturi aspernatur illum, voluptates quas odit harum cupiditate cum maxime... </code></pre></div> <p>See the <a href="https://github.com/darrenmothersele/stylex-barebones">Stylex Barebones</a> for the full example, I&#39;ve abbreviated the content here. The main point is to show how you can include YAML metadata above the main Markdown formatted content.</p> <p>You can then reference this content from your templates. For example, to print out the title of that first post you created, use the following in your Twig template:</p> <div class="highlight"><pre><code class="language-text" data-lang="text">{{ content.articles.first_post.title }} </code></pre></div> <p>Or, more useful, print out the titles of all articles:</p> <div class="highlight"><pre><code class="language-text" data-lang="text">{% for post in content.articles %} &lt;h2&gt;{{ post.title }}&lt;/h2&gt; {% endfor %} </code></pre></div> <p>Or, yet even more useful (if you&#39;re building an atomic design), output all the articles using a component template: </p> <div class="highlight"><pre><code class="language-text" data-lang="text">{% for post in content.articles %} {% include &#39;components/teaser.html&#39; with post only %} {% endfor %} </code></pre></div> <p>For this to work, create a component template for the <code>teaser</code> by creating a <code>templates/components/teaser.html</code> file with the following content:</p> <div class="highlight"><pre><code class="language-text" data-lang="text">&lt;div class=&quot;teaser&quot;&gt; &lt;h2 class=&quot;teaser-title&quot;&gt; {{ title }} &lt;/h2&gt; &lt;img src=&quot;{{ image }}&quot; alt=&quot;&quot; class=&quot;teaser-image&quot;&gt; {{ content|raw }} &lt;/div&gt; </code></pre></div> <p>You can create subfolders to organise different types of sample content, for example, add an events folder <code>content/events</code> and they will be available in your templates as <code>{{ content.events }}</code></p> <h2> Debugging</h2> <p>If you&#39;re getting error messages, you can turn on debugging. In the <code>index.php</code> file that you created simple add the following line before <code>$app-&gt;run();</code></p> <div class="highlight"><pre><code class="language-text" data-lang="text">$app[&#39;debug&#39;] = TRUE; </code></pre></div> <h2>Conclusion</h2> <p>This just does the basics to allow you to use Twig templates to quickly build out front-end code. It reads in sample content and data from yml files and allows you to easily combine them with template files to create a prototype site. </p> <p>The next step is to reset Drupal&#39;s markup and get it generating the exact same markup. This is covered more in my <a href="http://www.darrenmothersele.com/blog/2015/03/06/atomic-drupal-workshops/">Atomic Design in Drupal</a> workshops. </p> <p>You&#39;ll probably want to add your favourite front-end tools into this. In particular, I like to add a Gruntfile to do less/sass compilation, etc. </p> <p>Drop me a line if you find this useful, or have any ideas for how it can be improved. </p> <p>Thanks!</p> <p>Darren</p> Fri, 20 Mar 2015 00:00:00 +0000 http://www.darrenmothersele.com//blog/2015/03/20/stylex-prototype-style-guide-tool http://www.darrenmothersele.com//blog/2015/03/20/stylex-prototype-style-guide-tool Atomic Drupal Workshop <p>If you&#39;re a frustrated web developer spending more time battling with Drupal than enjoying its benefits then read on, as I&#39;m going to explain how I&#39;ve hacked the Drupal site building process to make it easier and more fun.</p> <!--break--> <p>I started exploring this process a couple of years ago. After years of Drupal experience, with it&#39;s ups and downs, something clicked. I thought I was in control before, but there would always be some part of a project where I felt like I was fighting with Drupal. I tried many different approaches, but once I found this methodology there was no looking back.</p> <p>I&#39;ve been developing this system for a couple of years, and in recent months I&#39;ve started to see more people talking about it, conference sessions, and blog posts that talk about some of these ideas. None of this is unique, but I have pulled together various elements into a process, or system that anyone can use to simplify their Drupal site building.</p> <p>In this article I hope to bring together a few key points that I think make the most difference to the success of a project.</p> <p>My work in the past year has taken me into many agencies and I&#39;ve worked with experienced Drupal developers, and with excellent developers but who were new to Drupal. On the one hand I&#39;ve seen Drupal developers artificially constrained to produce &quot;Drupaly&quot; solutions because of perceived limitations of what&#39;s possible with Drupal, and on the other hand I&#39;ve seen developers struggle to get Drupal to do what they want to do.</p> <h2>Perhaps you can relate to this story...</h2> <p>I went into an agency early last year to help with a late running project. There was nothing particularly unique about this website, other than it had some really nice design elements and was a stunning example of responsive design. But, hiding below the surface was a confusing Drupal implementation and a mess of spaghetti code.</p> <p>Several developers had worked on the project, and it showed. Competing Drupal modules were being used to achieve the same thing in different parts of the site, the CSS used multiple grid systems, and the general lack of consistency meant the final stages of the project, bug fixing and cross device testing were proving difficult.</p> <p>Requirements and designs had changed during the project, and so had the developers, which meant that rather than understand what had been done before, the developers hacked on extra bits of code, put in more and more CSS overrides to target specific elements to tweak the styles.</p> <p>The result was a site that was proving impossible to get working across all devices, and as bugs were fixed, more were being introduced and discovered. Slight changes were having unexpected knock on effects across the whole site.</p> <p>When I looked at the site, I congratulated them. They had produced a great prototype. They had gone a long way around to get there, but what they had done was understand the problem, and discover exactly what was required in a solution. This resulted in something that worked really well as a prototype. What they hadn&#39;t done was produce a production-ready site.</p> <p>I helped them take a few steps back, which at the same time was a huge leap forward. With the knowledge they had gained we could work with Drupal to get the project completed, rather than battling against it.</p> <h2>What to learn from this?</h2> <p>Consistency is important, and prototyping helps to clarify what is required in a solution. Doing all the testing and bug fixing at the end of a project is hard, gets out of control, and causes missed deadlines.</p> <h2>Introducing Atomic Drupal</h2> <p>I&#39;ve been looking at the emerging atomic design movement, component-based design, or style-guide driven development, and I&#39;ve taken best practise from the cutting edge of web design and combined it with over 7 years experience of pushing Drupal to it&#39;s limits and past them.</p> <p>Where I&#39;ve ended up is a system for converting ideas into effective websites. A way of working with Drupal rather than against it, with the aim of shifting the focus of a project from development and bug fixing to solving new and interesting problems. Making the basics of site building easy and fun.</p> <p>People I&#39;ve introduced to this already have found they can now do more with Drupal and say yes to more of clients requirements, and work on more interesting projects.</p> <h2>Atomic Design</h2> <p>A component-based approach to the front end means creating more maintainable and flexible designs. There are a few tricks to getting this to work in Drupal, but the most important are: taking full control over Drupal&#39;s markup, and planning out a consistent approach to building the site.</p> <h2>Prototyping</h2> <p>An added benefit of taking a component-based approach is the decoupling of front-end design and development from the back-end CMS implementation. The biggest win is that you can build and test all your front-end code separately to the CMS build (you&#39;re not constrained to using Drupal&#39;s markup). This means you can test and validate your front-end code early on in the project, you can test across devices and browsers earlier in the process, and therefore not leave all your big fixing until the end of the project.</p> <h2>Workshop</h2> <p>Get in touch if you&#39;re interested in learning more as I am running workshops on Atomic design with Drupal for agencies and individual developers. Check my training page to see upcoming dates for public courses (at the time of writing the next scheduled public workshop is 24th April).</p> <p>This workshop will cover how to take full control over Drupal&#39;s markup, resetting and removing Drupal&#39;s own markup and replacing it with your own. How to work with Atomic design and component based design principles in Drupal. Debunking the most common myths around Drupal front end code, and fixing the single biggest cause for late running projects and missed deadlines.</p> <p><a class="btn btn-primary" href="https://www.eventbrite.co.uk/e/atomic-drupal-workshop-tickets-16052157435">Book Ticket</a> <a class="btn btn-primary" href="https://www.eventbrite.co.uk/e/atomic-drupal-workshop-tickets-16052157435">More info</a></p> Fri, 06 Mar 2015 00:00:00 +0000 http://www.darrenmothersele.com//blog/2015/03/06/atomic-drupal-workshops http://www.darrenmothersele.com//blog/2015/03/06/atomic-drupal-workshops The Drupal Site Builder Manifesto <p>I wanted to get some clarity on what I mean by the term &quot;site builder&quot;. In a general sense, it refers to the actual process of building a website, but in Drupal the term Site Builder tends to have a specific meaning. I realised that my definition may vary from others so I wanted to be precise about what I think it means, and what I think it means to be a Drupal Site Builder.</p> <!--break--> <p>I am a developer. I studied programming languages in depth. I did research into the semantic analysis of object oriented languages. But, when it comes to Drupal, I love to be a Site Builder.</p> <p>I run a <a href="http://www.meetup.com/london-creative-coding/">Creative Coding Meetup</a> in London. At last night&#39;s meeting I was explaining Friday&#39;s <a href="http://www.darrenmothersele.com/blog/2015/02/05/drupal-training-drupalcamp-london/">Drupal Camp training</a> to someone. I am clear about the aims and objectives of the training, I know my material, and I&#39;ve given similar trainings many times before, but, the fact I labelled it an &quot;intermediate&quot; and &quot;site builder&quot; training causes some confusion.</p> <p>First of all, I realised that using the word &quot;intermediate&quot; doesn&#39;t really mean anything. Drupal developers (or anyone building Drupal sites) of all skill levels have benefited from this training. So, perhaps what I mean by &quot;intermediate&quot; is actually &quot;not beginner&quot;. As all I am really saying is that I&#39;m not covering the very basics of getting Drupal up and running.</p> <p>The term &quot;site builder&quot; is more problematic, possibly because my definition of a Drupal Site Builder may be wider than what most people expect. I thought about this a lot, and what I came up with was a clear set of statements of what I think it means to be a Drupal Site Builder...</p> <h2>The Drupal Site Builder Manifesto</h2> <p><img src="http://www.darrenmothersele.com/img/site-builder-sm.png" alt="Drupal Site Builder"></p> <p>As Drupal Site Builders...</p> <p>We work in a multi-disciplinary role.</p> <p>We take initiative, and play a central role in the web development process.</p> <p>We are usually the ones to take ownership of the final product.</p> <p>We don&#39;t just “click and configure” websites. We have knowledge of all the areas involved in building a Drupal website.</p> <p>We work with the rest of the team to ensure everyone is doing what they do best and contributing to the project in a meaningful way.</p> <p>We may not all be trained developers, but we do appreciate how to think like a developer. We apply software development principles and Drupal best practises when creating Drupal configuation.</p> <p>We may not all know how to write optimal PHP code, but we know when to build something using Drupal core or contributed modules, and when we need a custom plugin or custom module creating.</p> <p>We may not all be able to produce the most stunning web designs, but because we understand how Drupal works we will work with designers to ensure their designs are consistent and well structured.</p> <p>We may not all know all the latest front-end tricks, but when given well build front-end code we know how to get Drupal to generate the appropriate markup.</p> <p class="lead">Most importantly, we know how to get the best results out of Drupal's building blocks, we know how to turn good designs and ideas into great websites, and we know how to build websites in a methodical, flexible, and maintainable way.</p> Thu, 26 Feb 2015 00:00:00 +0000 http://www.darrenmothersele.com//blog/2015/02/26/drupal-site-builder-manifesto http://www.darrenmothersele.com//blog/2015/02/26/drupal-site-builder-manifesto Drupal Site Builder Patterns - The State Machine <p>In this new series for my blog, I&#39;ll be documenting some common design patterns for Drupal site builds. This first post is about the State Machine pattern, which is something I&#39;ve used on several sites recently.</p> <p>First, let me explain what I mean by &quot;pattern&quot;. If you are already familiar with design patterns in Object-oriented software then you can probably skip this bit, but I think it&#39;s useful for context.</p> <!--break--> <h3>Design patterns?</h3> <p>Here&#39;s a quote from the original <a href="http://en.wikipedia.org/wiki/Design_Patterns">Gang of Four book</a> on design patterns. That book is about design of object-oriented software, but I think it applies to Drupal development too. The quote is from p.1 of the book, apologies if I offend anyone by bastardising it. I&#39;ve taken the liberty of substituting the words &quot;Designing object-oriented software&quot; with &quot;building Drupal sites&quot;, and a few other substitutions to make my point...</p> <blockquote> <p>[Building large maintainable Drupal sites] is hard... Your design should be specific to the problem at hand but also general enough to address future problems and requirements [and be maintainable]... Experienced [Drupal site builders] will tell you that a reusable and flexible design is difficult if not impossible to get &quot;right&quot; the first time.</p> <p>Yet experienced [Drupal site builders] do make good designs. Meanwhile new [site builders] are overwhelmed by the options available and tend to fall back on non-[Drupal] techniques they&#39;ve used before. It takes a long time for novices to learn what good [Drupal site building] is all about. Experienced [site builders] evidently know something inexperienced ones don&#39;t. What is it?</p> <p>One thing expert [site builders] know NOT to do is solve every problem from first principles. Rather, they <strong>reuse solutions that have worked for them in the past</strong>. When they find a good solution, they use it again and again. Such experience is part of what makes them experts.</p> </blockquote> <p>So I&#39;ve been looking at what these &quot;good solutions&quot; are that I might have been using, and as I identify them I&#39;ve been documenting them along the same lines of the original design patterns from the Gang of Four book:</p> <ul> <li>Pattern name - the handle we use to describe the problem</li> <li>Problem - explain the problem and its context, and when you might want to use this pattern</li> <li>Solution - describe the elements that make up the solution, in my case how the pattern can be best implemented in Drupal</li> <li>Consequences - results and trade-offs of using the pattern, in this case I also consider further issues that many need to be considered as a result of using the pattern.</li> </ul> <p>So, first let&#39;s look at what a state machine is, and what problems it solves, before going on to look at how to configure it in Drupal.</p> <h3>State Machine</h3> <p>A state machine is a theoretical computer science concept that provides a <a href="http://blog.markshead.com/869/state-machines-computer-science/">mathematical basis for modelling computation</a>. But don&#39;t worry, the kind of state machines we&#39;ll be using don&#39;t require a degree in computer science to understand.</p> <p>All you really need to know is that the state machine (or more correctly a <a href="http://en.wikipedia.org/wiki/Finite-state_machine">Finite State Machine</a>) has a finite number of &quot;states&quot; it can be in and the machine is only ever in one of these states at a time, it&#39;s <em>current state</em>. The state machine can change from one state to another triggered by an event or condition. This change of state is called a <em>transition</em>. A state machine is typically visualised using a <em>state machine diagram</em>, for example:</p> <p><img src="http://darrenmothersele.com/img/state-machine/diagram1.png" alt="Simple state machine"></p> <p>As you can see the states are represented by an ellipse with the name of the state inside, the arrows denote the possible transitions. You can also see how the entry point and exit point would be notated.</p> <p>Here&#39;s a (very simplified) example of a ticket in an agile issue queue. In reality this would probably have several other states but for the sake of this example, here&#39;s a simple state machine for the ticket:</p> <p><img src="http://darrenmothersele.com/img/state-machine/diagram2.png" alt="Example state machine"></p> <p>A state machine is defined by the list of possible states and the event/condition that triggers each transition.</p> <p>If you&#39;re reading this and thinking &quot;Events&quot;, &quot;Conditions&quot;, sounds a bit like Drupal Rules, then you&#39;ve already worked out how we&#39;re going to implement this in Drupal!</p> <p>In this simple ticket example the states are &quot;In progress&quot;, &quot;Approval&quot;, and &quot;Finished&quot;. The transitions are &quot;Completed&quot;, &quot;Rejected&quot;, &quot;Accepted&quot;.</p> <h3>When to use it?</h3> <p>It might be useful to think that in business speak, when they say &quot;business processes&quot; they are actually talking about state machines. Here are some cases when you might want to think about state machines:</p> <ul> <li>If you&#39;ve ever had to model a &quot;state&quot; or &quot;status&quot; field, then you&#39;ve got a good candidate for a state machine.</li> <li>If you&#39;ve ever wanted to anything more complex than just published and unpublished nodes then you have a good candidate for using a state machine.</li> <li>If you have boolean fields in your content model called things like &quot;paid/unpaid&quot;.</li> <li>If you have records that need to expire after a specific period of time</li> </ul> <p>Drawing out a state machine diagram to model this kinds of problems can be really useful to help identify any &quot;edge-case&quot; scenarios you may not have thought of, and capture them early in the design process. It also shows you exactly what you need to test further along in the site build.</p> <h3>Let&#39;s build it</h3> <p>As with anything in Drupal there are several ways to achieve this functionality, in fact there&#39;s even a <a href="https://drupal.org/project/state_machine">State Machine</a> module, but that relies on creating custom plugins. If you&#39;re a developer you might want to take a look at this module.</p> <p><a href="https://drupal.org/project/workbench_moderation">Workbench Moderation</a> and various other workflow modules include a state machine implementation for a specific purpose.</p> <p>The approach documented here is suitable for site builders, is flexible, and provides a neat solution that can be configured using the following contributed modules:</p> <ul> <li><a href="https://drupal.org/project/rules_link">Rules Link</a></li> <li><a href="https://drupal.org/project/field_permissions">Field Permissions</a></li> </ul> <p>I said before that the state machine is defined by it&#39;s set of possible states and set of transitions. In Drupal we&#39;ll be using a simple list field to store the list of possible states for the node.</p> <p>In a <a href="http://drupalize.me/blog/201404/hiding-form-fields-drupal-8">recent post</a> on Drupalize.me they mention the addition of the ability to hide form fields in Drupal 8 core. In Drupal 7 we need a module to help us do this. In this case we are adding a field that will never be directly edited by the user so we just deny access to edit that field using the <a href="https://drupal.org/project/field_permissions">Field Permissions</a> module.</p> <p>For the simple ticket example, we have 3 states. So use an integer list field with the following allowed values:</p> <ul> <li>0|In progress</li> <li>1|Awaiting approval</li> <li>2|Finished</li> </ul> <p>I said that the state machine was defined by the set of possible states (implemented by our list field), and a set of transitions. These transitions can be implemented using the <a href="https://drupal.org/project/rules_link">Rules Link</a> module.</p> <p>Using the Rules Link module you can add a button to the ticket node which manipulates the &quot;state&quot; value preventing the user from actually editing the value in the state field directly, and thus enforcing the workflow defined in our state machine.</p> <p>Each &quot;Rules link&quot; is configured in two parts. First you define the conditions for when the link should be visible using standard Rules conditions. Secondly, you use the rules reaction to set the value of the state field to the new value (and perform any other actions that you want as a side effect of the transition).</p> <h3>Considerations</h3> <p>It&#39;s good to follow a principle of audit-ability, so you probably need to keep the transition history. A simple solution might be to add a timestamp field such as &quot;confirmed at&quot; to mark when it went to confirmed state. If using node, you could log revisions to track state changes in the revision log for the node. Or you could look at Messages module to log messages when state changes happen.</p> <h3>More patterns</h3> <p>If you&#39;re interested in learning more from my 7 years of Drupal experience (and if you&#39;re based in London) why not join me for <a href="http://www.eventbrite.com/e/everything-i-know-about-drupal-2-day-intensive-drupal-training-course-tickets-11153411153?aff=state">Everything I Know About Drupal</a> an intensive 2-day Drupal training I&#39;ve been working on. It&#39;s taken a lot of preparation, and there&#39;s still a small number of tickets available. You can find more information on my <a href="http://darrenmothersele.com/blog/2014/04/15/drupal-training-london/">blog post</a> about it or grab a ticket on <a href="http://www.eventbrite.com/e/everything-i-know-about-drupal-2-day-intensive-drupal-training-course-tickets-11153411153?aff=state">the Eventbrite page</a>.</p> Wed, 23 Apr 2014 00:00:00 +0100 http://www.darrenmothersele.com//blog/2014/04/23/drupal-patterns-state-machine http://www.darrenmothersele.com//blog/2014/04/23/drupal-patterns-state-machine I Don't Use Recruitment Agents <p>I started working with Drupal full time in 2007. I knew back then I was on to a winner, as none of the other open-source systems I evaluated at the time offered the same power and flexibility. It took a while for mainstream web development community to catch on, but over the years the Drupal community has seen massive growth, and now Drupal powers some of the biggest sites on the internet, well over 1 million websites.</p> <p>But, this success brings problems, and one recurring complaint I&#39;ve heard over the years has been about the difficulty in finding top Drupal talent. This has made Drupal a prime target for recruitment agencies deception and dirty tricks.</p> <!--break--> <p>Wunderroot are a well known company in the Drupal world, and are known to be a good employer. As UK MD, Steve Parks, says in his blog <a href="http://wunderroot.co.uk/blog/we-dont-use-recruitment-agents">We Don&#39;t Use Recruitment Agents</a></p> <blockquote> We would really love to be able to use recruitment agencies — imagine: a team of people with genuine experience in hiring great staff, with fantastic contacts books, and taking the role of a trusted friend to guide us through advertising, filtering, selecting and engaging the right people. It'd be fantastic. We'd pay good money for that. <strong>Unfortunately, that's not how most recruitment agencies work in reality.</strong> </blockquote> <p>I have experience with working with recruitment consultants from both sides. Before I started freelancing in Drupal full time I was running a digital music startup. As a successful startup we experienced fast growth, and didn&#39;t have the resources in-house to do thorough candidate searches. We used a couple of recruitment consultants and were consistently disappointed. Candidates were misrepresented, to the point where one didn&#39;t recognise his own CV in an interview.</p> <p>On the other side, as a candidate, I do not use agencies for work. One experience in particular put me off for many years.</p> <p>I interviewed for a position, but decided after the first interview that, although the opportunity was interesting, I knew I was not the right candidate. The company wanted to invite me back for a second interview, but I told the consultant that I was not interested, and explained my reasons. Unfortunately, the consultant would not take no for an answer, and I was subjected to a week of harassment (to the point of bullying) over my decision.</p> <p>In <a href="http://wunderroot.co.uk/blog/we-dont-use-recruitment-agents">We Don&#39;t Use Recruitment Agents</a>, Steve Parks tells of a &quot;bait and switch&quot; operation where developers had been approached by recruitment agencies saying that they had been engaged by Wunderroot to headhunt (the bait) in order to get someone interested, but then saying the position was filled and proposing other positions (the switch).</p> <p>I&#39;m not sure if it&#39;s the same dirty tactic in operation, but I have heard in the past of an employer receiving my CV from an agency claiming to represent me. The employer knew me directly, so checked, and they had an out-of-date CV that I had given to the agency for a different opportunity previously. This came up in conversation at a Drupal meetup and it was suggested that this is probably not a mistake as other developers had heard of it happening too.</p> <p>The extreme of recruiters&#39; tricks are documented in <a href="http://web.archive.org/web/20120601080215/http://www.kernelmag.com/scene/2133/consol-yourself-with-this-one/">this old post</a> from Kernel Mag in which Consol Partners are accused of &quot;telling outrageous lies to candidates and start-ups&quot;.</p> <p>In a post on <a href="http://www.ere.net/2013/12/16/the-top-25-recruiting-trends-problems-and-opportunities-for-2014-part-2-of-2/">recruiting trends</a> ERE suggest that, in an era when candidate sourcing is becoming easier as everyone is &quot;findable&quot; on the internet, recruiters should &quot;shift toward improving the various selling components of recruiting&quot;. I&#39;m not sure exactly what they mean by &#39;<em>selling components</em>&#39; but I would beg recruitment agencies not to do this, and instead focus on providing <em>value</em>.</p> <h3>Recruiters - Do This:</h3> <p>Here&#39;s a short TODO list for recruiters:</p> <ul> <li>Clean up your industry: Get rid of the deception and bullying.</li> <li>Provide genuine value (c.f. Steve Parks quote above).</li> </ul> <h3>Until then...</h3> <p>If you&#39;re a reputable company looking to source Drupal developers, or you are a Drupal developer working in London or the UK, get in touch. I&#39;m starting a free job board on <a href="http://www.drupaldeveloper.co.uk/jobs">DrupalDeveloper.co.uk</a>.</p> Mon, 14 Apr 2014 00:00:00 +0100 http://www.darrenmothersele.com//blog/2014/04/14/no-recruiters http://www.darrenmothersele.com//blog/2014/04/14/no-recruiters Drupal Theme Generator Update <p>It&#39;s been a week now since I demoed my proof-of-concept for an automated theme generator at the Drupal show and tell event so I thought I&#39;d collect together the feedback I&#39;ve received so far and post an update.</p> <!--break--> <h3>Wrong Approach?</h3> <p>Almost unanimously positive feedback. In fact, it seems other people have been thinking along similar lines:</p> <blockquote class="twitter-tweet" lang="en-gb"><p><a href="https://twitter.com/mothersele">@mothersele</a> dude! just saw <a href="http://t.co/GyV2m41eUe">http://t.co/GyV2m41eUe</a> This is something that <a href="https://twitter.com/jenlampton">@jenlampton</a>, <a href="https://twitter.com/mortendk">@mortendk</a>, <a href="https://twitter.com/Cottser">@Cottser</a> and I have discussed for 8.x twig!</p>&mdash; Mark Carver (@mark_carver) <a href="https://twitter.com/mark_carver/statuses/450016685752201216">March 29, 2014</a></blockquote> <p>The one opposing view I have encountered wasn&#39;t actually against any of the ideas in the theme generator, but suggested that taking over Drupal markup was wrong and that we should be working with what Drupal provides. I know there are arguments for this, and if you want to go this route then you will need some other mechanism for documenting the conversion of your design to Drupal theme. If you want to argue this case, I&#39;d suggest first try having that discussion with <a href="https://twitter.com/mortendk">Morten</a>, as I&#39;m going to assume that we&#39;re all OK with the concept of taking complete control of (completely rewriting) Drupal&#39;s markup output.</p> <h3>Annotation</h3> <p>In an earlier prototype I had started working with annotations inside HTML comments but I found these increasing harder to parse as the extractions became more sophisticated. Someone in conversation brought up ideas from KSS and suggested looking at CSS comments as an alternative.</p> <p>I&#39;m still proposing this as a possible approach (see <a href="https://en.wikipedia.org/wiki/Docblock">Docblock</a>), but for now I&#39;m going to continue to annotate the markup (not the CSS) with x- attributes, as no one has had an issue with this, and at this stage it&#39;s easier to work with QueryPath to create the extractions based on these attributes. It seems that annotating the markup with x- attributes will be acceptable as long as they are stripped from the markup during the build process.</p> <blockquote class="twitter-tweet" lang="en-gb"><p><a href="https://twitter.com/rootwork">@rootwork</a> <a href="https://twitter.com/illepic">@illepic</a> <a href="https://twitter.com/micahgodbolt">@micahgodbolt</a> <a href="https://twitter.com/EvanLovely">@EvanLovely</a> <a href="https://twitter.com/mothersele">@mothersele</a> Interesting! Do the data attributes get stripped out during the build step?</p>&mdash; Brad Frost (@brad_frost) <a href="https://twitter.com/brad_frost/statuses/449662512624328704">March 28, 2014</a></blockquote> <p>It was great to get feedback from <a href="http://bradfrostweb.com/">Brad Frost</a> as his work on Atomic Design has been influential in the development of this process.</p> <h3>In code, or config</h3> <p>In this first proof-of-concept, the generated theme is held in memory, well actually it is persisted as a Drupal variable containing a single object that holds the result of all the &#39;extractions&#39; from the source. The original intention was that this would actually be a ctools exportable, so that it could be exported and managed as part of the configuration management process for the site.</p> <p>This is how the Panels flexible layout builder works. It has one parent layout plugin that programmatically declares child layout plugins based on the layouts you define using the layout builder tool. These child layouts are stored as exportable objects, so they can be exported using <a href="https://drupal.org/project/features">Features</a>. The current Hyde theme generator approach is similar, except that the parent plugins (for layout or styles) programmatically declare child layout and style plugins based on the result of each extraction from the HTML source design.</p> <p>Storing the result of the build in configuration or database raised some concerns, mainly over capturing the results in version control. These tweets summarise the issue:</p> <blockquote class="twitter-tweet" lang="en-gb"><p><a href="https://twitter.com/mothersele">@mothersele</a> interesting implementation. But I believe that should definitely generate theme in code, not just DB&#10;<a href="https://twitter.com/mcjim">@mcjim</a> <a href="https://twitter.com/MattFielding">@MattFielding</a></p>&mdash; Tom Bamford (@waako) <a href="https://twitter.com/waako/statuses/449539868411322368">March 28, 2014</a></blockquote> <blockquote class="twitter-tweet" lang="en-gb"><p><a href="https://twitter.com/waako">@waako</a> If a prototype is always in sync with a Drupal theme, the markup *is* all in code right? // <a href="https://twitter.com/mothersele">@mothersele</a> <a href="https://twitter.com/mcjim">@mcjim</a></p>&mdash; Matt Fielding (@MattFielding) <a href="https://twitter.com/MattFielding/statuses/449551562344386560">March 28, 2014</a></blockquote> <p>Matt picks up on my original intention, in that the design/theme would be captured in code and be version-able because the translation is automatic from the design&#39;s HTML/CSS/JS.</p> <p>The difficulty is in managing any changes that happen to the generated code once it becomes a Drupal theme. This is exactly the problem that using the theme generator is trying to solve. That it provides a documented, repeatable conversion process, so that design can become part of the (agile) development workflow.</p> <p>However, it is going to be unavoidable that some tweaking will be needed. This covers a couple more issues that were raised at the Drupal show-and-tell event:</p> <ul> <li>How to manage logic in template files?</li> <li>How to capture Drupal&#39;s pre-process functions?</li> </ul> <p>The approach I am looking at to solve this, is one I&#39;ve seen practised by other tools that involve code generation. For example, have you seen BDD using <a href="http://behat.org/">Behat</a>? When define a test scenario in Behat it generates stub code for any unrecognised steps in your tests. For example, if you say &quot;Given I am in a directory&quot;, you would get the generated stub code:</p> <div class="highlight"><pre><code class="language-text" data-lang="text">/** * @Given /^I am in a directory &quot;([^&quot;]*)&quot;$/ */ public function iAmInADirectory($argument1) { throw new PendingException(); } </code></pre></div> <p>I think the theme generator could do something similar for elements marked as requiring pre-processing in the template file. This needs some further thought and perhaps a couple of experiements.</p> <h3>Terminology</h3> <p>Still struggling with naming conventions. If this is going to be a more general tool then need generally understandable terms (like &#39;component&#39;). But, need to avoid overloading terms even more, as it&#39;s already quite confusing having SMACSS modules, Drupal modules, panels, blocks, boxes, styles, layouts. urgh!</p> <h3>Next steps...</h3> <blockquote class="twitter-tweet" lang="en-gb"><p><a href="https://twitter.com/mothersele">@mothersele</a> <a href="https://twitter.com/mark_carver">@mark_carver</a> I love it. Also love that it works w/ panels! Q: Are the layout plugins placed in the theme? <a href="https://twitter.com/mortendk">@mortendk</a> <a href="https://twitter.com/Cottser">@Cottser</a></p>&mdash; Jen Lampton (@jenlampton) <a href="https://twitter.com/jenlampton/statuses/450703701263388672">March 31, 2014</a></blockquote> <p>So, I&#39;m going to revise the current proof-of-concept and produce a second prototype. This time as a Drush command that generates an actual Drupal theme. Rather than holding the extracted theme in configuration it will generate a theme folder, that will include all the usual Drupal theme files, plus any plugins for Panels layouts, styles, display suite etc, and the CSS/JS copied across from the source design.</p> <p>This will allow Hyde to generate stub code for pre-processing or other programmatic tweaks that are needed to get Drupal&#39;s output to match the design markup. I also think people will be more accepting of this approach as it&#39;s probably more like how it is expected to work.</p> <p>My worry is that people will then hack the generated theme, it will go out of sync with the source design markup, and that will break the whole process.</p> <p>If you want to get involved, please drop me a line. I need input from designers, themers, and developers. In particular, I&#39;d be interested to speak to anyone else already using Atomic Design and/or SMACSS on Drupal projects.</p> Fri, 04 Apr 2014 00:00:00 +0100 http://www.darrenmothersele.com//blog/2014/04/04/drupal-theme-generator-update http://www.darrenmothersele.com//blog/2014/04/04/drupal-theme-generator-update Drupal Theme Generator Demo <p>I&#39;ve been playing with the idea of automatically generating Drupal themes from static HTML/CSS/JS using annotations in the HTML markup. I put together a basic proof-of-concept of a tool to generate a Drupal theme, ctools layout and style plugins, and view modes and templates.</p> <p>Last night at the <a href="http://www.drupalshowandtell.com/">Drupal Show and Tell</a> event in London I gave a live demo of the theme generator in action. The event was recorded, so will be online eventually, but for now I&#39;ve recorded this demo as a couple of attendees suggested this would give a better idea of the detail that couldn&#39;t be seen on the screen during the live demo.</p> <!--break--> <p>My interest in this area came about through wanting to bring design into the development workflow of an agile project, and move away from the &#39;throw it over the fence&#39; mentality in design deliverables. You can read more about how this came about in my previous blog post <a href="http://darrenmothersele.com/blog/2014/03/12/automatic-drupal-theme-generation/">Death of the Themer</a>.</p> <h3>Assembly, not Deconstruction</h3> <p>Traditionally implementation of a design was done via a process of deconstruction from a PSD into flat HTML and CSS, and then another process of deconstruction in CMS implementation of the design. You can&#39;t design a responsive site in Photoshop so luckily this is changing. PSDs were horrible to work with as amends take far too long, and while Photoshop may be good to quickly mock up style ideas, pages designed in Photoshop tend rely too much on intuition, implications about how things would work, and tend to come with an implied &quot;you get the idea&quot;.</p> <h3>Atomic Design</h3> <p>As I&#39;ve mentioned in earlier posts, I&#39;m excited about the emerging trend towards atomic design (see <a href="http://bradfrostweb.com/blog/post/atomic-web-design/">Brad Frost</a>) as it brings a more &#39;development&#39; style process into design. Treating the process as that of designing a system of re-usable components, rather than just designing pages.</p> <p>This moves implementation of a design from a process of deconstruction, to a process of assembly, so brings the world of dev and design closer together. Either bringing design into the development workflow, or bringing development processes into design (depending on which way around you look at it).</p> <p>With an atomic approach to design, and with something like SMACSS for modular CSS, the process of converting to a Drupal theme can be automated. Because the markup/styles are &#39;componentised&#39; we can annotate the source code to document the conversion process and then use automated tools to manage the process.</p> <h3>Demo</h3> <p>Here&#39;s a demo of the proof-of-concept:</p> <div class='embed-container'><iframe src='https://player.vimeo.com/video/90315757' frameborder='0' webkitAllowFullScreen mozallowfullscreen allowFullScreen>https://player.vimeo.com/video/90315757</iframe></div> <h3>Next...</h3> <p>You can download/fork the code from the <a href="https://github.com/darrenmothersele/hyde">GitHub Hyde repo</a>. You&#39;ll need to patch the QueryPath module as it needs the latest version of the QueryPath library and the QP module doesn&#39;t include the right files to make this work by default.</p> <p>A lot of work needs to be done. This is very rough proof-of-concept code, but I think this shows the concept can work, and worthy of further development.</p> <p>Some feedback from last night included:</p> <ul> <li>Generate an actual theme. At the moment the theme is just an object stored in the DB/cache, but I had planned for this to be a ctools exportable. An earlier version I started working on generated actual theme files, perhaps it would be better to switch back to this approach?</li> <li>How to handle logic in template files? Shouldn&#39;t this be handled in pre-process?</li> <li>Stub code generation for pre-process functions</li> <li>Adding extra custom fields for display only? The example given was a date field that was displayed twice on page, once for date stored in field and once for time stored in same field.</li> </ul> <p>Drop me a line if you&#39;ve got any other ideas, or want to get involved, or want to help fund building this properly! :)</p> <h3>Update:</h3> <p>As requested, here&#39;s links to some of the other resources I mentioned during the Show and Tell...</p> <ul> <li><a href="http://webdesign.tutsplus.com/articles/the-sparkbox-responsive-design-process--webdesign-9651">Sparkbox Responsive Design Process</a></li> <li>Stephen Hay, quote: <a href="https://vimeo.com/47171001">We&#39;re not designing pages, we&#39;re designing systems of components</a></li> <li><a href="http://daverupert.com/2013/04/responsive-deliverables/">Tiny Bootstraps for Every Client</a></li> <li><a href="http://smacss.com/">Scalable and Modular Architecture for CSS (SMACSS)</a></li> <li><a href="http://patternlab.io/">Pattern Lab</a> and <a href="http://bradfrostweb.com/blog/post/atomic-web-design/">Brad Frost</a></li> <li><a href="http://warpspire.com/kss/">Knyle Style Sheets (KSS)</a></li> <li><a href="http://bem.info/method/">Block, Element, Modifier (BEM)</a></li> </ul> Fri, 28 Mar 2014 00:00:00 +0000 http://www.darrenmothersele.com//blog/2014/03/28/drupal-theme-generator-demo http://www.darrenmothersele.com//blog/2014/03/28/drupal-theme-generator-demo Dennis Dropin - BDD and Drupal <p>Last night I attended the <a href="http://www.meetup.com/DennisDropIn-Drupal-OpenSource/events/169988982/">Dennis Dropin</a> event on Behavior-Driven Development (BDD) and Drupal. This is a new event on the Drupal London scene hosted by Dennis Publishing.</p> <!--break--> <p>I&#39;ve been attending Drupal events in London since 2007, and there have been a wide variety of different types of events. There have been high points, such as <a href="http://darrenmothersele.com/blog/2013/03/05/drupal-camp-london-review.html">Drupal Camp London 2013</a>, and low points (we had quite a lot of Microsoft sponsored events, but one in particular springs to mind where every presentation was also either paid for by Microsoft or about Microsoft technology - I&#39;m not complaining - I have no right to complain as I&#39;ve eaten enough of their free pizza over the years!). From Drupal Camps, Drupalcon, code sprints, workshops, trainings, and just regular pub meetups, London has a really exciting and active Drupal-scene.</p> <p>Do we need another event?</p> <p>Well, if this first event in the series is anything to go by I&#39;d say definitely, yes please! The event took place in the boardroom at Dennis Publishing, so it was limited in capacity, about 25 people in attendance and the room was nicely packed. <a href="https://twitter.com/PaulLomax">Paul Lomax</a>, the CTO, did say that they had plans for a bigger space so by July we could see this expand into a bigger event.</p> <p>I can think of at least three reasons why this event was a success:</p> <ul> <li>It really felt like this was Dennis Publishing wanting to give something back to the Drupal community. The two presentations were perfectly matched. The first to motivate reasons for adopting BDD, and the second to give practical examples. There was enough technical detail to be useful, without being overwhelming.</li> <li>Dennis&#39; approach to digital is exemplary, probably due to Paul&#39;s leadership. It comes across that the whole team have the right balance of formal process and pragmatism.</li> <li>It seemed like a lot of the Dennis team were in attendance and the experience level of attendees was high. This meant there were some interesting discussions around the presentations too.</li> </ul> <p>The event had a natural split in two parts, which I&#39;d never really considered before, but perhaps others planning events could take into account. Pairing a presentation of motivating business cases with a more technical presentation of practical examples and inner workings.</p> <p>It was interesting to hear in the discussion alongside the presentations real world cases of how BDD had caught bugs that would have cost them ad revenue or resulted in financial losses if they had made it into production.</p> <p>I asked about Continuous Deployment and if introducing testing and increased the frequency of deployment. Paul confirmed they had been able to do more regular deployments, but gave a good reason (one I hadn&#39;t thought of) for why Continuous Deployment is not viable in a Drupal environment. His argument was that when you do a deployment you have to do a cache clear, and when you do a cache clear you clear the form cache. This kicks out any content editors that might be working on the site so deployments have to be limited and controlled. This lead to some discussion of a growl-like notification system with Node.js to push notifications to content editors logged in to the site.</p> <p>Another really interesting idea was the integration of visual diff into the Behat tests. This allows them to do a pixel-by-pixel comparison between the staging environment and production to flag up any major changes. A great extra precaution to pick up any bugs that may cause blocks to disappear or display incorrectly.</p> <p>The next event in the series, <a href="http://www.meetup.com/DennisDropIn-Drupal-OpenSource/events/169953872/">Responsive Web design: How Dennis are skinning this cat</a> is scheduled for April 16th. Already 17 people signed up to the Meetup group so I hope I get in!</p> Thu, 13 Mar 2014 00:00:00 +0000 http://www.darrenmothersele.com//blog/2014/03/13/dennis-dropin-drupal-bdd http://www.darrenmothersele.com//blog/2014/03/13/dennis-dropin-drupal-bdd Death of the Drupal Themer <p>At Drupal Camp London 2013 <a href="https://twitter.com/mcjim">James Panton</a> presented a methodology for implementing designs in Drupal without resorting to custom theme development. At this years Drupal Camp I pulled together two BoF (Birds of a Feather) sessions to continue the conversation and discuss prototyping designs, atomic design, and challenges of incorporating design activities into development workflow.</p> <p>In recent posts I&#39;ve talked about <a href="http://www.darrenmothersele.com/blog/2014/02/06/from-prototype-to-drupal-theme/">prototyping</a> and a bit about <a href="http://darrenmothersele.com/blog/2014/02/07/from-prototype-to-drupal-theme-2/">using Jekyll for prototyping</a>. In many ways this discussion is a continuation of those ideas, but also much more general in it&#39;s scope, and more wide-reaching in it&#39;s potential.</p> <!--break--> <h2>Death of the Themer?</h2> <p>I&#39;ve become interested in this area after recently facing challenges bringing design activities into the development workflow of an agile project. But first, for some context, let me explain where this all began...</p> <p>Last year, Jim presented a methodology for implementing designs in Drupal without having to do any custom theme development.</p> <p>First, Drupal is stripped of all it&#39;s markup. Jim presented to a packed room at Drupal Camp London, and received a big whooping round of applause when he showed naked Drupal markup. Perhaps indicating the general level of frustration the developers/themers have from battling with Drupal markup. Also, there&#39;s a general preconception that Drupal suffers very badly from &quot;Divitis&quot;, &quot;Classitis&quot; and &quot;Span-mania&quot;. This demo showed that this need not be the case.</p> <p>Next, markup is added back in bit by bit to match the markup in the flat HTML/CSS design. This means that the eventual markup produced by Drupal should exactly (or almost!) match what the designer originally intended. The rendered HTML is therefore cured of it&#39;s divitis (contains much less bloat), works with the CSS styles from the design with little or no tweaking, and can make use semantic HTML5 tags.</p> <p>The tools used to reset Drupal default markup include: <a href="https://drupal.org/project/semanticviews">Semanic Views</a>, <a href="https://drupal.org/project/ds">Display Suite</a>, <a href="https://drupal.org/project/panels">Panels</a>, and a fork of <a href="https://drupal.org/project/semantic_panels">Semantic Panels</a> that I can&#39;t seem to find a reference for. <a href="https://drupal.org/project/fences">Fences</a> can also be useful, although functionality to override field wrappers is also part of Display Suite.</p> <p>One of the main benefits of this approach is that it allows designers and Front-end developers to work freely, using whatever tools they want, and without consideration for any of Drupal&#39;s (perceived) limitations. There have been lots of really cool developments in front-end, including CSS and HTML preprocessors, and the multitude of CSS and JS frameworks. This approach allows designers, front end developers, UXs, and IAs to take advantage of all of these tools when prototyping sites.</p> <p>During the BoF sessions at this year&#39;s Drupal Camp London a few limitations and disadvantages were discussed. This methodology moves the implementation of design from development (writing code) to configuration. This can become quite repetitive as each individual bit of output has to be configured with appropriate resets and the correct wrappers to build up the markup.</p> <h2>Custom Plugins?</h2> <p>In the BoF sessions I presented a methodology that I had been playing with, inspired by Death of a Themer, whereby designs are implemented in a similar way, without the need for a custom theme. Drupal markup is taken to a &quot;full reset&quot; state, and then just the required markup is introduced through various plugins.</p> <p>This differs from the original methodology as it does not use configuration to add wrappers back in to fields, view modes, views, panels, etc. Instead, the markup is taken from the prototype (flat HTML and CSS) and copied into &quot;plugins&quot;. Various plugins are used:</p> <ul> <li>Display Suite plugins to add markup to content/entities in various view modes.</li> <li>Views styles to output list markup</li> <li>Panel&#39;s style plugins to add &quot;box&quot; markup, and,</li> <li>Panel&#39;s layout plugins to add layout markup.</li> </ul> <p>The result is the same markup as the flat prototype, and the same result as with the original Death of a Themer approach, but with much less configuration required.</p> <p>The real big win for this approach, is that the components of the design are reusable across various content types and sections of the site without having to repeatedly configure each occurrence.</p> <p>Building out these plugins for every bit of a design might seem like over-kill and more work than is really necessary, but it is a much more scalable way of theming as you end up with design components that can be reused across the site.</p> <p>This version of &quot;Death of a Themer&quot; means the Themer is replaced with a developer, rather than a site-builder, as the emphasis moves away from configuration towards writing custom plugins in code. However, I think a lot of the grunt work can be automated, as I&#39;ll explain in a bit.</p> <h2>Atomic Design</h2> <p>I saw parallels between this approach (of reusable theme components) and the emerging trend of <a href="http://bradfrostweb.com/blog/post/atomic-web-design/">atomic design</a>. In fact, I think atomic design is more than just a current trend but a real leap forward in design methodology.</p> <blockquote> <p>We&#39;re not designing pages, we&#39;re designing systems of components. <br> -- <a href="http://bradfrostweb.com/blog/mobile/bdconf-stephen-hay-presents-responsive-design-workflow/">Stephen Hay</a></p> </blockquote> <p>While producing an atomic design the designer is effectively breaking down the design into components. This is exactly what a good themer does when they take a design and decide how to implement it as a Drupal theme.</p> <h2>From Design to Theme</h2> <p>When a designer hands over a design (let&#39;s assume static HTML and CSS) the developer (or themer, or site-builder) has to make several decisions about how this will be implemented.</p> <ul> <li>Assumptions are made and things get &quot;lost in translation&quot;</li> <li>Compromises are made due to limitations in implementation (i.e. limitations of the CMS, content model, etc)</li> <li>Markup is augmented to add in extra properties like RDFa, etc</li> </ul> <h2>Agile</h2> <p>There shouldn&#39;t really be a &quot;handover&quot; of design. The style guide / atomic design or static mockup that is the result of prototyping should evolve as the product evolves.</p> <p>If something comes up that needs design we go back to the static HTML/CSS to implement it. If using atomic design, this means adding any required &quot;atoms&quot;, &quot;molecules&quot;, etc.</p> <p>If changes have been made as a design is implemented these need to be flowed back upstream to the style guide so that further development of the design can happen, and then (some of) the conversion process is repeated to bring across new design elements into the theme/templates.</p> <p>This process can be hard to manage and bring duplication of effort into the process.</p> <p>If we can automate some of the steps involved in going from static HTML and CSS to Drupal theme then we can move towards a more agile, and robust design-dev workflow.</p> <h2>Proof of concept</h2> <p>Automatically generating a Drupal theme from either a style guide, atomic design, pattern library, static mockup, prototype (or whatever you want to call it!) might sound like a crazy idea, but I&#39;ve got a working proof of concept.</p> <p>I decided to start from just pure HTML/CSS. After experimenting with static site generators (HTML preprocessors), and CSS preprocessors like SASS, I decided that it was best to take pure HTML/CSS as the starting point. This works because every design eventually ends up as HTML/CSS. It&#39;s the language of the web, so it&#39;s unavoidable. It means designers can use any combination of tools they like, as long as they produce HTML/CSS as the end result.</p> <p>As an example, I&#39;m using Jekyll to compile the static mockup, and Compass to compile the CSS, but this could be any combination of tools, or just hand-crafted HTML and CSS.</p> <p>The next stage is to add annotations into the source of the HTML to identify and describe each of the design &quot;components&quot;.</p> <p>I don&#39;t have any terminology yet. Drupal has it&#39;s own jargon, as does SMACSS, Atomic Design, OOCSS, KSS, etc. I&#39;m not sure what to call things. I&#39;m tending towards a combination of Atomic Design and Drupal terminology, but this will change.</p> <h2>Annotations</h2> <p>There has been some discussion in the design community about <a href="https://www.youtube.com/watch?v=ROaXVB-bbek">Pattern Library Annotations</a> documentation, etc.</p> <p>I want to use annotations in designs so that they can be automatically parsed and converted.</p> <p>In this proof of concept, annotations in the HTML source code map directly to the appropriate Drupal templates and plugins.</p> <p>I&#39;m using the <code>x-</code> prefix for my custom attributes. This mechanism is intended for use in vendor prefixing for vendor specific attributes. It distinguishes them nicely from <code>data-</code> custom attributes, results in valid HTML5, and therefore I think it&#39;s an acceptable abuse of the feature.</p> <p>For example, annotate a certain part of the source code as being responsible for layout and it will be automatically compiled into a Panels Layout Plugin:</p> <div class="highlight"><pre><code class="language-text" data-lang="text"> &lt;div x-drupal-type=&quot;layout&quot; x-drupal-name=&quot;front_page&quot; x-drupal-label=&quot;Front page&quot; x-drupal-no-wrap&gt; &lt;div class=&quot;container&quot;&gt; &lt;div class=&quot;row&quot;&gt; &lt;div class=&quot;span8&quot; x-drupal-region x-drupal-name=&quot;content&quot;&gt; ... &lt;/div&gt; &lt;div class=&quot;span4&quot; x-drupal-region x-drupal-name=&quot;sidebar&quot;&gt; ... &lt;/div&gt; &lt;/div&gt; &lt;/div&gt; &lt;/div&gt; </code></pre></div> <p>Another example, this is content shown in a particular preview style called &quot;Box&quot;. It maps to a Drupal view mode:</p> <div class="highlight"><pre><code class="language-text" data-lang="text"> &lt;div class=&quot;box&quot; x-drupal-type=&quot;display&quot; x-drupal-name=&quot;box_teaser&quot; x-drupal-label=&quot;Box teaser&quot;&gt; &lt;img src=&quot;&quot; width=&quot;100&quot; height=&quot;100&quot; alt=&quot;&quot; x-drupal-region x-drupal-name=&quot;image&quot; x-drupal-no-wrap&gt; &lt;h6 x-drupal-region x-drupal-name=&quot;title&quot;&gt;Easy to use&lt;/h6&gt; &lt;p x-drupal-region x-drupal-name=&quot;summary&quot; x-drupal-no-wrap&gt; To get started, you select the desired sample and base the entire website on it. It’s that simple! &lt;/p&gt; &lt;/div&gt; </code></pre></div> <p>Many other attributes are identified and the system currently supports panels layouts, panels styles, views styles, display suite (view mode templates), menus (kinda), and image styles.</p> <p>During the compilation process the various components are identified and the appropriate plugins are created. Any required static files, such as CSS and JS are copied across. Any content in the various regions is removed from the markup, and the generated plugins therefore only contain the markup to wrap the various parts of Drupal output.</p> <p>You can see the (very!) rough proof-of-concept here: <a href="https://github.com/darrenmothersele/hyde">https://github.com/darrenmothersele/hyde</a></p> <p>You really shouldn&#39;t try using this yet, but if you insist, install the modules on a Drupal site with Display Suite, Panels, etc, then enable both modules, and configure to point at the folder with your HTML/CSS design. Then click the &quot;Sync&quot; button to parse your design files and create and register the appropriate plugins based on the design.</p> <p>Warning: You are probably better off waiting for the next version or some actual documentation!</p> <h2>Rather see it in action?</h2> <p>If you would rather see it in action, then come along to the next <a href="http://www.meetup.com/drupal-show-and-tell/events/168733432/">Drupal Show and Tell</a> where I&#39;ll be demonstrating the early version of the theme generator and asking for feedback!</p> Wed, 12 Mar 2014 00:00:00 +0000 http://www.darrenmothersele.com//blog/2014/03/12/automatic-drupal-theme-generation http://www.darrenmothersele.com//blog/2014/03/12/automatic-drupal-theme-generation My Review of Drupal Camp London 2014 <p>Last weekend I was back at City University for the second Drupal Camp London. This year even bigger than the last, with over 600 attendees!</p> <p>I reviewed my post from <a href="http://localhost:4000/blog/2013/03/05/drupal-camp-london-review.html">last year</a> and it seems that I attended a lot fewer sessions this time around. That could be because I hadn&#39;t been to a Drupal event for a while, so I spent more time catching up with old friends and talking about the future of Drupal. I also ran two Bird of a Feather sessions on Atomic Design, Design Patterns, Death of the Themer, automated theme building, and general issues around bringing design into the development workflow, in particular for agile projects.</p> <!--break--> <h2>Friday</h2> <h3>Training day</h3> <p>Before the main Camp starts on Saturday there is the Business and Training day. The main CxO event is happening in another building, and has a strong line up of speakers. While this is going on I&#39;m down in the basement of City University with <a href="http://www.bluespark.com/team/ronald-ashri">Ronald Ashri</a> giving an &quot;Introduction to Drupal&quot; training.</p> <p>We&#39;ve actually got a large group with mixed abilities so we&#39;ve prepared a flexible training that covers a lot of material. Ronald prepared a comprehensive overview for the morning session. We went off-piste a few times, including some interesting discussions around configuration management and best practises. In the afternoon I prepared several demonstrations around an example site with content I had automatically imported from DBpedia. This covered content type configuration, simple Views configurations, some more advanced Views, and we even touched on creating custom workflows with Rules module. We had lots of good feedback about the training so I think this day was a success! A highlight was seeing how well my demo of the <a href="https://drupal.org/project/rules_link">Rules Link</a> module was received. Since I discovered this module I&#39;ve used it on every project, so it was good to share this with others.</p> <h2>Saturday</h2> <p>On to the main Drupal Camp...</p> <h3>Breakfast and chatting</h3> <p>After getting directions from the very hospitable Alex Elkins from City University, I arrive in time to find breakfast being delivered. There are several familiar faces around, so I take the time to catch up with people I haven&#39;t seen for a while.</p> <p>After leaving the canteen and heading out towards the rooms where the sessions are taking place, I made a stop in the &quot;sponsors room&quot;. This room seemed a bit strange to me. Why would sponsors pay a premium to be hidden away in a room off to the side? Last year you couldn&#39;t move for sponsors, they were all over the place! But I guess this is a side effect of the growth of the camp, and needing more space. Anyway, I decide to pop my head in to see who&#39;s around.</p> <p>I had a great chat with the guys from <a href="http://www.pulsant.com/">Pulsant</a> about their various options. At first I was surprised that they hadn&#39;t heard of Docker, but then perhaps not everyone is as excited about this as me. I&#39;m using Docker extensively now in <a href="http://www.apiarycloud.com">Apiary</a> and I do believe it will revolutionise our industry. Anyway, I quickly realised that this wasn&#39;t Pulsant&#39;s thing anyway, they are focused on the actually boxes and wires that run this stuff, and they seem to really care about getting that right. I&#39;ve seen them supporting lots of UK Drupal community events, so it was great to finally speak to them.</p> <p>I then got talking to iKos about the work they are doing with Drupal Commerce and SagePay. This is something I&#39;m probably going to be making extensive use of on a couple of projects, so I&#39;ll plug their free ebook <a href="http://i-kos.com/sagepay">Integrating Drupal, Commerce and Sage Pay</a>. Well worth a read.</p> <h3>Entity operations</h3> <p>All this chatting means I miss most of the first session and just make it in time for the end of Joachim&#39;s <a href="http://2014.drupalcamplondon.co.uk/drupalcamp-london-2014/session/fast-entities">presentation of entity operations</a>. I bump into an old colleague on the way out who&#39;s excited about going away and building some custom entities so I guess Joachim must have given a persuasive demo!</p> <h3>Demo Framework</h3> <p>Another coffee break, more chatting and I almost miss the next session, but determined to actually see something I rush off to find Annika&#39;s session on the <a href="https://drupal.org/project/df">Demo Framework</a>. I hadn&#39;t seen the Demo Framework before, but essentially, it looks like a distribution of Drupal with EVERYTHING in it, pre-configured to show off some of Drupal&#39;s sexiest features.</p> <p>From a technical point of view I really liked the combination of features and migrate module to create demo scenarios. With Features packaging up the functionality, and Migrate module used to package demo content.</p> <p>There was an amusing question from someone after this presentation who asked if it was dangerous to show clients all this functionality up front. They seemed concerned that it would then be hard to justify high prices after the client had seen all that Drupal could do. I think perhaps this person should attend one of <a href="http://www.acquia.com/about-us/team/jeffrey-jam-mcguire">Jeffrey McGuire&#39;s</a> sessions on selling the benefits of Drupal and open-source. My own opinion is that that you should always be providing value, and that when you provide value to a customer, it should not be hard to justify your price when it&#39;s based on the value you provide.</p> <h3>Lunch</h3> <p>Doesn&#39;t feel like I&#39;ve been here 5 mins and already I&#39;m eating lunch? It&#39;s no break from the Drupal action though, as Daniel from <a href="https://www.kendra.org">Kendra Initiative</a> has got a few people together to show off the mockup I made for a collaborative rights management tool for musicians. This is the start of a Technology Strategy Board funded project to develop an application to manage collaboration, metadata and rights, so I may well be blogging about this again in the near future.</p> <h3>Rules Rule Commerce</h3> <p>This session was pitched as an intermediate session, so I took along Alice, who is a relative newcomer to Drupal, but has been picking it up really quickly. Unfortunately, <a href="https://twitter.com/svenbergryen">Sven&#39;s</a> session was more of an introduction so there wasn&#39;t anything new here.</p> <h3>Harmony Forum</h3> <p>After leaving the Rules session I bumped into some people who had just come from a session around the corner on <a href="http://2014.drupalcamplondon.co.uk/drupalcamp-london-2014/session/harmony-forum-introduction">Harmony Forum</a> that sounded excellent. Drupal is lacking a good Forum option, so I was interested to hear what this was about.</p> <p>The most exciting thing in the open-source forum world at the moment is <a href="http://www.discourse.org/">Discourse</a>. I had looked at integrating Discourse with Drupal a while ago but not got very far with it. There&#39;s an existing Drupal module, but it proxies all requests via Drupal (which seemed like a bad idea from a performance and maintenance point of view) and it works against an old version of Discourse. I strongly believe in using the right tool for the job, and that not everything has to happen in Drupal, but this &quot;integration&quot; seems far too tightly coupled.</p> <p>I&#39;m undecided if integrating with Discourse, or building a modern forum solution natively in Drupal would be the best course of action. I think the answer will depend on the scale of the site in question. On smaller sites it makes sense to have everything under one roof, but I think for larger sites a separation of concerns offers extra scalability options that may be worth the overhead of supporting two systems. It&#39;s good that we potentially have both options.</p> <h3>Next Generation DevOps</h3> <p><a href="https://twitter.com/shrikeh">Barney Hanlon</a> gave us a tour of state-of-the-art DevOps in what he called the &quot;Five Stars of DevOps&quot;. Namely: Monitoring, Security, Performance, Automation and Scalability.</p> <p>As I tweeted at the time, this was a real highlight of the Camp. I&#39;ve been doing a lot of DevOps stuff recently, it&#39;s a really exciting area to be working and it&#39;s advancing quickly, so it&#39;s always good to hear what other people are up to. Barney presented this stuff really clearly and obviously knows his stuff. The slides from his presentation are available <a href="http://www.slideshare.net/shrikeh/devops-the-next-generation-slideshare">here</a>.</p> <p>In large-scale Drupal deployments I always encourage scaling out over scaling up. With effective DevOps automation, the pain of maintaining multiple systems is reduced, so you can benefit from using the most appropriate technology for each task. Barney summarised this with the question:</p> <blockquote> Am I doing something in my application that is done better by the infrastructure or an external service? <br><cite>- Barney Hanlon</cite> </blockquote> <p>I&#39;ve been making extensive use of Puppet throughout my DevOps work. It&#39;s based on Ruby, and I found the Puppet configuration files easy to work with. Barney highlighted something that had been bothering me about the Puppet approach, in that you need to have the Puppet Agent on the machine before you can provision it via Puppet. Not quite a chicken and egg style paradox, but it does mean you need someone other mechanism to first bootstap the machine and get the Puppet Agent on to it. Barney, instead recommends the use of <a href="http://www.ansible.com/">Anisble</a>. This is a pure SSH-based approach so needs no extra software on the machine to get started. I plan to move <a href="http://www.apiarycloud.com">Apiary&#39;s</a> initial bootstraping process to Ansible and still make use of Puppet, but then probably soon move all the configuration into Ansible.</p> <p>Barney presented an interesting stack he called the &quot;SPDY sandwich&quot;. It had multiple instances of Nginx with different responsibilities. I&#39;ve done this before for various reasons including load balancing and SSL termination, but Barney is using two layers of SPDY/Page speed optimisations. Perhap&#39;s now it&#39;s time to go and look again at supporting SPDY! <a href="http://blog.phusion.nl/2013/08/21/use-nginx-spdy-without-compiling-nginx-and-without-a-recent-openssl/">This blog post</a> seems like a good place to start, any pointers welcome!</p> <p>Barney re-iterates his point about not doing things in the application that can be done better by infrastructure, and he demonstrates this point using an example where he configures <a href="http://openresty.org/">OpenResty</a> to manage CSRF tokens. OpenResty is a web application server built on Nginx making use of the Lua scripting language. This opens up a whole new world of possibilities!</p> <p>And of course no presentation on DevOps would be complete without some talk of Docker. I think I&#39;ve said this before, but Docker is going to revolutionise our industry. Barney explained some of the current limitations (runs as root!) but Docker is still not ready for production and in heavy development. I did like the example scenario he gave where PECL dependencies could be installed in a Docker container and shared.</p> <h3>BoF - Death of the Themer</h3> <p>I finished the day with some impromptu BoF action. I was keen to get <a href="https://twitter.com/mcjim">James Panton</a> and <a href="https://twitter.com/jamiemagique">Jamie</a> into a room to discuss some of the ideas I&#39;ve been having recently around challenges of bringing design activities into a development workflow (in particular Agile).</p> <p>Last year James had presented on the Death of the Themer, and Jamie has been doing a lot of work with atomic design and live style guides. Unfortunately, they were coming to the Camp on different days, so I had to run two separate BoFs.</p> <p>I&#39;m going to write up the BoF notes and post them here separately. If you&#39;re at all curious about atomic design, style-guides, or automated Theme generation drop me a line, or look out for an announcement on Twitter.</p> <h2>Sunday</h2> <h3>Measuring Success (Piwik)</h3> <p>My training partner from Friday, Ronald, starts Sunday with a discussion of analytics. A lot of what he says applies to any website and analytics software combination, but I&#39;m particularly interested in the fact he&#39;s using Piwik. I&#39;ve been hearing a lot about Piwik recently, and I&#39;ve been meaning to check it out. You may remember I mentioned it on a post in my &quot;Cloud Survivalist&quot; series, as Google Analytics is the only Google service I have not yet found a replacement for.</p> <p>I&#39;d already decided, after talking to Ronald on Friday, that I was going to start using Piwik, but it was good to see it in operation. Ronald gave some good examples, including tracking content items wherever they appear, not just looking at page views. He did this by showing how to add tracking codes to content items in any view mode, so they are tracked in lists and views as well as full page view.</p> <p>Ronald shared a couple of tricks they have implemented to use learnings from analytics to drive content placement. He showed how you could use activity to automatically optimise content placement by doing things like moving items in a nodequeue on CRON based on reading data from the analytics API.</p> <h3>MTV</h3> <p><a href="https://twitter.com/iamreevo">Paul Reeves</a> gave an in-depth look into the guts of the new Drupal 7 powered platform at MTV. I&#39;d been involved in the architecture and development of this, but it was good to hear Paul explain the wider impact of the work we did.</p> <h3>More BoF...</h3> <p>The BoF continues from yesterday. As I said before, I&#39;ll post my notes up as a separate post, probably some time next week.</p> <h2>Wrap up</h2> <p>I might have attended fewer sessions than the previous year, but I left Drupal Camp feeling like the weekend had been a success. The sessions were just a small part of what Drupal Camp is about. It was more about the conversations, meeting up with old friends, making new connections, and throughout all this seeing common threads of conversation, perhaps indicating the current Drupal zeitgeist, namely...</p> <ul> <li>Drupal 8 is not going to be ready this year.</li> <li>Drupal 7 is the best it&#39;s going to be. D7 is a solid robust platform for developing on, and deserves a life beyond D8, a Drupal 7 LTS perhaps?</li> <li>Rules Link is an awesome module</li> <li>DevOps!</li> <li>Atomic design is more than a current trend, and there&#39;s an opportunity for design to become a more integral part of the development workflow.</li> </ul> <p>(or maybe that&#39;s just me).</p> <p>Finally, a big thank you to all the organisers: Tim Deeson, Hedley Smith, George Hazletood, Leon Tong, Ben Wilding, Alex Burrows, Della Deme, Farez Rahman, John Kennedy, (did I miss anyone?).</p> <p>Oh, and of course <a href="http://www.city.ac.uk/">City University</a>!</p> Wed, 05 Mar 2014 00:00:00 +0000 http://www.darrenmothersele.com//blog/2014/03/05/drupal-camp-london-2014 http://www.darrenmothersele.com//blog/2014/03/05/drupal-camp-london-2014