Planet Drupal

Subscribe to Planet Drupal feed - aggregated feeds in category Planet Drupal
Updated: 17 min 44 sec ago

J-P Stacey: My Drupalcon Barcelona notes

Sun, 27/09/2015 - 12:34

As with previous years, I maintained notes on a publicly available Google Doc during Drupalcon Barcelona. I've tidied them up below for future reference, and added links to the recorded sessions where possible.

NB: these are rough notes made during talks. Please take with a pinch of salt.

Read more of "My Drupalcon Barcelona notes"

Categories: Elsewhere

DrupalCon News: Thank you for coming to DrupalCon Barcelona

Sat, 26/09/2015 - 16:19

Thank you so much for attending DrupalCon Barcelona.  We had an amazing time and hope that you did too.  

After each Con, we ask that you please let us know how it went so we can see what we can improve for next time.  Please

Fill Out the Survey

Categories: Elsewhere Watch Drupalcon Barcelona 2015 sprinting on

Sat, 26/09/2015 - 14:43
One little Drupal community secret: the main-event of a DrupalCon might be sprinting... A code sprint is getting developers for a set amount of time – usually one to two days – and just writing code. That's it. You're not teaching anything. Participants will learn from others as they go, but the...
Categories: Elsewhere Watch Drupalcon Barcelona 2015 sessions on Youtube

Sat, 26/09/2015 - 14:34
More than 125+ sessions from last week's Drupalcon in Barcelona are on Youtube: Posted by the Drupal Association. Hope you can learn from it too! Session tracks Business and Strategy Business Showcase Coding and Development Content Strategy Core...
Categories: Elsewhere

Drupal core announcements: PHPTemplate will be removed from Drupal 8 core

Sat, 26/09/2015 - 14:27

Since 2013, PHPTemplate is no longer used in Drupal 8 core and has been replaced by the Twig theme engine.

In 2014, we enabled Twig's autoescape feature in Drupal 8 to provide a more secure foundation for themers. To take full advantage of this feature, core relies on Twig to perform the final escaping of many variables. PHPTemplate is not compatible with this approach, currently insecure, and no longer supported, so it will be removed from Drupal 8 core.

Most Drupal themes that used PHPTemplate in Drupal 7 should be updated to use Twig. Drupal core will also still support multiple theme engines, but alternate theme engines will also need to provide some means of escaping unsafe output or risk security vulnerabilities.

Issue where this change is under discussion: Remove PHPTemplate, and add test coverage for multiple theme engine support

Categories: Elsewhere All Children over 5 Deserve an iPad?

Sat, 26/09/2015 - 13:13
Categories: Elsewhere

Cocomore: DrupalCon Barcelona 2015 – the last days

Sat, 26/09/2015 - 00:00

On the last day, many sessions were held and a keynote took place early in the morning again. Initially, David Rozas made a presentation on Community Contribution and following this, Mike Bell gave a moving speech about Mental Health.

Categories: Elsewhere

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

Fri, 25/09/2015 - 23:29

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.

Categories: Elsewhere

Zivtech: Introducing Probo.CI

Fri, 25/09/2015 - 18:00

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 The part that is different from 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, 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.

Categories: Elsewhere

Chapter Three: ADFS and SimpleSAMLphp with Drupal

Fri, 25/09/2015 - 17:56

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

Categories: Elsewhere

LevelTen Interactive: DriesNote: DrupalCon Barcelona 2015

Fri, 25/09/2015 - 17:04

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

Categories: Elsewhere

Matt Glaman: Drupal Commerce flamegraphs and performance.

Fri, 25/09/2015 - 15:04

 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.

Categories: Elsewhere

InternetDevels: Lviv Euro Drupal Camp 2015: Schedule and Reports

Fri, 25/09/2015 - 14:19

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
Categories: Elsewhere

Steve Purkiss: Remote DrupalCon - Day 3

Fri, 25/09/2015 - 11:12
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 - 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 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
Categories: Elsewhere

Amazee Labs: DrupalCon Barcelona - Day 4

Fri, 25/09/2015 - 11:00
DrupalCon Barcelona - Day 4 Claudine Braendle Fri, 09/25/2015 - 11:00

Thursday started well, as I was past the stress of giving a talk in front of a room full of people. I barely made it to the keynote, but got there just in time to see the two community keynotes, by David Rozas and Mike Bell. 

A lot of topics this year turned around the health of the Drupal community, and the two smaller keynotes didn’t disappoint.

David Rozas spoke about his PhD research on the Drupal community and Commons-Based Peer Production (CBPP). Some of the points that came out where the fact that affective contribution like organising event is underrepresented and undervalued in the open source community, although this affective contributions are essential to help it scale and grow without losing the sense of community.

Mike Bell then went on stage and stunned everyone with his raw and honest keynote on his mental health condition. He spoke very openly about a subject that is taboo, especially in the work-life, but also talked about the cost of depression for the company and what can be done to help people you work with. 

After the coffee break I went to watch my colleague Josef Dabernig and Adam Juran’s presentation Building layouts from 7 to 8: Coding vs Clicking. The talk was fast-paced and looked at different types of templates like landing pages or simple pages, and showed us the different approaches to building these with the Drupal interface or in the theme with code. The code was full of in-depth information the state of modules like panels, page manager and display suite in Drupal 8 and what methods are already available in D8 and what still needs workarounds. 

After lunch I went to see the presentation about Visual Regression Testing by Amitai Burstein, which is something that has been on my mind a lot in the last two years with the growing complexity of front-end code.

The last talk I watch, but this time online, where the usability results presented by Angie Byron, Bojhan Somers and Lewis Nyman Making Drupal a better out-of-the-box product: Report on usability testing results and how we can make 8.1.x+ shine.

The day ended with a great Closing session and the much-loved Trivia Night!

Categories: Elsewhere

Annertech: DrupalCon 2016 is Coming to Dublin!

Thu, 24/09/2015 - 19:00
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 - 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.

Categories: Elsewhere

Dries Buytaert: The future of decoupled Drupal

Thu, 24/09/2015 - 16:43

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 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.

Categories: Elsewhere

Lullabot: What Happened to Hook_Menu in Drupal 8?

Thu, 24/09/2015 - 15:46

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 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' => '' ); 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/first/second’] = 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 obviously means you should be careful how you name your custom parameters to avoid accidentally getting an object when you didn’t expect it. Treat entity type names as reserved words that should not be used for other parameters. Or maybe even add a prefix to custom parameters to ensure they won’t collide with current or future entity types or other automatic mapping.

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 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 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.

Categories: Elsewhere

InternetDevels: Drupal 8 development: useful tips

Thu, 24/09/2015 - 15:34

Hello, everyone! The release of Drupal 8 is almost here, but its beta version is already vailable for use. So let's explore Drupal 8 together.

Read more
Categories: Elsewhere

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

Thu, 24/09/2015 - 15:16

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:

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.

Categories: Elsewhere