Darren Mothersele - Drupal Planet Feed Darren Mothersele's Drupal Planet Feed http://www.darrenmothersele.com How to Survive Gentrification of the Drupal Community <p>We&#39;re finally approaching the release of <a href="https://www.drupal.org/node/2605142">Drupal 8.0.0 on 19th Nov</a>. The biggest achievement of the Drupal community to date. A complete rewrite of the core system to use modern object-oriented PHP. An effort that is often referred to as &quot;getting off the island&quot;.</p> <p>While the switch from Drupal 7 to Drupal 8 is a big change for developers, it is the result of a slow process of maturation of the Drupal community. Drupal 8 brings changes that will be welcomed by many, will bring in many new users, and of course, will push a few people out. How can we survive this &quot;gentrification&quot; of the Drupal community and prosper without losing touch with why we loved Drupal in the first place.</p> <!--break--> <h2>Gentrification</h2> <p>Cities all over the world are becoming more exclusive, more expensive, and a natural result of this is gentrification. It&#39;s contentious. Some see this as urban improvement, some as social cleansing.</p> <p>I moved to London nearly 12 years ago. Dalston, to be precise. I was back in Dalston this weekend for a party, and it&#39;s very different to how I remember it from 2004. I compared the nice clean overground train to the unreliable and dirty Silverlink trains that used to run to Dalston. Then, walking down Kingsland road without being on guard. When I lived there in 2004 it was often cordoned off by police. The hipsters, the trendy coffee shops, and other obvious signs of gentrification proliferate.</p> <p>Brixton was my home for many years, and I witnessed first hand the results of gentrification. I had an office space in Brixton, and decided to leave it when the landlord announced he was increasing the rent by 25%. I lived in several flats around Brixton over the years, and eventually moved (a bit) further south as rental prices in Brixton soared. I say this with tongue in cheek, well aware that to many I&#39;d be seen as one of the gentrifiers! It&#39;s the communities that settled here during the <a href="http://www.urban75.org/brixton/history/history.html">1940s and 1950s</a> that gave the area it&#39;s eclectic multi-cultural feel. They&#39;re the ones who have been displaced, losing their homes and community as developers and &quot;yuppies&quot; take over.</p> <h2>Gentrification of the Drupal Community</h2> <p>I first used Drupal back in 2003, version 4 point something. It was fun. Hacky, but fun. I had to quickly get a site up for an event we were organising and Drupal offered a collaborative content model that set it apart from the other products we evaluated.</p> <p>I came back to Drupal in 2007 for another community site build, and Drupal 5 had been released. It was really fun. Yes, still very hacky, but it came with the power to build a CMS exactly the way I wanted it to work, and it came with an awesome community of other hackers. A community of dedicated open-source types, who valued openness, and working on projects for good. I was hooked and made the leap to full time Drupal development. Through Drupal I got involved in the first social innovation camp, and other tech-for-good type things.</p> <p>Szeged 2008 was my first Drupalcon. 500 Drupal contributors and users in a small university town in Hungary. Everyone I met truly cared about making Drupal an awesome project and was contributing time and effort in any way they could. Several years later and Drupalcon have grown. 2000+ attendees in Barcelona this year, 2300+ in Amsterdam last year. But, as the community has grown, so has the commercial influence. With sales pitches as prevalent as learning sessions on the schedule.</p> <p>One thing I noticed this year was that several sessions concluded, or included, a call for donations or funding to accelerate a particular module or project&#39;s development. The precedent was set in the starting session of the conference when the Drupal Association made an announcement about the Drupal 8 accelerate funding programme. I&#39;m not saying this is a bad thing. If this is what it takes to get Drupal 8 finished in today&#39;s conditions, then that&#39;s great. But, look at it as an indicator of how the community has changed, when compared to the sessions at Szeged seven years earlier. You would not have seen a call for quarter of a million dollar funding back then. Everyone was there because they loved it, not because they were being paid.</p> <h2>Hacking the hackers</h2> <p>While doing research for this post, I came across this brilliant essay, <a href="https://aeon.co/essays/how-yuppies-hacked-the-original-hacker-ethos">The hacker hacked</a>, by Brett Scott about the gentrification of hacker culture. I quote his summary of the gentrification process:</p> <blockquote> <p>Key to any gentrification process are successive waves of pioneers who gradually reduce the perceived risk of the form in question. In property gentrification, this starts with the artists and disenchanted dropouts from mainstream society who are drawn to marginalised areas. This, in turn, creates the seeds for certain markets to take root. A WiFi coffeeshop appears next to the Somalian community centre. And that, in turn, sends signals back into the mainstream that the area is slightly less alien than it used to be. </p><p> If you repeat this cycle enough times, the perceived dangers that keep the property developers and yuppies away gradually erode. Suddenly, the tipping point arrives. Through a myriad of individual actions under no one person’s control, the exotic other suddenly appears within a safe frame: interesting, exciting and cool, but not threatening. It becomes open to a carefree voyeurism, like a tiger being transformed into a zoo animal, and then a picture, and then a tiger-print dress to wear at cocktail parties. Something feels ‘gentrified’ when this shallow aesthetic of tiger takes over from the authentic lived experience of tiger.<br /> -- Brett Scott</p> </blockquote> <p>How does this relate to the Drupal community? Perhaps it starts with the NGOs and charities, our original flagship Drupal sites, that became our &quot;artists and disenchanted dropouts from mainstream society&quot;. Then the big media companies move in as the &quot;perceived dangers gradually erode&quot;. Eventually, The White House start using Drupal, and we&#39;re at home with the large enterprise clients and big corporate contracts.</p> <p>As the Drupal project developed the requirements changed. Drupal&#39;s capabilities improve, and the Drupal user base and community advanced too.</p> <p>This is evident in the development, and standardisation of things like configuration management. Something that was never an issue in the early days, as the community became more professional, solutions for configuration management were hacked together, and then became standardised.</p> <p>Configuration management is just one example of the many benefits the Drupal community has experienced through the process of gentrification. There&#39;s also great test coverage, performance improvements, greater tooling, and many other advancements that came to Drupal as the community matured. Drupal became less about hacking and more about software engineering.</p> <h2>Drupal 8</h2> <p>Development on Drupal 8 started in March 2011 and four years later, is to set to be released on November 19, 2015. Over these years, Drupal has been rewritten, removing most of the pre-OO era PHP legacy.</p> <p>Drupal&#39;s legacy was the &quot;not invented here&quot; mindset that became entrenched in the community through hacking solutions to extensibility into a language that was not designed to support it. And, a culture of not depending on third-party code due to early well publicised security issues with PHP extensions.</p> <p>The move away from this legacy, the move to &quot;get off the island&quot;, is a move towards more standardised, modern, development practises, and a move to embrace the wider PHP community.</p> <h2>Social cleansing</h2> <p>I mentioned before that gentrification is contentious. For some see it as urban improvement, some as social cleansing. Drupal and the Drupal community have clearly benefitted already, and it looks like prosperous times ahead for those who come along for the ride, and the newcomers who join and adopt Drupal.</p> <p>But, what about the social cleansing. Will parts of the community be pushed out? Who gets left behind?</p> <p>Drupal has suffered from an identity crisis. Because of it&#39;s flexibility, it&#39;s been used for many things. Drupal&#39;s openness to hacking, extending and ability to do just about anything, meant it was more than just a CMS. Over the years many talked about &quot;small core&quot;, many used Drupal&#39;s core tools as a Framework, building apps and tools well beyond what a typical CMS would be used for.</p> <p>Drupal 8 is a content management system.</p> <p>Drupal 8 focuses on content management, on providing tools for non-technical users to build and manage sites. <b>That&#39;s what it always wanted to be anyway</b>.</p> <p>Drupal 8 leverages the wider PHP community, in particular the Symfony components, as it&#39;s core. It no longer makes sense to see Drupal as a framework.</p> <p>One of the parts of the community being displaced, are those using Drupal as a framework. If this is you then you may already be looking at a fork, like <a href="https://backdropcms.org/">Backdrop</a>, or playing with other frameworks, like the beautiful <a href="http://laravel.com/">Laravel</a>.</p> <p>Another section of the community that may be displaced are those running Drupal on low end and shared hosting. Through the gentrification process, Drupal&#39;s requirements have increased. The increased hosting requirements have meant that dedicated Drupal platform hosting providers have emerged. More options for scalability and custom software stacks have taken precedent over solutions for smaller websites.</p> <p>Drupal also potentially loses the innovators. Drupal always had a reputation for being cutting edge and innovative. As it moves to become the enterprise choice of open-source CMS, innovation becomes less important, and stability, security, and backwards compatibility become more important. The biggest innovations in Drupal (flexible content types and Views) date back to the 4.7 era. Views is now in core in Drupal 8. As Drupal matures further from this point, we&#39;ll probably see Drupal adopting innovations from other systems and ecosystems, rather than innovating on it&#39;s own. It&#39;s well placed to do this now, built on Symfony components, innovations from the wider community will be easier to integrate.</p> <h2>Surviving Gentrification</h2> <blockquote> Do you abandon the form, leave it to the yuppies and head to the next wild frontier? Or do you attempt to break the cycle, deface the estate-agent signs, and picket outside the wine bar with placards reading "Yuppies Go Home"?<br /> -- Brett Scott </blockquote> <p>Or, do come along for the ride? Enjoy the benefits of gentrification, without losing the reason why you got involved in the first place?</p> <p>If you&#39;re going to stick around then you&#39;re going to need change a few things. Here&#39;s 5 steps that will get you started:</p> <h3>1. Learn the foundations that Drupal is now built on.</h3> <p>If (like me) you&#39;ve got a background in OO then this shouldn&#39;t be too hard. I did several years of post-graduate research into semantics and verification of object-oriented software. You definitely don&#39;t need to go that deep, but I would highly recommend getting to grips with classic works on design patterns such as <a href="https://en.wikipedia.org/wiki/Design_Patterns">Gang of Four</a> and <a href="http://martinfowler.com/books/eaa.html">Martin Fowler</a>.</p> <p>With a basic understanding of the core &quot;patterns&quot; of object-oriented software, you start to appreciate how Symfony works.</p> <p>Drupal, Silex, Laravel, Symfony Full Stack, Symfony CMF, phpBB, Joomla, Magento, Piwik, PHPUnit, Sonata, and many more projects are built on this same foundation. So, it&#39;s definitely worth learning, and Drupal can be a good way to learn it, while still working with a system you know well.</p> <p>Try building a simple app with <a href="http://silex.sensiolabs.org/">Silex</a>.</p> <p>Check out <a href="https://www.youtube.com/playlist?list=PLpeDXSh4nHjR26Dheb6U1NUSp0aACYGvE">Drupalcon</a> (and <a href="https://www.youtube.com/channel/UCb9XEo_1SDNR8Ucpbktrg5A">Laracon</a>) on YouTube. There&#39;s some great stuff. Like this talk from Ryan Weaver about <a href="https://www.youtube.com/watch?v=iQL1joxljho">Symfony</a> and this talk by Ross Tuck about <a href="https://www.youtube.com/watch?v=ajhqScWECMo">Models and Service Layers</a>.</p> <h3>2. Do PHP the right way.</h3> <p>PHP has changed. There&#39;s a lot of outdated information and a lot of legacy code. Drupal 8 has been rewritten to remove this legacy code, but there&#39;s still a lot of bad advice on how to write PHP out there. Read <a href="http://www.phptherightway.com/">PHP The Right Way</a> for a full guide on how modern PHP should be crafted.</p> <h3>3. Use Composer, use and create PHP packages.</h3> <p>Getting off the island, and embracing the wider PHP ecosystem means using Composer, and it&#39;s ecosystem of PHP packages. There are many more packages that are potentially compatible with Drupal, and by architecting your Drupal extensions as more general PHP packages you have access to a much wider pool of potential collaborators.</p> <p>Creating PHP packages also forces you to write clean code, think like a software engineer, and write more maintainable, extensible, and reusable code. Check out <a href="http://thephpleague.com/">The PHP League</a> as examples of solid PHP packages. They have a good <a href="https://github.com/thephpleague/skeleton">Skeleton</a> starting package.</p> <p>You may have made custom Drupal modules before. Try thinking about how you can refactor these into separate packages, and using the Drupal &quot;module&quot; as a small layer that integrates your logic with Drupal.</p> <p>The <a href="https://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29">SOLID</a> principles will guide you towards creating good packages.</p> <h3>4. Use an IDE</h3> <p>This was a big one for me. I was always against using an IDE, burnt by early experiences with open-source IDEs. I settled on a customised Sublime Text setup, and various other apps. I didn&#39;t see much benefit over using one app for everything when I could combine a selection of my favorite apps to do the same thing.</p> <p>I&#39;m not sure why I stuck to this. I also do a lot of C++ programming. I have my own programming language (<a href="http://cyrilcode.com">Cyril</a>) for creating audio-reactive visuals. I use XCode for C++ as the debugging tools are essential when you&#39;re dealing with object graphs, memory management, and debugging pointer issues. So, why not use an IDE for my web development?</p> <p>I tried <a href="https://www.jetbrains.com/phpstorm/">PHPStorm</a> and it&#39;s great. Far from the cumbersome experience I had in the early days with open-source IDEs, it offers a smooth, fast, integrated experience.</p> <p>I think you can get away without an IDE when you&#39;re hacking on Drupal 7, but on an OO system like Drupal 8 you will need an IDE. You will need the integrated tooling, testing, and you&#39;ll be much more efficient with intelligent autocompletion, hinting, quick access to docs, and fast navigation of the huge codebase.</p> <h3>5. Identify your values and serve your purpose.</h3> <p>As the corporates, enterprises, and big businesses take over, it&#39;s important to remain true to your yourself. By <a href="https://www.mindtools.com/pages/article/newTED_85.htm">identifying your values</a> you will be well placed to notice when they are being compromised.</p> <p>You probably got into open-source because you believe in the power of collaboration. But, this value of collaboration can often be at odds with the cut-throat corporate culture of competition.</p> <p>To be aware of this is to be aware of the opportunity to spread openness and collaboration with our work.</p> <p>As the proceeds of Drupal&#39;s success flow into the community, it&#39;s important to use this to do good. To continue to serve our communities and society as a whole. To enable collaboration, share our work, and use openness to build the world we want.</p> <h2>Final thoughts</h2> <p>The real opportunity, is to spread Drupal&#39;s values of cooperation to the wider population.</p> <p>This is part of a bigger shift in society to adopt open-source values, principles, and methodologies. Chris Anderson says it best:</p> <blockquote> If the past ten years have been about discovering new social and innovation models on the Web, then the next ten years will be about applying them to the real world.<br /> -- Chris Anderson </blockquote> <p>The <a href="http://blog.workopen.org/manifesto/">Work Open Manifesto</a> offers a useful formulation of what it means to be open that can apply beyond open source software: <b>&quot;Think Big, Start Small, Work Open&quot;</b>.</p> <p>Drupal is great case study for starting small, thinking big, and working openly.</p> <p>The Drupal community has always has been transforming, improving ourselves, improving the product, improving our practises, and improving our tools.</p> <p>Now it&#39;s time to think beyond Drupal, beyond the Drupal community, and to see Drupal&#39;s values of collaboration, teamwork, and openness spread through the wider community, society, and the world.</p> Mon, 16 Nov 2015 00:00:00 +0000 http://www.darrenmothersele.com//blog/2015/11/16/surviving-open-source-gentrification/ http://www.darrenmothersele.com//blog/2015/11/16/surviving-open-source-gentrification/ 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/