Feed aggregator

OSTraining: 5 Steps to Build a Drupal 8 Multi-lingual Site

Drupal News - September 25, 2015 - 1:29pm

Drupal 8 is a massive undertaking. It's already been 5 years in the making.

Why did it take so long? Partly because so many important contributed modules are now core features. Translation is a perfect example.

It used to take several contributed modules to make even a small multi-lingual Drupal 7 site. Now, you can translate everything using just the Drupal 8 core.

Here's our 5-step guide to building your first Drupal 8 multi-lingual site.

Zivtech: Introducing Probo.CI

Drupal News - September 25, 2015 - 8:00am

Probo.CI is a new open source continuous integration system designed from the ground up to work with Drupal. It integrates with Githhub to build your pull requests and post the status of your builds back to the Github PR, just like travis.ci. The part that is different from travis.ci is that it does not tear down your environment at the end and but instead posts a link to that environment on the github issue for easy code review, client feedback, and project manager evaluation. In order to save on resources with large numbers of containers, Probo shuts down containers while you’re not using them and starts them up again on demand to give you just-in-time access to your development environments. Probo is designed to be easy to extend and easy to wire into a broader devops ecosystem.

Under the hood, Probo.ci is written in Node.js and powered by Docker. This means that with just a little configuration you can run on your own container images and test your Drupal sites on whatever versions of whatever services your stack needs. Probo is implemented using a microservice architecture and ships with services for receiving Github notifications of push and pull request events and posting statuses back to the status API, another for creating, starting, and stopping the containers, and a third for proxying incoming requests to the correct container (and starting the container if it was stopped to save on resources). It also ships with tools for use as a local test runner (especially helpful when you’re getting your project ready to build server side).

Cross posted from the Probo CI Blog.


Chapter Three: ADFS and SimpleSAMLphp with Drupal

Drupal News - September 25, 2015 - 7:56am

This is instruction on how to configure SimpleSAMLphp library and Drupal on Pantheon, the configuration settings may vary depending on the ADFS configuration.


  1. Download SimpleSAMLphp version 1.11.0. The newer versions available but I haven't had a chance to try them.

  2. Drupal 7 site (latest version always recommended).

  3. simpleSAMLphp Authentication Drupal 7 module.

  4. Drupal 7 site running on Pantheon.

Install SimpleSAMLphp

  • Create a private directory in your document root: /private and move downloaded files and folders to /private/simplesamlphp-1.11.0

LevelTen Interactive: DriesNote: DrupalCon Barcelona 2015

Drupal News - September 25, 2015 - 7:04am

Dries Buytaert, founder of Drupal, gave a keynote address at DrupalCon in Barcelona on September 22, 2015.  He answered what he called “three uncomfortable questions” about the state and future of Drupal, and announced that the long-awaited release of Drupal 8 is imminent, planned for October 7, 2015. The speech is available online, however, we've made it easier on you, with the following summary notes on DriesNote:

Is Drupal losing momentum? 

Basically, yes, but it will get it...Read more

Matt Glaman: Drupal Commerce flamegraphs and performance.

Drupal News - September 25, 2015 - 5:04am

 I've been working on a and one of the tools is setting up the ability to easily generate flamegraphs. I figure the best test run would be to dive into some basic info on the performance of a front page load for a typical Drupal Commerce site. There's no magic solution presented here, just some knowledge on what the build process looks depending on caches.

Page load with a cold cache

Here is a first load of a Drupal Commerce site installed from Commerce Deploy with one product display on the homepage. Commerce Deploy is a barebones installation with basic configuration and generally most modules enabled you'd need in a typical site - including Features. The first flamegraph is from a cold cache page load. As you can see a lot of time is spent building the Rules cache, and Rules is integral to the operation of Drupal Commerce. Then you have general hook invocations and everything being collected and cached - Views data, the theme registry, miscellaneous APIs. 

Note: you can click any of the SVGs and navigate the function calls.

One thing I hope you'll notice is the fact cron ran at the end of the menu execution. That's because this is the default settings of "run cron every three hours." That runs when a user visits your site. Here's the same process but with cron set to "never" under the expectation we'll set a crontab to run cron via Drush or wget hourly or so. As you can see, there is a dramatic difference on that first load with a cold cache. One thing to remember, if you're using Features, is that Features will rebuild on cron.

Page load with a warmed cached

Here's the same site once the cache has been warmed. Nifty right? Let's trying adding in  and see how much that changes the page load.

The performance of a cold cache page load is about the same. But there is quite a difference with entity caching enabled - I actually feel the overall process is cut in half. I have had some developers say Entitycache is pointless unless you're storing it in an in-memory cache like Redis or Memcache. I don't think this is true - however you would most benefit by putting the entity cache in memory and saving your MySQL server from a lot of liftings.

What if I do have a slow Drupal site?

Like I said, there isn't a huge takeaway from this article. But, hopefully, you can grasp an idea of where you might be experiencing bottlenecks and begin resolving the issues. Don't just take Entitycache and toss it on to make a band-aid. Try to discover the issues and prevent them from happening. For what it's worth, using my tool it only took 10 minutes to generate these flamegraphs. If you'd like to learn more about the process, I recommend this  about making flamegraphs. In fact, my implements the exact workflow of that blog post, but with two commands.

InternetDevels: Lviv Euro Drupal Camp 2015: Schedule and Reports

Drupal News - September 25, 2015 - 4:19am

Have you ever wondered what it’s like to kill ...five birds with one stone? Yep, five not just two. Getting advanced Drupal training, sharing experience and learning first hand from expert developers, adventures of travelling, city touring and cyber questing, lots of fun hanging out with the IT crowd, and loads of yummy food – all in one at the upcoming Lviv Euro Drupal Camp 2015, the meeting point for drupalers from all corners of the country!

Read more

Steve Purkiss: Remote DrupalCon - Day 3

Drupal News - September 25, 2015 - 1:12am
Friday, 25th September 2015Remote DrupalCon - Day 3 "Talk is silver, contribution is gold"

It's the final day of sessions at the Real DrupalCon and these are the keynotes I've been waiting for! (click here for yesterday's blog if you missed it)

I say "keynotes" as in a departure from the norm there are two speakers today, both whom I've had the pleasure of seeing previously and both whom touch on subjects close to me - Contribution beyond source code in Drupal and Mental Health in Open Source.

Contribution beyond source code

Sketchnotes by Peter Decuyper

David Rozas (@drozas) is a Free Software enthusiast, Drupal developer, PhD candidate and postgraduate researcher whom for the last few years has been researching contribution in Free Software communities, specifically Drupal. I've seen David talk at a few DrupalCamps and it is great to see his work being recognised and able to reach a wider audience.

I find it a particularly interesting area as my non-code contributions to the Drupal project are orders of magnitude greater than the ones of code - I just noticed the other day my Drupal Groups Profile says I've been involved in organising 70 events, plus I've done things like create a cool short film about What is Drupal? In fact one of the reasons I used Drupal in the first place was because writing code for other people's websites selling parking spaces or whatever didn't really float my boat much as a computer scientist so I could do most of what I needed with existing modules and just provide the 'glue code'.

It is only really in the past year with the advent of Drupal 8 that my code contributions have started - much of that has also been to do with actually knowing how I can join in, along with confidence issues - the latter covered by today's second keynote covers so I'll park that one for the moment.

Commons Based Peer Production

The key to David's session for me was the introduction to the audience of the term "Commons Based Peer Production", which is how the Drupal community works. I honestly think the vast majority of people who currently use Drupal at the moment think it's a CMS product produced by some magical team toiling away building the exact feature you want to use for Free, or they simply don't think about how or where it comes from, it just is. By David introducing the notion of Commons Based Peer Production it ideally frames the community and the product, and explains how it is built and maintained - not by one specific company but by a community of peers, i.e. you and me, no magic unicorns in the sky. Far too often I see Drupal 'sold' as a product which often serves to disappoint when people encounter issues and don't understand the process of how they can deal with them, often expecting people to work for free and/or blaming Drupal itself for their problems. An overview of CBPP should be in every Drupal 101 tutorial, get people involved in the community from the start!

David covers the notion of what commons are and highlights a number of quotes from Drupal community members and comes to the conclusion that to continue to scale the Drupal community effectively more local meetings in real life are needed to strengthen the connections built online and enable community members to interact on other levels than just code itself. In terms of funding the growth, David explains we need to explore new dimensions of value - an area I'm particularly interested in as I love to write and do other things than code however the only proven way I get money at the moment is from coding.

Profiles on the Drupal website are covered, highlighting that community contributions are beginning to be included a lot more, as well as things like listing your mentors which helps the mentors too, not just your own profile. More non-code contributions need to be included - it's often been the mantra of Drupal that "Talk is silver, code is gold", I like the alternative "Talk is silver, contribution is gold". The more we recognise people's contributions of any kind, the more the community will grow organically.

David's keynote is an enlightening one as it educates members of our community as to what it is they are actually part of - I think this is key to knowing that you can and are part of it and helps to break down the barriers to contribution. He ends his keynote saying this is only the first set of results and wants to continue the research in an open, Drupal fashion and invites people to join in over at a new group set up Research about the Drupal community - this is only the beginning!

Mental Health & Open Source

Mike Bell, UK Drupalist begins his keynote on Mental Health & Open Source with a caveat that he is not a doctor and this is just from his own experience via a break down. Shortly after his talk I saw this infographic by Anna Vital go by on my twitter timeline which I thought was quite appropriate as I think I have at some time encountered similar scenarios and it's how you deal with them which makes them either constructive or destructive.

Mike covers these issues well in three sections - Depression, Anxiety and Imposter Syndrome. Rather than repeating his entire keynote I'm going to cover a little about how each of them affects my life and I encourage you to watch Mike's keynote to gain more insight into what is a very important subject everyone is affected by at some time or another.


It's strange when you look at your life and all the things you have - I live in a wonderful apartment, in a wonderful city, close to the beach yet depression is something which, as Mike says, just comes over like a dark cloud and it's very hard often to see the good in anything. Like Mike, when I first went for help with my depression from the medical profession I was put on a dose of medication and it did help me get through the worst of it. This was 20 years ago when I was a 'mature student' at uni (I'm now 43!). A year later I went particularly low again and was put on a different medication which had an adverse reaction with me which meant I was shaking all the time and when my best friend pointed it out I took myself off the medication and haven't had any pharmaceuticals since. For me, I know what causes my depression and I know what I need to do to get out of it - eat healthily, do lots of exercise, etc. Doesn't mean I always do it, and I'm particularly out of practice at the moment hence why I'm not as happy as I know I can be, but whilst the pills do help in some cases, they only tend to mask the underlying issues which are often more than not life issues which I believe working through them makes me a stronger person in the end. I'm not advocating not taking medication, I'm just saying for many people it's not the answer but a temporary fix, and if you're happy with that then that's fine. Mental illness isn't one thing affecting people in one way and there's no one answer.


I'm going through lots of anxiety right now - I spent a lot of time and money traveling this year so I could grow my Drupal network and learn more about Drupal 8 but I went over-optimistic again and didn't build my pipeline up enough, so a month ago I lost a number of potential opportunities all at the same time and now I'm two months behind in rent. The worst is it's debilitating which just produces a downward spiral as it means you stop doing the things which bring you the work in the first place. Luckily a couple of months back I forced myself to start blogging again, so when I had to cancel my DrupalCon ticket I thought that instead of being depressed and anxious about cancelling the one thing which probably would've meant I'd bump into someone and make connections for work I'd use my talents, keep myself busy, create the opportunity for connections to happen, and give you all an ear-bending in the meantime ;)

I'm anxious about writing about this stuff because I'm freelance, I'm the salesperson, and I worry if people know every bit about my life then they somehow link it with work. Well, for sure I don't do a 9-5 any more, but I go by what I produce, the end result, and when I look back at the projects I've produced lately I'm very proud - happy clients takes my anxiety away for sure! So thanks to Mike, because if it weren't for you I wouldn't feel as easy as I do now writing about this stuff, and frankly I don't care what people think, whether self-indulgent, too much, or whatever, it's helping me right now lol.

Imposter Syndrome

This is probably my biggest bug-bear with mental illness. I've been hacking on computer code for the lat 34 years, yet often when I look at some code I go "I can't do this" and it often take a lot of effort to get past this point, but every time I have I've proved to myself that I can do it. That's probably more confidence than imposter syndrome, for me it stems back to when I was in a previous company in the dotcom days and the head geek took the mick out of my technical capabilities. I admit I'm not the best one to be sitting down coding all day on a client's site, but that's more to do with the fact I'm a creator as opposed to a mechanic, and my days are not 100% coding any more.

Where I get imposter syndrome most is when all three issues are affecting me, and I can honestly say yesterday was one of those days. I was ready to sell everything up - I don't know where my next income is coming from, I'm late with bills, I'm credit carded up to the max - what am I doing, who am I kidding that I know this Drupal thing? I realised it was only my current wave of thinking though so instead of staying up late last night to write this final blog of the conference I'd do it the next day. Then anxiety set in - what if I forgot everything I watched? What if I just let it slip and didn't end up writing the blog? I knew this blogging thing was a silly idea & wouldn't last long - etc. etc. - if I told you every thought I had last night on this the page would never end, but we are here so once again the world didn't end ;)

Managing Mental Illness

Mike continues his keynote covering what methods he's using to cope at the moment and areas such as how it impacts companies and business. For me, Drupal enables me to live with who I am as a person - there's enough opportunities around so that I can, bit by bit, fulfil my needs from a number of different areas - personally I've never found a job which could do that for me. You're either building your own life or someone else's, from a bad experience being made redundant back in the 'dotbomb' days I've always wanted to be in a position where I'm in control, and although it's hard to say this right now with imposter syndrome creeping back in with the thought of the late rent and bills, I do believe I've managed to do pretty good having freelanced now for the last 15 years. That's not to say I'm not open to opportunities - often I think about how 'easy' it would be not to have to worry and just take my monthly pay, but I don't believe that's going to fulfil my potential as a human being - in fact I don't think it does for any human being, but that's another story for another time.

All I do know is I'm enjoying writing this way too much - I used to blog and write stuff every day as I wrote a Plain English Guide to Open Source but my writing stopped shortly before my Drupal started due to an abusive relationship I was in over in Canada with a girl who I found out was BPD & bipolar, but that's yet again another story so for the moment thanks Mike for helping me back on my road to recovery, apologies to those who are just trying to catch up with the goings-on at DrupalCon, I'll get back on the case shortly, if you want to discuss this, or anything, further please do tweet @stevepurkiss or contact me through my website, comments are broken on here and I'm not fixing them as I'm migrating to Drupal 8 just as soon as I finish this blog ;)

Mike's keynote finishes up with a well-deserved standing ovation from the audience then a short Q&A session discussing things like how we can help within our community and at our events. Mike suggests a table at events where local mental health professionals can set up a stall with leaflets, etc. Personally I think we should do those as part of the process but focus on the underlying issues as to why people are having break downs in the first place. It's a strange year as this is covered in other sessions I watched which I brief below as our project has experienced much 'burn-out', but it is great to see so much focus on this - seeing and being part of how we address these issues is great as I'm sure if it were in some company they'd probably just pass it on to the HR department to sort out, we have the opportunity here to forge new ways of dealing with the pressures of modern life. Personally I believe new ways of living like being a digital nomad are part of the cure - we don't need to be near the factories to do our work any more yet we live in an infrastructure and culture built around those principles, luckily this is changing slowly as we do more of this sort of thing.

Other sessions from Day 3

I must admit I had to have a break after watching the two keynotes, it was all a bit overwhelming - two subjects close to my heart, community members and their work being recognised, the reaction of the audience, etc. but I knew there were more awesome sessions coming and two days in with only one to go was certainly no time to give up now I've been blogging about it too ;) So on we continue, and on a similar vein to the keynotes...

Avoiding and surviving of contribution burnout - @laurii1 and @schnitzel provide an excellent session on what burnout is as opposed to stress, some tips on how to deal with it personally (like drink more water, cos it makes you pee so forces you to get up and move around!), and how to deal with it in our community (delegation, more praise for participation, etc.). More than half the session is given over to discussion with the audience on how we can make Drupal more sustainable so well worth a watch. I think there will always be stress and burnout whilst there's such a disproportionate amount of contributors vs users of Drupal so believe that at least some of these issues can be addressed by growing the community of contributors so the workload is shared more, and perhaps saying no to stuff if there isn't the material support to go along with the efforts necessary to produce it.

Pain Points of Contribution in the Drupal Community - Kalpana's (@kgoel) session is along similar veins but more on the practical side of what the problems are with the current interfaces we have and stumbling blocks to participation and how we can get organisations to contribute and participate more.

Hassle-free Hosting and Testing with DevShop & Behat - there's lots of options for managed Drupal hosting, and whilst I love them they are rather expensive especially when dealing with small or personal projects, plus it's always good to look at other options so when I saw there was an open source hosting project for devshops available I thought I'd check it out. It's interesting, but I still don't feel confident enough to manage my own and clients sites as I'm no sysadmin (I like to break things, guess that's why I like tests so much!) so whilst I'll still be playing around with self-hosting a few pet projects, I'll leave the client stuff up to the professionals. Worth watching if you want to set up your own hosting stack though.

The future of Groups on Drupal.org - unfortunately the presenter's slides didn't display properly so we couldn't fully see the proposed improvements but you got a good idea that there's a lot of good change on the way, focusing on the personas that were created a while back for drupal.org users so contextual data should show up in the future, at the moment it's focused squarely on developers.

Planning for Drupal 8.1.x, 8.2.x, and our future together - this was actually more interesting and important than I thought it would be, another half-session, half audience participating in making a list of what to be included in the next versions of Drupal now that we have gone to semantic versioning, i.e. minor versions as well as major providing functionality additions. Presenter Tim Plunkett whom I had the pleasure of finally meeting when I went to DrupalCon LA (yes, that's another reason why I'm cashflow poor at the moment!) is ideally placed to host this talk as his work in the panels and layouts area is particularly affected by semantic versioning as not everything will get into the 8.0.0 release. Watch this if you're planning on using Drupal 8 and want to know what's coming up soon!

AMA: Drupal Shops Explain How They Do It - not much in terms of visuals on this one but an interesting discussion from a few Drupal shops as to how they do things like manage remote teams and encourage clients to become part of the community. I find it encouraging hearing their efforts but as someone who's seen a lot of the issues lately with getting Drupal 8 out of the door I'll be a lot happier when the balance of contributions is, well a little more balanced. If people can make millions out of Drupal, then it shouldn't be as hard as it was to get $250k for funding some core development - for whatever reason. What businesses get back is Drupal, if you don't fund/help maintain/grow Drupal, it will disappear. Free as in speech, not beer remember!

Distributed Teams, Systems & Culture - An interesting session on how one company - pantheon - manages its remote teams.

PHP 7 is (almost) here. OMG! PANIC! - I started to watch this as now Drupal 8 is almost here we are actually making use of some of the functions PHP has developed in the last 10 years or so! It was a little too heavy for me for yesterday so I'll revisit it sometime as interesting things are happening in the PHP world.

Paid contribution: past, present, and future - this was a really interesting session on funding contributions, mainly driven by audience discussions being part of the core conversations track. There's been a lot of different approaches to funding in the last year with more people now being paid to work on Drupal fulltime, a few funding campaigns for things like Rules and other efforts. One particular point I thought interesting was the discussion on return on investment for companies sponsoring DrupalCamps, and the general feeling that it's becoming harder to justify as businesses want to know direct results. Suggestions such as questionnaires before the event so companies can research potential employees were offered and a general feeling that the overall sponsorship packages need to be revamped - companies don't care how big their logo is, they want value they can value. There was also the Rules initiative which was funded but took a lot of effort and it was mentioned that it's going to be hard to go back and ask for more so other options would be good to look into - personally I think people just don't know what needs doing or how they can get involved so it's good to see sessions like this try to hatch more ideas out.

Building semantic content models in Drupal 8 - I was particularly interested in this session as one of my projects is a Drupal skills-matching site. I must admit I was eagerly waiting Dries' Drupal 8 retrospective to appear in the video timeline so once it did and I saw that most of this looked the same as it was in 7, I moved on. Extremely interesting topic though!

Drupal 8 retrospective with Dries - each year the founder of the Drupal project Dries does a Q&A session which is one of the only sessions I usually attend. After quite a few DrupalCons (8 I believe!), I soon worked out that most of the videod sessions I was fine with watching after the event, so mostly ended up going to BoFs (Birds of a Feather) sessions where you get to participate in the growth of a certain area of the project, or the hallway track. This DrupalCon is the only one I've watched all sessions during the event but sadly that's only because I'm not physically there!

Dries goes through what worked well, what didn't, and how we can improve in the future - release fewer things sooner, improve core funding, etc. The take-away quote for me was when he said "we need to get off our processes island as well as our technical one" which couldn't have summed it up better - other projects and organisations have worked on this for years and we should gain knowledge from them, at the moment we just throw things into the pot and Drupal comes out the other side, we need more direction.

A truly superb session and one every Drupaler must watch!

Watch Later List

By this time I was pretty bushed so I thought I'd go through the rest of the Drupal Association videos to see which other ones from the conference I'd like to watch. As per usual a massive list emerged but thought I'd post it here for those like-minded!

We did a DrupalCon!

These words from the closing session where they announced the next European DrupalCon will be in Dublin next September! Before that there's DrupalCon Asia in Mumbai in February and DrupalCon New Orleans in May. I do hope I manage to work out my business models so I can afford to go to all. I'm particularly interested in Mumbai as I've never been there and I think there is massive opportunity over there, I'd love to grow teams of connections out there, watch this space and get in touch if you want to be involved or can help out in any way.

Although I didn't make it I do feel doing this blog has made me feel more part of it so didn't totally miss out but I do recommend you make the effort to attend a DrupalCon if you haven't already, at least go to your local events or start one up if there isn't anything - I learned the hard way that Drupal isn't just a sole way of working, it's all about the people, join in and soon things start to become much clearer.

Well, that's it from me - thanks for joining me on my remote DrupalCon journey and I hope never have to do it again as instead I'll be there ;)

Click here to contact me to discuss this further, I welcome all feedback!

tags: drupalconbarcelonaPlanet DrupalDrupal Planet

Annertech: DrupalCon 2016 is Coming to Dublin!

Drupal News - September 24, 2015 - 9:00am
DrupalCon 2016 is Coming to Dublin!

Céad míle fáilte go Baile Átha Cliath. DrupalCon is coming to Dublin. Yes, you read that right, DrupalCon 2016 will be in Dublin, and we at Annertech can't wait to see you there.

The Drupal Ireland community has been doing great work over the past few years - Drupal.ie was launched, Drupal Camp Dublin became Drupal Open Days Ireland, hundreds of Drupalists came to Drupal Dev Days in Dublin, DrupalCon Trivia Nights were organised and hosted in many cities, and now - at last - DrupalCon will be held in Dublin.

Dries Buytaert: The future of decoupled Drupal

Drupal News - September 24, 2015 - 6:43am

Of all the trends in the web community, few are spreading more rapidly than decoupled (or "headless") content management systems (CMS). The evolution from websites to more interactive web applications and the need for multi-channel publishing suggest that moving to a decoupled architecture that leverages client-side frameworks is a logical next step for Drupal. For the purposes of this blog post, the term decoupled refers to a separation between the back end and one or more front ends instead of the traditional notion of service-oriented architecture.

Traditional ("monolithic") versus fully decoupled ("headless") architectural paradigm.

Decoupling your content management system enables front-end developers to fully control an application or site's rendered markup and user experience. Furthermore, the use of client-side frameworks helps developers give websites application-like behavior with smoother interactivity (there is never a need to hit refresh, because new data appears automatically), optimistic feedback (a response appears before the server has processed a user's query), and non-blocking user interfaces (the user can continue to interact with the application while portions are still loading).

Another advantage of a decoupled architecture is decoupled teams. Since front-end and back-end developers no longer need to understand the full breadth and depth of a monolithic architecture, they can work independently. With the proper preparation, decoupled teams can improve the velocity of a project.

Still, it's important to temper the hype around decoupled content management with balanced analysis. Before decoupling, you need to ask yourself if you're ready to do without functionality usually provided for free by the CMS, such as layout and display management, content previews, user interface (UI) localization, form display, accessibility, authentication, crucial security features such as XSS (cross-site scripting) and CSRF (cross-site request forgery) protection, and last but not least, performance. Many of these have to be rewritten from scratch, or can't be implemented at all, on the client-side. For many projects, building a decoupled application or site on top of a CMS will result in a crippling loss of critical functionality or skyrocketing costs to rebuild missing features.

To be clear, I'm not arguing against decoupled architectures per se. Rather, I believe that decoupling needs to be motivated through ample research. Since it is still quite early in the evolution of this architectural paradigm, we need to be conscious about how and in what scenarios we decouple. In this blog post, we examine different decoupled architectures, discuss why a fully decoupled architecture is not ideal for all use cases, and present "progressive decoupling", a better approach for which Drupal 8 is well-equipped. Today, Drupal 8 is ready to deliver pages quickly and offers developers the flexibility to enhance user experience through decoupled interactive components.

Fully decoupled is not usually the best solution

In a fully decoupled architecture, the theme layer is often ignored altogether, and many content management capabilities are lost, though many clients ingesting data are possible.

Traditionally, CMSes have focused on making websites rather than web applications, but the line between them continues to blur. For example, let's imagine we are building a site delivering content-rich curated music reviews alongside an interaction-rich ticketing interface for live shows. In the past, this ticketing interface would have been a multi-step flow, but here we aim to keep visitors on the same page as they browse and purchase ticket options.

To write and organize reviews, beyond basic content management, we need site building tools to assemble content and lay it out on a page. On the other hand, for a pleasant ticket purchase experience, we need seamless interactivity. From the end user's perspective, this means a continuous, uninterrupted experience using the application and best of all, no need to refresh the page.

Using Drupal to build a content-rich site delivering music reviews is very easy thanks to its content types and extensive editorial features. We can list, categorize, and write reviews by employing the user interfaces provided by Drupal. But because of Drupal's emphasis on server-side rendering rather than client-side rendering, Drupal alone does not yet satisfy our envisioned user experience. Meanwhile, off-the-shelf JavaScript MVC frameworks and native application frameworks are ill-suited for managing large amounts of content, due to the need to rebuild various content management and site building tools, and they can pay a performance penalty.

In a fully decoupled architecture, our losses from having to rebuild what Drupal gives us for free outweigh the wins from client-side frameworks. With a fully decoupled front end, we lose important aspects of the theme layer (which is tightly intertwined with Drupal APIs) such as theme hook suggestions, Twig templating, and, to varying degrees, the render pipeline. We lose content preview and nuances of creating, curating, and composing content such as layout management tools. We lose all of the advancements in accessibility and user experience that make Drupal 8 websites a great tool for both end users and site builders, like ARIA roles, improved system messages, and, most visibly, the fully integrated Drupal toolbar on non-administrative pages. Moreover, where there is elaborate interactivity, security vulnerabilities are easily introduced.

Progressive rendering with BigPipe

Fully decoupled architectures can also have a performance disadvantage. We want users to see the information they want as soon as possible (time to first paint) and be able to perform a desired action as soon as possible (time to interaction). A well-architected CMS will have the advantage over a client-side framework.

Much of the content we want to send for our music website is cacheable and mostly static, such as a navigation bar, recurring footer, and other unchanging components. Under a traditional page serving model, however, operations taking longer to execute can hold up simpler parts of the page in the pipeline and significantly delay the response to the client. In our music site example, this could be blocks containing songs a user listened to most in the last week and the song currently playing in a music player.

What we really need is a means of selectively processing those expensive components later and sending the less intensive bits earlier. With BigPipe, an approach for client-side dynamic content substitution, we can render our pages progressively, where the skeleton of the page loads first, then expensive components such as "songs I listened to most in the last week" or "currently playing" are sent to the browser later and fill out placeholders. This component-driven approach gives us the best of both worlds: non-blocking user interfaces with a brisk time to first interaction and rapid piecemeal loading of complete Drupal pages that leverage the theme layer.

Currently, Drupal 8 is the only CMS with BigPipe deeply integrated across the board for both core and contributed modules—they merely have to provide some cacheability metadata and need no awareness of the technical minutiae. Drupal 8's Dynamic Page Cache module ensures that the page skeleton is already cached and can thus be sent immediately. For example, as menus are identical for many users, we can reuse the menu for those users that can access the same menu links, so Dynamic Page Cache is able to cache those as part of the page skeleton. On the other hand, a personalized block with a user's most played songs is less effective to cache and will therefore be rendered after the page skeleton is sent. This cacheability is built into core, and every contributed module is required to provide the necessary metadata for it.

For a fully decoupled site to load more rapidly than a highly personalized Drupal 8 site using BigPipe, you would need to reconstruct a great deal of Drupal's smart caching logic, store the cache on the client, and continuously synchronize the client cache with server data. In addition, parsing and executing JavaScript to generate HTML takes longer than simply downloading HTML, especially on mobile devices. As a result, you will need extremely well-tuned JavaScript to overcome this challenge.

Client-side frameworks encounter some critical and inescapable drawbacks of conducting all rendering on the client side. On slow connections such as on mobile devices, client-side rendering slows down performance, depletes batteries faster, and forces the user to wait. Because most developers test locally and not in real-world network conditions on actual devices, it's easy to forget that real risks of sluggishness and unreliability, especially due to spotty connectivity, continue to confront any fully decoupled site — Drupal or otherwise.

Progressive decoupling is the future

Under progressive decoupling, the CMS renderer still outputs the skeleton of the page.

As we've seen, fully decoupling eliminates crucial CMS functionality and BigPipe rendering. But what if we could decouple while still having both? What if we could keep things like layout management, security, and accessibility when decoupling while still enjoying all the benefits an interaction-rich single-page application would give us? More importantly, what if we could take advantage of BigPipe to leverage shortened times to interaction and lowered obstacles for heavily personalized content? The answer lies in decoupled components, or progressive decoupling. Instead of decoupling the entire page, why not decouple only portions of it, like individual blocks?

This component-driven decoupled architecture comes with big benefits over a fully decoupled architecture. Namely, traditional content management and workflow, display and layout management are still available to site builders. To return to our music website example, we can drag a block containing the songs a user listened to most in the past week into an arbitrarily located region on the page; a front-end developer can then infuse interactivity such that an account holder can play a song from that list or add it to a favorites list on the fly. Meanwhile, if a content creator wants to move the "most listened to in the past week" block from the right sidebar of the page to the left side of the page, she can do that with a few mouse clicks, rather than having to get a front-end developer involved.

We call this approach progressive decoupling, because you decide how much of the page and which components to decouple from Drupal's front end or dedicated Drupal renderings. For this reason, progressively decoupled Drupal brings decoupling to the assembled web, something I'm very passionate about, because empowering site builders and administrators to build great websites without (much) programming is important. Drupal is uniquely capable for this, precisely because it allows for varying degrees of decoupledness.

Drupal 8 is ahead of the competition and is your go-to platform for building decoupled websites. It comes with a built-in REST API for all content, a system to query data from Drupal (e.g. REST exports in the Views module), and a BigPipe implementation. It will be even better once the full range of contributed modules dealing with REST is available to developers.

With Drupal 8, an exciting spectrumopens up beyond just the two extremes of fully decoupling and traditional Drupal. As we've seen, fully decoupling opens the door to a Drupal implementation providing content to a broad range of one or more clients ("many-headed" Drupal), such as mobile applications, interactive kiosks, and television sets. But progressive decoupling goes a step further, since you can fully decouple and progressively decouple a single Drupal site with all the tools to assemble content still intact.

What is next for decoupling in Drupal?

In the case of many-headed Drupal, fully decoupled applications can live alongside progressively decoupled pages, whose skeletons are rendered through the CMS.

Although Drupal has made huge strides in the last few years and is ahead of the competition, there is still work to do. Traditional Drupal, fully decoupled Drupal, and progressively decoupled Drupal can all coexist. With improved decoupling tools, Drupal can be an even better hub for many heads: a collection of applications and sites linked and supported by a single backend.

One of the most difficult issues facing front-end developers is network performance with REST. For example, a REST query fetching multiple content entities requires a round trip to the server for each individual entity, each of which may also depend on relational data such as referenced entities that require their own individual requests to the server. Then, to gather the required data, each REST query needs a corresponding back-end bootstrap, which can be quite hefty. Such a large stack of round trips and bootstraps can be prohibitively expensive.

Currently, the only way to solve this problem is to create custom API endpoints (e.g. in Views) that comprehensively provide all the data needed by the client in a single response to minimize round trips. However, managing endpoints for each respective client can quickly spiral out of control given the range of different information each client might demand and number of deployed versions in the wild. On the other hand, if you are relying on a single endpoint, updating it requires modifying all the JavaScript that relies on that endpoint and ingests its response. These endpoint management issues can force the front-end developer to depend on work the back-end developer must complete, which creates bottlenecks in decoupled teams.

Beyond performance and endpoint management, developer experience also suffers under a RESTfully decoupled Drupal architecture. For each individual request, there is a single corresponding schema for the response that is immutable. In order to retrieve differently formatted or filtered data according to your needs, you must create a second variant of a given endpoint or provision a new endpoint altogether. Front-end developers concerned about performance limitations desire full control from the client side over what schema comes back and want to avoid working with the server side.

Decoupling thus reveals the need to investigate better ways of exposing data to the client side. As our pages and applications become ever more component-driven, the complexity of the queries we must perform and our demands on their performance increase. What if we could extract only the data we need by writing queries that are efficient and performant by default? Sebastian Siemssen proposes using Facebook's GraphQL (see demo video and project on drupal.org) due to the client's explicit definition of what schema to return and the use of consolidated queries which break apart into smaller calls and recombine for the response, thereby minimizing round trips.

I like GraphQL's approach for both fully and progressively decoupled front-ends. It means that decoupled sites will enjoy better overall performance and give front-end developers a better experience: very few round trips to the server, no need for custom endpoints, no need for versioning, and no dependence on back-end developers. (I even wonder if GraphQL could be the basis for a future version of Views.)

In addition, work on rendering improvements such as BigPipe should continue in order to explore the possibilities given a more progressive rendering system. It's currently in progress to accelerate Drupal's perceived page loads where users consume expensive or personalized content. As for tools within the administration layer and in the contributed space, further progress in Drupal 8 is also necessary for layout management tools such as Panels and block placement that would make decoupling at a granular level much easier.

A great deal is being done, but we could always use more help; please get in touch if you're interested in contributing code or funding our work. After all, the potential impact of progressive rendering on the future of decoupled Drupal is huge.


Decoupled content management is a rapidly evolving trend that has the potential to upend existing architectural paradigms. Nonetheless, we need to be cautious when approaching decoupled projects due to the loss of functionality and performance.

With Drupal 8, we can use progressive rendering to build a Drupal-driven skeleton of the page to fill out increasingly expensive portions of the page. We can then selectively delineate which parts of the page decouple once the page load is complete. This concept of progressive decoupling offers the best of both worlds. Layout management, security, and content previews are unaffected, and within page components, front-end application logic can work its magic.

Drupal 8 is now a state-of-the-art platform for building projects that lie at the nexus between traditional content-rich websites and modern interaction-rich web applications. As always, while remarkable strides have been made with Drupal 8, more work remains.

Special thanks to Preston So and Wim Leers at Acquia for contributions to this blog post and to Moshe Weitzman, Kevin O'Leary, Christian Yates, David Hwang, Michael Pezzi and Erik Baldwin for their feedback during its writing.

What Happened to Hook_Menu in Drupal 8?

Drupal News - September 24, 2015 - 5:46am

In Drupal 7 and earlier versions hook_menu has been the Swiss Army knife of hooks. It does a little bit of everything: page paths, menu callbacks, tabs and local tasks, contextual links, access control, arguments and parameters, form callbacks, and on top of all that it even sets up menu items! In my book it’s probably the most-used hook of all. I don’t know if I’ve ever written a module that didn’t implement hook_menu.

But things have changed In Drupal 8. Hook_menu is gone and now all these tasks are managed separately using a system of YAML files that provide metadata about each item and corresponding PHP classes that provide the underlying logic.

The new system makes lots of sense, but figuring out how to make the switch can be confusing. To make things worse, the API has changed a few times over the long cycle of Drupal 8 development, so there is documentation out in the wild that is now incorrect. This article explains how things work now, and it shouldn't change any more.

I’m going to list some of the situations I ran into while porting a custom module to Drupal 8 and show before and after code examples of what happened to my old hook_menu items.

Custom Pages

One of the simplest uses of hook_menu is to set up a custom page at a given path. You'd use this for a classic "Hello World" module. In Drupal 8, paths are managed using a MODULE.routing.yml file to describe each path (or ‘route’) and a corresponding controller class that extends a base controller, which contains the logic of what happens on that path. Each controller class lives in its own file, where the file is named to match the class name. This controller logic might have lived in a separate MODULE.pages.inc file in Drupal 7.

In Drupal 7 the code might look like this:

function example_menu() { $items = array(); $items['main'] = array( 'title' => 'Main Page', 'page callback' => example_main_page', 'access arguments' => array('access content'), 'type' => MENU_NORMAL_ITEM, 'file' => 'MODULE.pages.inc' ); return $items; } function example_main_page() { return t(‘Something goes here’); }

In Drupal 8 we put the route information into a file called MODULE.routing.yml. Routes have names that don’t necessary have anything to do with their paths. They are just unique identifiers. They should be prefixed with your module name to avoid name clashes. You may see documentation that talks about using _content or _form instead of _controller in this YAML file, but that was later changed. You should now always use _controller to identify the related controller.

example.main_page_controller: path: '/main' defaults: _controller: '\Drupal\example\Controller\MainPageController::mainPage' _title: 'Main Page' requirements: _permission: 'access content'

Note that we now use a preceding slash on paths! In Drupal 7 the path would have been main, and in Drupal 8 it is /main! I keep forgetting that and it is a common source of problems as I make the transition. It’s the first thing to check if your new code isn’t working!

The page callback goes into a controller class. In this example the controller class is named MainPageController.php, and is located at MODULE/src/Controller/MainPageController.php. The file name should match the class name of the controller, and all your module’s controllers should be in that /src/Controller directory. That location is dictated by the PSR-4 standard that Drupal has adopted. Basically, anything that is located in the expected place in the ‘/src’ directory will be autoloaded when needed without using module_load_include() or listing file locations in the .info file, as we had to do in Drupal 7.

The method used inside the controller to manage this route can have any name, mainPage is an arbitrary choice for the method in this example. The method used in the controller file should match the YAML file, where it is described as CLASS_NAME::METHOD. Note that the Contains line in the class @file documentation matches the _controller entry in the YAML file above.

A controller can manage one or more routes, as long as each has a method for its callback and its own entry in the YAML file. For instance, the core nodeController manages four of the routes listed in node.routing.yml.

The controller should always return a render array, not text or HTML, another change from Drupal 7.

Translation is available within the controller as $this->t() instead of t(). This works because ControllerBase has added the StringTranslationTrait. There's a good article about how PHP Traits like translation work in Drupal 8 on Drupalize.Me.

/** * @file * Contains \Drupal\example\Controller\MainPageController. */ namespace Drupal\example\Controller; use Drupal\Core\Controller\ControllerBase; class MainPageController extends ControllerBase { public function mainPage() { return [ '#markup' => $this->t('Something goes here!'), ]; } Paths With Arguments

Some paths need additional arguments or parameters. If my page had a couple extra parameters it would look like this in Drupal 7:

function example_menu() { $items = array(); $items[‘main/%/%’] = array( 'title' => 'Main Page', 'page callback' => 'example_main_page', ‘page arguments’ => array(1, 2), 'access arguments' => array('access content'), 'type' => MENU_NORMAL_ITEM, ); return $items; } function example_main_page($first, $second) { return t(‘Something goes here’); }

In Drupal 8 the YAML file would be adjusted to look like this (adding the parameters to the path):

example.main_page_controller: path: '/main/{first}/{second}' defaults: _controller: '\Drupal\example\Controller\MainPageController::mainPage' _title: 'Main Page’ requirements: _permission: 'access content'

The controller then looks like this (showing the parameters in the function signature)::

/** * @file * Contains \Drupal\example\Controller\MainPageController. */ namespace Drupal\example\Controller; use Drupal\Core\Controller\ControllerBase; class MainPageController extends ControllerBase { public function mainPage($first, $second) { // Do something with $first and $second. return [ '#markup => $this->t('Something goes here!'), ]; } }

Obviously anything in the path could be altered by a user so you’ll want to test for valid values and otherwise ensure that these values are safe to use. I can’t tell if the system does any sanitization of these values or if this is a straight pass-through of whatever is in the url, so I’d probably assume that I need to type hint and sanitize these values as necessary for my code to work.

Paths With Optional Arguments

The above code will work correctly only for that specific path, with both parameters. Neither the path /main, nor /main/first will work, only /main/first/second. If you want the parameters to be optional, so /main, /main/first, and /main/first/second are all valid paths, you need to make some changes to the YAML file.

By adding the arguments to the defaults section you are telling the controller to treat the base path as the main route and the two additional parameters as path alternatives. You are also setting the default value for the parameters. The empty value says they are optional, or you could give them a fixed default value to be used if they are not present in the url.

example.main_page_controller: path: '/main/{first}/{second}' defaults: _controller: '\Drupal\example\Controller\MainPageController::mainPage' _title: 'Main Page' first: '' second: '' requirements: _permission: 'access content' Restricting Parameters

Once you set up parameters you probably should also provide information about what values will be allowed for them. You can do this by adding some more information to the YAML file. The example below indicates that $first can only contain the values ‘Y’ or ‘N’, and $second must be a number. Any parameters that don’t match these rules will return a 404. Basically the code is expecting to evaluate a regular expression to determine if the path is valid.

See Symfony documentation for lots more information about configuring routes and route requirements.

example.main_page_controller: path: '/main/{first}/{second}' defaults: _controller: '\Drupal\example\Controller\MainPageController::mainPage' _title: 'Main Page' first: '' second: '' requirements: _permission: 'access content' first: Y|N second: \d+ Entity Parameters

As in Drupal 7, when creating a route that has an entity id you can set it up so the system will automatically pass the entity object to the callback instead of just the id. This is called ‘upcasting’. In Drupal 7 we did this by using %node instead of %. In Drupal 8 you just need to use the name of the entity type as the parameter name, for instance {node} or {user}.

example.main_page_controller: path: '/node/{node}' defaults: _controller: '\Drupal\example\Controller\MainPageController::mainPage' _title: 'Node Page' requirements: _permission: 'access content'

This upcasting only happens if you have type-hinted the entity object in your controller parameter. Otherwise it will simply be the value of the parameter.

JSON Callbacks

All the above code will create HTML at the specified path. Your render array will be converted to HTML automatically by the system. But what if you wanted that path to display JSON instead? I had trouble finding any documentation about how to do that. There is some old documentation that indicates you need to add _format: json to the YAML file in the requirements section, but that is not required unless you want to provide alternate formats at the same path.

Create the array of values you want to return and then return it as a JsonResponse object. Be sure to add ”use Symfony\Component\HttpFoundation\JsonResponse” at the top of your class so it will be available.

/** * @file * Contains \Drupal\example\Controller\MainPageController. */ namespace Drupal\example\Controller; use Drupal\Core\Controller\ControllerBase; use Symfony\Component\HttpFoundation\JsonResponse; class MainPageController extends ControllerBase { public function mainPage() { $return = array(); // Create key/value array. return new JsonResponse($return); } } Access Control

Hook_menu() also manages access control. Access control is now handled by the MODULE.routing.yml file. There are various ways to control access:

Allow access by anyone to this path:

example.main_page_controller: path: '/main' requirements: _access: 'TRUE'

Limit access to users with ‘access content’ permission:

example.main_page_controller: path: '/main' requirements: _permission: 'access content'

Limit access to users with the ‘admin’ role:

example.main_page_controller: path: '/main' requirements: _role: 'admin'

Limit access to users who have ‘edit’ permission on an entity (when the entity is provided in the path):

example.main_page_controller: path: '/node/{node}' requirements: _entity_access: 'node.edit'

See Drupal.org documentation for more details about setting up access control in your MODULE.routing.yml file.


So what if a route already exists (created by core or some other module) and you want to alter something about it? In Drupal 7 that is done with hook_menu_alter, but that hook is also removed in Drupal 8. It’s a little more complicated now. The simplest example in core I could find was in the Node module, which is altering a route created by the System module.

A class file at MODULE/src/Routing/CLASSNAME.php extends RouteSubscriberBase and looks like the following. It finds the route it wants to alter using the alterRoutes() method and changes it as necessary. You can see that the values that are being altered map to lines in the original MODULE.routing.yml file for this entry.

/** * @file * Contains \Drupal\node\Routing\RouteSubscriber. */ namespace Drupal\node\Routing; use Drupal\Core\Routing\RouteSubscriberBase; use Symfony\Component\Routing\RouteCollection; /** * Listens to the dynamic route events. */ class RouteSubscriber extends RouteSubscriberBase { /** * {@inheritdoc} */ protected function alterRoutes(RouteCollection $collection) { // As nodes are the primary type of content, the node listing should be // easily available. In order to do that, override admin/content to show // a node listing instead of the path's child links. $route = $collection->get('system.admin_content'); if ($route) { $route->setDefaults(array( '_title' => 'Content', '_entity_list' => 'node', )); $route->setRequirements(array( '_permission' => 'access content overview', )); } } }

To wire up the menu_alter there is also a MODULE.services.yml file with an entry that points to the class that does the work:

services: node.route_subscriber: class: Drupal\node\Routing\RouteSubscriber tags: - { name: event_subscriber }

Many core modules put their RouteSubscriber class in a different location: MODULE/src/EventSubscriber/CLASSNAME.php instead of MODULE/src/Routing/CLASSNAME.php. I haven’t been able to figure out why you would use one location over the other.

Altering routes and creating dynamic routes are complicated topics that are really beyond the scope of this article. There are more complex examples in the Field UI and Views modules in core.

And More!

And these are still only some of the things that are done in hook_menu in Drupal 7 that need to be transformed to Drupal 8. Hook_menu is also used for creating menu items, local tasks (tabs), contextual links, and form callbacks. I’ll dive into the Drupal 8 versions of some of those in a later article.

More information about this topic:

Matt Glaman: Fixing rotated images uploaded to Drupal from an iPhone

Drupal News - September 24, 2015 - 5:16am

iPhones 4 and up store images in landscape mode and use EXIF data to provide proper rotation when viewed. This is a bit quirky as not all desktop browsers provide fixes, or they may not be streamlined. I remember my old project manager telling me their images were showing up "flipped to the side" during mobile QA testing. Sure enough when the image was embedded in HTML it was cocked to the side - however when viewed directly in the browser or desktop it was fine. What? Luckily through some Google-fu I stumbled upon this great blog post detailing how "" True words.

I am guessing you landed here from a Google search and want to solve this problem. You are in luck - check out the project. Originally it spawned , but Dave Reid suggested its better as a standalone module so all files can be fixed - not just sites using File Entity. Typically Drupal takes a "manipulate on render" approach. This module does not. The image will be manipulated on upload to the proper rotation. Here is the reason: what if you want to display the original file and not a derivative? That is going to be embedded in an image tag and probably not render right. Secondly one would have to make sure every single image style added this filter. There is enough button clicking when setting up a Drupal site.

If you wold like to give it a test, checkout out these example files repository from the aforementioned blog: https://github.com/recurser/exif-orientation-examples.

I also would like to note that ImageCache Actions provides this functionality, but as a submodule and as an image filter. I wish I could remember who pointed this out, but it was discovered a few months after the project. But, again, with my previous arguments a filter does not cut it.

Steve Purkiss: Remote DrupalCon - Day 2

Drupal News - September 23, 2015 - 12:15pm
Wednesday, 23rd September 2015Remote DrupalCon - Day 2

Let's never do that again

Unlike when I was watching yesterday's Driesnote, I actually quite expected these sorts of words to come out of the mouth of Larry Garfield, aka @crell, long-time Drupal contributor and the reason I stayed up way too late last night after blogging so not strictly Day 2 but deserves a mention as was a superb, insightful session "Drupal in 2020".

The never do that again refers to the four-or-so years spent on developing Drupal 8 with most of that time spent not developing new stuff but just barely catching up with modern technology trends. In order to be relevant even with today's technologies we need to be looking at what we could be doing and Larry shows off a number of impressive development projects which enable PHP to run in a similar way to node.js - even faster in many cases. Well worth a watch!

I ended the night with Ken Rickard's 2020 Vision, an entertaining session from a highly experienced professional reminding us that we are implementing a content management system, not a web publishing tool which comes from the print era, and thus there are many different considerations, and often many of the non-technical ones are overlooked whereas they can prove to be the biggest obstacles.

Day 2 Keynote - Web Psychologist Nathalie Nahai

I'd seen Nathalie talk before so I must admit I wasn't paying much attention until I saw a question pop up on twitter asking how this session mostly on marketing manipulation techniques was relevant to our community. Nathalie quickly focused on how we could use some of the techniques to help our current community as well as attract new people in by simply telling our story. A well-deserved round of applause came when Nathalie remarked:

"This is such a vibrant community it needs to be expressed online much more"

This is a big area of interest to me as I see so many wonderful stories from around the Drupal world yet currently the loudest voices being heard are the ones with funding. I've not an issue with that per se, I believe we could do more by collaborating together on strong marketing messaging.

I know the DA are doing as much as they can with the resources they have available, however I believe there is a place in the market for an organisation which markets the community as a whole - I envisage trucks that turn into training rooms / 24h coder lounges with schwag stores on board so can rock up to camps all over the place ;) But I guess that's another blog for another time - all I know is I'd love to go round the world interviewing the community for all to see & potentially training many more unexplored areas up in our community values of ownership!

Making the Leap: Successful Products as a Web Agency

Drawing from his own experience with Drupal offsite backup service NodeSquirrelDrew Gorton from managed hosting service providers Pantheon gave an interesting talk covering how quite a few product businesses had managed to make the uncommon successful birth from an agency. Drew provides useful insights I empathise with as I much prefer working in the product world however what with my bootstrapping and co-operative ideals it's taking a little longer than I'd hoped for ;)

Self-Managing Organizations: Teal is the new Orange

This was a really interesting session from a company I hadn't heard of before - Liip. Their organisation is around the 120 people mark and they have a self-organising way of working, with the ratio of pay difference between high and low 3-1. I beleive the company is also owned by the staff however I don't think the percentages were detailed, will have to watch again. They said they had no plans and let teams decide their own projects, strategies, etc. Obviously it's not all plain-sailing and provided a for a great case-study in things going certainly a better way in terms of fairer working environments and enabling human beings to grow rather than be stunted by job roles.

I watched a little of Shut up and take my money! which was about integrating the Stripe payment system with Drupal 8. I've done this previously and nothing much seemed to be different on the Stripe side so moved on - the videos are pouring in quick & fast!

I then watched Expose Drupal with RESTful for a short while until I realised it was 7 so moved on to PhpStorm for Drupal Development which was a fairly short session clocking in at 15 minutes however very useful, even pointing out a feature which shows you what features you have and haven't been using. I'm no fan of the licensing on PhpStorm but it does make life much easier so will be harder to give up than my macbook but I guess will have to be done at some point if I'm going to achieve complete Freedom!

Headless D8 in HHVM plus Angular.js

It was noted from the outset that this was a sponsored session from platform.sh so they would be showing off their product, which I've had the pleasure of playing around with a little on a time-limited trial, however I was suckered in by the buzzwords so I stuck it out. Being at home it was even easier for me to just click the mouse than suffer potential slight embarrasment as I walk out of the session room but in reality that rarely happens and I end up sitting right through the session continually questioning myself as if I were watching the fifth instalment of Jaws wondering wether an incident with a fish will happen at some point.

Suffice to say platform.sh works with HHVM and Angular.js. I've nothing against sponsor talks or platform.sh, I think they are both good things, just not this session, for me at least. I guess I wanted to see something shiny, not just a product demo, I feel they could've made a lot more out of the title than they did without having to be so focused on the continual sales pitch. Which I know that's what it was, but felt more like something that should've been out in the exhibit hall. I guess that doesn't get videod and put into the stream though.

I started to watch Altering, Extending, and Enhancing Drupal 8 by Joe Shindelar (@eojthebrave) whom I've had the pleasure of meeting at a number of Drupal events here & in the US. Joe's a great teacher, but for me as I've been playing with Drupal 8 for a while now I decided to skip on, especially when he said "Don't hack core" which is I know the thing, but in Drupal 8 I plan to hack core by simply using its interfaces... it's made for 'hacking' this time. Properly hacking that is of course! I realise this presentation wasn't for me though.

Then I watched a little Building amazing searches with Search API but all was looking pretty similar to 7 so thought I'd put that one on the watch when I have a specific need for it list. Then came along a truly awesome session...

Avoiding and surviving of contribution burnout

As someone who has suffered from depression I am particularly proud of the fact our community can have sessions that cover topics like this. I feel like I'm coming from a different angle as I'm spending most of my time working out how and where I can be of help and it's the client work if anything that's burning me out due to my complete lack of wanting to do anything other than write beautiful code, and I've not yet met a client who has the want or budget to pay me to do that. Sarcasm aside, burnout is a big issue, and something I have an issue with the business/community balance side as I believe one is currently gaining far more benefit out of the other than there should be and I don't really think it's anything that can't be solved with a more balance put back into the situation. That of course is not to make light of anyone's situation, just how I see the situation from my many travels around camps and to CXO meetups and my experience in the world up until now.

Pain Points of Contribution in the Drupal Community

Along similar veins to the previous session, Kalpana Goel delivers another important session trying to untangle the issues surrounding contibuting to the community and how we can potentially go about solving them.

Then I watched around half of Hassle-free Hosting and Testing with DevShop & Behat which looks like an interesting, open, option for self-hosting your own sites. Being a little tired I thought I'd come back to that when I'm more awake one weekend.

Last one for the day was The future of Groups on Drupal.org, which gave an interesting insight into forthcoming changes on drupal.org, much powered by the persona work done previously, so should be interesting when I log in and tailored content appears for me! It's great to see movement finally here, but I agree with Dries when he said previously it really needs perhaps ten million dollars of investment in it. ATEOTD, if you don't look after your tools you won't be able to make a decent product. It's always been my hope that as we talk about Drupal more, about the Why, and show people around the world what we're building the community will organically scale as people will want to be part of it. I think we have a number of issues in the way of that at the moment - perception, current human fear-driven non-sharing society, and state of internal systems. It's good to see a little focus going on the things we can fix now, hopefully we can scale it up soon so we don't get more fractured across different proprietary community silos just because they're 'easy'.


Well I may not be in Barcelona but I'm certainly ranting like I'm at DrupalCon, just on the record lol! With all the tweets and session-watching I'm certainly getting DrupalCon tired so signing off for the night, looking forward to the final day of sessions tomorrow with another important keynote and of course looking forward to finding out where next year's European DrupalCon will be - hopefully I'll plan a little better and build a little buffer so I don't miss out!

Unfortunately my comments are broken on this site so whilst I'm migrating to Drupal 8, do please tweet me @stevepurkiss or get in touch via my contact form.

tags: drupalconremoteDrupal PlanetPlanet Drupal

Annertech: DrupalCon Barcelona 2015 Day 3

Drupal News - September 23, 2015 - 11:06am
DrupalCon Barcelona 2015 Day 3

Wow! What a day we had at DrupalCon Barcelona 2015. I know, personally, I had the best day i've ever had at a DrupalCon, attending a great keynote on web psychology, a talk that validated my thoughts on design in the browser, an awesome presentation on linked data and the semantic web, and that's without mentioning the BoFs on web apps versus websites and Twitter Bootstrap, and then ... oh man - that was a lot.

So, today's best bits:


Modules Unraveled: 149 Using Panopoly and it's Drupal 8 Future with David Snopek - Modules Unraveled Podcast

Drupal News - September 23, 2015 - 9:54am
Published: Wed, 09/23/15Download this episodeProject
  • For people who might not know, what is a Drupal distribution?

    • Out of the box, vanilla Drupal doesn’t do much - you have to install modules and mold it into what you want
    • A distribution is Drupal prepackaged with contrib modules and themes, pre-configured for a specific use case (OOB, X+Y)
  • What is Panopoly?

    • A “starter site” distribution (replacement for vanilla Drupal)
    • A “base distribution” on which to build other distributions
    • A set of Features modules that can be used outside of Panopoly
  • Why would someone want to use Panopoly instead of vanilla Drupal?

    • Improved blank slate
    • Includes some the most popular modules and configuration that almost everyone is using anyway
    • Hide Drupal-isms from site managers and users
    • WYSIWYG, Media, responsive layouts, edit in place, live previews, improved search, UX improvements, a11y improvements
    • Include a bunch of stuff backported from D8: toolbar, responsive bartik, etc
    • Unified content/layout management system built on Panels eco-system
    • Rather than learning all that community knowledge over, re-use a well thought out, tested approach to doing Drupal
  • Some people love Panels, but others hate it. Why would someone who isn’t a “Panels lover” want to use Panopoly?

    • Best of Panels eco-system
    • You build with Views, Entities/Fields, custom code, whatever - the Panels bits tie those things together and allow users to customize them
    • We hide the nastiest bits (page_manager UI) from users and site managers
  • Why would someone want to create their own distro?

    • Boilerplate, build once / deploy lots, maintenance of lots of sites
    • Even small organizations can benefit
  • What advantages do you get by build your distro on Panopoly?

    • Like “base theme” shared work (like WYSIWYG, responsive, etc) and defined approach
    • Focus only on the unique stuff in your distro (by fitting into Panopoly’s architecture)
  • Why would someone want to use one of Panopoly’s Features modules outside of Panopoly?

    • [Quick background on Feature]
    • Dozen or so features
    • If like just a piece of Panopoly (ex. panopoly_wysiwyg) you could steal it!
    • Lots of thought into buttons to enable, filtering for control/security, additional features like Media/Linkit
  • Updating distributions can be hard. What does Panopoly do to help with this?

    • [explain why hard]
    • Docs
    • CI
    • distro_update
  • Security updates in particular can be hard, because you have to wait for the distro to make its own update. How does Panopoly handle them?

    • [mention how handled in the past / security team]
  • What are the plans for Panopoly in Drupal 8?

Episode Links: David on drupal.orgDavid on Twitter (@dsnopek)David on Twitter (@mydropninja)David on webPanopoly project pagePanopoly demo from DrupalCon Austin (demo starts at 18:15)#drupal-scotch on IRC#Panopoly on IRCPanopoly groupTags: planet-drupal

InternetDevels: The 10 Commandments of User Interface Design

Drupal News - September 23, 2015 - 7:15am

Design is not just what it looks like or feels like, design is how it works.

Read more

KnackForge: TRANSLATION in Drupal 7 : How to work with

Drupal News - September 23, 2015 - 4:48am

In the previous part, we discussed about the Translation in Drupal 7 works with few snapshots and some makeovers. Now, lets discuss how to work with translation to translate the contents, field values and entity items.

1) Translating Menus

With Drupal core alone, user-defined menu items are not translatable. The Menu translation module, part of the Internationalization (i18n) package, allows users to select a translation mode for each menu.

The following modes are available:

  • No Multilingual Options

  • Translate and Localize

  • Fixed Language

Translate and Localize Menus

There are two ways that menu items will be translated:

  • You can set a language when creating a custom menu item so that the menu item will only show up for that language. Menu items that link to nodes in a particular language will be treated this way.

  • You can localize other custom menu items without a language (for example, menu items linking to views pages). Use the Translate tab to translate the menu item title and description. Translators can also use the 'Translate interface' pages to translate these menu items.


Wim Leers: Making Drupal fly — The fastest Drupal ever is here!

Drupal News - September 23, 2015 - 3:59am

Together with Fabian Franz from Tag1 Consulting, I had a session about Big Pipe in Drupal 8, as well as related performance/cacheability improvements.

I’ll let the session description speak for itself:

With placeholders (https://www.drupal.org/node/2478483) having just gone into Drupal 8 Core, BigPipe being unblocked now and actively making its way in, Render Strategies around the corner, and out-of-the-box auth-caching in CDNs + Varnish a true possibility on the horizon, those are really exciting times for Drupal 8 Performance. But there is even more …

Come and join us for a wild ride into the depths of Render Caching and how it enables Drupal to be faster than ever.

The Masterplan of Drupal Performance (Next steps)

Here we will reveal the next steps of the TRUE MASTERPLAN of Drupal Performance. The plan we have secretly (not really!) been implementing for years and are now “sharing” finally with all of you! (Well you could look at the issue queue too or this public google doc, but this session will be more fun!)

Learn what we have in store for the future and what has changed since we last talked about this topic in Los Angeles and Amsterdam and why Drupal 8 will even be more awesome than what you have seen so far.

Also see a prototype of render_cache using the exact same Drupal 8 code within Drupal 7 and empowering you to do some of this in Drupal 7 as well.

Get the edge advantage of knowing more

Learn how to utilize cache contexts to vary the content of your site, cache tags to know perfectly when items are expired and cache keys to identify the objects - and what is the difference between them.

Learn how powerful ‘#lazy_builders’ will allow the perfect ESI caching you always wanted and how it will all be very transparent and how you can make your modules ready for the placeholder future.

See with your own eyes how you can utilize all of that functionality now on your Drupal 7 and 8 sites.

Get ready for a new area of performance

We will show you:

  • How to take advantage of #lazy_builders
  • How to tweak the auto-placeholdering strategies (depending on state of issue at time of session)
  • The biggest Do’s and Don’ts when creating render-cache enabled modules and sites
  • Common scenarios and how to solve them (mobile sites variation, cookie variation, etc.)
  • Drupal using an intelligent BigPipe approach (but a different one, one that is way more like Facebook does it …)
Get to know the presenters

This session will be presented by Wim Leers and Fabian Franz. Wim implemented a lot of what we show here in Drupal 8 and made the APIs easy and simple to use and made cache tags and #lazy_builders a very powerful concept. Fabian has prototyped a lot of this concepts in his render_cache module, introduced powerful Drupal 8 concepts into Drupal 7 and is always one step ahead in making the next big thing. Together they have set out on a crusade to rule the Drupal Performance world to bring you the fastest Drupal ever and with that trying to make the whole Web fast!

Frequently Asked Questions
  • I have already seen the session in Amsterdam and Los Angeles, will I learn something new?

Yes, absolutely. While the previous sessions focused more on the basics, this session will also cover how to use #lazy_builders and custom render strategies to empower your Drupal to be fast.

  • Will there again be a demo?

Yes, there will again be a nice demo :). You’ll love it!

  • Is it even possible to make it even faster than what we have seen?

Yes :)

Slides: Making Drupal fly — The fastest Drupal ever is here!Conference: DrupalCon BarcelonaLocation: BarcelonaDate: Sep 23 2015 - 14:15Duration: 60 minutesExtra information: 

See https://events.drupal.org/barcelona2015/sessions/making-drupal-fly-fastest-drupal-ever-here.

DrupalCon News: Group Photo Timelapse

Drupal News - September 23, 2015 - 3:48am

Thank you to everyone who came out to jump in the group photo!  Check us out.

Thank you to Petr Illek for making the timelapse!

undpaul: DrupalCon Barcelona 2015: Get your poster

Drupal News - September 23, 2015 - 2:34am

We folks at undpaul love Drupal swag. At DrupalCon Amsterdam, we gave away over 500 shirts for free, which was a huge success. 

drupal planet english

KnackForge: Responsive vertical column layouts using jQuery Plugin

Drupal News - September 23, 2015 - 1:22am

Usually while we add contents to a div, it get arranged accordingly to our web styles. But there are some special cases where we need our contents to be arranged in a vertical manner as like the newspaper (or) journal content. To achieve this vertical fashion of content alignment, after a very long and vast search, we found these jQuery plugin to customize the column layouts dynamically based on these plugins:

  • columnizer.js

  • isotope.js

Note: This can be easily acheived with the help of Bootstrap themes as in Drupal 7. These plugin are for the non-bootstrap theming to achieve this kind of result.

The columnizer plugin is such kind of plugin which aligns our content all into a adaptive layout, which is also responsive and kind of interesting too. It does provide us a lot of options to get our content aligned in the layout like newspaper material, journal like stuff and etc.

Now, let us know what's all we need to do are these. Just prepare all your html document and download the columnizer plugin from here

To use columnizer, just call the columnize() function on your jQuery selection, and that’s it! we are ready to go.

Syndicate content