Nov 25 2015
Nov 25

Post date: 

November 26 2015




drupal planet, drupalcampmelbourne, drupal

This is the second year that DrupalCampMelbourne has been run in it’s current form, and it’s expected to be just as much fun as it was last year, but maybe just a bit bigger.

DrupalCampMelbourne is a two day event, with one day of sessions and one day of code sprints, but the way it’s run is a little bit unique (as far as we know). Unlike a conventional Conference or Camp, the scheduling is 100% determined by the attendees on the day.

How does that work you ask?

It’s relatively simple:

  1. First thing Friday morning all attendees get the opportunity to do a short lightning talk explaining the topic they wish to cover.
  2. During the lightning talks, all attendees will vote on the sessions they wish to see.
  3. Finally, after all lightning talks and voting is complete, the DrupalCampMelbourne website auto-magically builds the schedule based off the votes, number of sessions and room sizes.

We ran this approach for the first time last year and it worked superbly, and with a little tweaking to the algorithm this year we expect it to be just as good, if not better.

The major benefits of this approach are:

  1. Everyone gets an opportunity to have their say, both in submitting a session and in voting on what they’d like to see.
  2. No “committee” or “track chairs” are required to vet every talk and make the final decisions, reducing the organisational time of the event.
  3. SkyNet is one step closer to taking hold of us all… oh wait.

So if you are coming (you are coming right?), make sure to get their early and have your say. And remember, everyone has something worth saying and worth hearing, and there’s nowhere better to start than a local community.

There are still some tickets left for the event, so if you haven’t got yours, get it now:

The future (a.k.a, SkyNet?)

The auto-magic scheduling of the talks is but the beginning, just as the day of session is just the beginning of DrupalCampMelbourne.

Day 2 of DrupalCampMelbourne is, as it was last year, a Code Sprint. This year, I will be running a sprint on the future of the DrupalCampMelbourne website in the hopes to make it even better; more autonomous, more usable and also more generic.

More autonomous

The “auto-magic” scheduling feature is a great help for running a DrupalCamp, it helps get Day 1 all sorted with minimal effort, but it’s not the only part that can be automated and improved. A larger portion of the camp itself could be automated.

If, when setting up the next camp, one where to provide the site with the date of the event, the camp could set a schedule for the organisers (when to have venue booked by, when to contact sponsors, etc), it could transition through various states (register your interest, event information, signup, etc), it could manage the budget (venue cost + resource costs - sponsors - tickets = success) and much more.

The possibilities are endless.

More usable

There’s no question that there have been some issues, certain information lacking, not enough communication, and other various management related issues; this is inevitable when the number of volunteers is in the low single digits and the time those volunteers have is equally lacking.

DrupalCampMelbourne is as open source as it can be at the moment, the source code is entirely available on ( for anyone at all to contribute to. This year I want to push forward and get more people involved, let’s ensure the site is more usable in the future, makes more information available and the site provides the missing communication it needs.

More generic

There is absolutely no reason that this project should be specific to DrupalCampMelbourne, nor even a DrupalCamp at all, it could apply to any type of Camp style event in any locale.

Genericising the existing work and building a new DrupalCamp/Camp Drupal distribution has been a goal from the very start, and with Drupal8 out it’s the best time to do exactly that.

So come along to DrupalCampMelbourne 2015 on Saturday (and Friday) and get involved. This is only one of the various sprints that will be being run during the Code Sprint. And don’t forget, a Code Sprint isn’t just for developers, there’s something for everyone, from novice to professional.

Nov 25 2015
Nov 25

As with many crazy ideas this all started in a bar. No ordinary bar, this was DrupalCon Barcelona Trivia Night. @BarisW said “so what are you going to do about Drupal 8’s release, we’re relying on you”. I was phased, but it set my mind in motion.

I am one of those people who, when faced with a challenge, believe the impossible is possible. How do I reach every corner of the globe and spread the word of this amazing new Drupal 8 thing? This is the story of how Celebr8D8 came to be, and I didn't do it alone.

Why was so driven to this?

Simple. Whilst I have been very fortunate to have attended many DrupalCons, experienced the scale and diversity of the Drupal community first hand, many have not. Many never will. Few have any concept of the global movement which builds the software. It all happens behind closed doors. I wanted to show to the world there are people in every place across the globe involved in Drupal. Of every creed, colour and background.

Germinating the ideas

So I decided it would be a interesting project to try and persuade as many people as I could muster, from as broad backgrounds as I could get, to film themselves saying a script about Drupal 8. This could then be edited to feature each person in sequence. The inspiration came from these two pop videos. Cry and Band Aid.

Like most big ideas in Drupal this was going to need help. Enter Jeffrey A. "jam" McGuire, Robert Douglass and Campbell Vertesi. A few emails later we had a concept. Then out the blue Campbell suggested Celebr8D8. BOOM! I instantly knew this was the stroke of genius upon which to hand our idea from. Jam and I had skype chats, created obligatory google docs, sent dozens of persuasive emails. In less than 2 days between us we had a concept, script and list of 20+ people willing to take part.

Then out the blue Campbell suggested Celebr8D8. BOOM! I instantly knew this was the stroke of genius

But then I thought, wouldn’t it be amazing to make a Drupal 8 site for this film to live on. And how about we secretly approach dozens of people to film themselves talking about what Drupal 8 meant to them. Using Jam’s and my little black books we emailed as many people as we could think with sample videos inviting people to join in.

Meanwhile I twisted a few arms - Amy Leak (Designer), Matt Smith (Developer), Alison Hover (Themer), James Hall (Site Builder) all committed to creating the Drupal 8 site. They were amazing, literally a self managed team who made magic.

It was all coming together, or so I thought. Time was passing and I was becoming anxious. As social media lead for Drupal, I was one of the few people who knew down to the hour when Drupal 8 was coming out. 4 days to go and no crowd sourced videos. I stayed up until the early hours emailing people, persuading them to commit. Slowly the films started to trickle in, then a wave.

Meanwhile, the feature film submissions were coming in thick and fast. Enter Graham Brown (@vaccineMedia), producer of the film. Working into the early hours for several days with little direction he created the film we all saw watched on release day. And then Jam told us he’d had a call to go to Antwerp to meet Dries, with a film crew (thanks Acquia!). Suddenly we an exclusive, the big guy was in. Sometimes I think destiny has a part to play in life, this was one of those days.

And then Jam told us he’d had a call to go to Antwerp to meet Dries, with a film crew (thanks Acquia!). Suddenly we an exclusive, the big guy was in

But how do we get people to know about this site?

So we had an amazing film coming together, a site and dozens of community films flying in from around the globe. But how do we draw an audience? Well if there’s one I’ve learnt in Drupal, if you can inspire the community into action amazing things happen. So I set about enabling another mad idea I had - “The social media Mexican wave”.

I thought that if I could contact a person in every country where there is Drupal and ask them to retweet one tweet about our site, at a certain time in their local timezone, we could achieve something interesting. Chasing the sun around the globe, a steady rhythm of retweets would ripple across the world like the Mexican Waves in 1990’s football crowds.

[embedded content]

So I created a webform for people to volunteer, sent a couple of tweets linking to the form and went to bed. In the morning I had a tonne of retweets and more importantly 199 volunteers with a potential reach of 350000 people! Wow! So I emailed the volunteers and primed them with my plan so that come Drupal 8 release day they could support us on social media, give us a boost!

Another secret piece to my social media master plan was to ask people Twitter username when they submitted films. Whilst moderating each film, I took a screenshot, added it to a scheduled tweet in Hootsuite with a link to the page on our site, and @mentioned the person in the tweet. Doing so would guarantee that person noticed, hopefully was flattered and duly retweeted. Each tweet was carefully primed to go out at the right time, when that person was awake, in their part of the world. Naturally most people retweeted and boosted our impact. (an export of these tweets is available to download below, with stats so you can copy my ideas)

The hashtag #Celebr8D8 was the icing on the cake. The Drupal Association contacted me and we asking what hashtag could be used for the 207 release parties happening around the world. They loved the one we had planned and asked if they could use it too. Well no one owns hashtags, I thought it would be fun and more effective to combine efforts.

So come 9am 19th November 2015 the first tweet announcing the site went out as I slept. Thanks Hootsuite (and many others to follow that day). In New Zealand Josh Waihi’s short film launched the site with a humble tweet, and lit the touch paper of what became a 24 hr period which saw our campaign reach 250,000+ people. The Drupal community really got behind the idea, our films were watched thousands of times, a huge feeling of being connected was achieved.

We were very fortunate to have the full power of, provided for FREE (thanks Robert Douglass!), so we knew that no matter how busy the site got, it would stay up. I’m sure Platform hardly noticed, but I was pretty stoked when I noticed there were 386 visitors on the site at one moment.

Was it a success?

What started as an idea by one person and a few friends took flight and it felt like the whole world joined us. People from 115 countries in the world came to the site, watched our films. For the 7 hours between 10:00 and 17:00 GMT the site sustained over 200 concurrent users. We supported 7,396 sessions by 5,474 users and 22,061 page views. Not bad for an entirely volunteer team who had less than 2 weeks notice.


222.5K impressions in 3 days. The main announcement Tweet reached 48,042 people with 309 retweets.

We asked people what #Drupal8 means to them. Their response will delight you #celebr8d8

— Celebrate Drupal 8 (@celebr8d8) November 18, 2015

Celebr8 Drupal 8 the Film

Graham's headline film was watched 1596 times in 24 hours.

[embedded content]

Who's were the most popular films

I know how the Drupal community are so competitive, so these are in popularity order.

  1. Dries and Jam Belgium and NZ
  2. MortendK Denmark
  3. Drupal Association USA
  4. StavrianaNathan
  5. Grienauer Austria
  6. Noah Australia
  7. Net Studio Greece
  8. Lewis and Emma UK
  9. Andrew McPhaerson UK
  10. Amazee Switzerland
  11. @shyam_raj
  12. Steve Purkiss UK
  13. Dave Hall Australia

Stats available below

You will see below more remarkable stats I’ve taken from Google Analytics, Twitter Analytics and Bitly. In the spirit of open source, there is also a spreadsheet with some of the top level stats and some PDF’s you may use and distribute freely under Creative Commons Attribution-ShareAlike 3.0 license

All of this makes me very happy. But it would not have been possible without some very special people. I’d like to close by saying a huge thanks to Jeffrey A. "jam" McGuire and his lovely wife Francesca who tolerated me hijacking him for best part of two weeks to pull help pull my mad plan together. Without Jam this would not have been possible, nor as amazing. And to Graham, Matt, Ali, James and Amy for tirelessly working on the film and site!

Let’s do it again some time, but for now, can I have a rest?

In the meantime here are few of my favourite tweets from this very memorable day .....

Following are some of my favourite tweets

With so many to choose from, here are a selection from the tweets I favourited on Twitter.

Drupal Saudi Arabia

????? ????? ????????????? #?????? #?????? #Celebr8D8 #Drupal8 #drupal ??? ???@Raeda1 @DrupalAssoc @celebr8d8 @drupal

— Essam Al-Qaie (@EssamAlQaie) November 19, 2015

Cerebr8ting Drupal8 in Munich! #Celebr8D8

— Maria Blum (@BlumCodes) November 19, 2015

Join us next Thursday to #Celebr8D8 — a piñata is in the forecast —

— Amazee Labs Austin (@amazeelabs_atx) November 12, 2015

The Moment We've All Been Waiting For: Drupal 8 is Here! #Celebr8D8!

— Duo (@DuoConsulting) November 19, 2015

#celebr8d8 up up up. @drupalcamppune celebrating drupal 8 launch. Sky lanterns. #drupal

— Prafful Nagwani (@nagwaniz) November 19, 2015

Drupal Nigeria

A little #Drupal8 release party happened last Friday, Eket, Nigeria. #Celebr8D8. Awesome!!

— Aniebiet Udoh (@almaudoh) November 23, 2015

Drupal Bangalore

#celebr8d8 Bangalore Drupal 8 celebrations !

— pvishnuvijayan (@pvishnuvijayan) November 21, 2015

Welcoming the new baby in gang #Celebr8D8 #Drupal8 ##drupal

— AddWebSolution (@AddWebSolution) November 21, 2015

and the party is still on ;) Celebrating @Drupal8ishere :D Are you celebrating? #Celebr8D8 #Drupal8 #Cyprus

— OpiumWorks (@OpiumWorks) November 20, 2015

Looking for the #Celebr8D8 party in Melbourne? It’s near these people!

— cafuego (@cafuego) November 20, 2015

Setting up for the Portland #Celebr8D8 shin dig!

— Holly Ross (@drupalhross) November 20, 2015

Getting ready to party in Portland with @ryanaslett #celebr8d8

— Drupal Association (@DrupalAssoc) November 19, 2015

drupal 8 release party @Blisstering !!!! @DrupalMumbai @celebr8d8 @DrupalAssoc

— Blisstering (@Blisstering) November 19, 2015

Consider this the start of a slow clap for all those #Celebr8D8 cakes. Delicious work, #Drupal, delicious work.

— Amazee Labs Austin (@amazeelabs_atx) November 19, 2015

#Celebr8D8 coming to an end. Thanks @pdjohnson

— Isabell Schulz (@murgeys) November 19, 2015

Nov 25 2015
Nov 25

Load Testing is an important part of quality assurance that takes place prior to launching a site.

When load testing, we simulate user interaction with a website, increase the frequency or the number of interactions and collect the results of system usage, then analyze them to aid system improvement towards desired results. The data will prove useful for creating benchmarks of site performance, which can be compared with earlier site's performance if a site is undergoing a migration. 

Read more about Drupal site migrations.

The Basics

There are three phases of performing load testing.

1. Analysis & Acceptance: Obtain a prediction of potential load and agree on Acceptance Criteria

2. Behavior: Plan and design the test cases and test steps that represent typical usage and prepare the target environment

3. Execute, Modify & Repeat: Execute the test and measure the results. If necessary, implement improvements and repeat.

Analysis and Acceptance

Typically we analyze previous site’s traffic by looking at google analytics during site migrations. We look for traffic patterns and interaction patterns. Looking for highest pageviews days over a period of a year or more gives us an idea of typical peak load. Sometimes the trends are seasonal, as in eCommerce sites, so it’s important to look at a longer period of time.

Interaction patterns give us an idea on how the users use the site; whether they are logging in, which pages are most popular, how many pageviews are typically generated by the user, what actions are performed, etc.. From this data we will create target load numbers and use cases. We agree on the acceptance criteria of site performance. Those may be the number of error-free requests a minute, Apex scores or average response times. Looking at lengthy periods of time in Analytics will help set accurate expectations and test cases??


Build test cases and test steps that will be run by the load test. Sites that provide information typically have scripts that simulate several users consuming information on some of its popular pages. Applications will have scripts which run the user through achieving a goal, such as signing up for an email, creating an account, searching for specific content, etc..


We prefer to use Load Storm for test execution along with New Relic on the server. Load Storm spins up cloud servers which simulate user behavior through browser requests and collects the data on each request while providing a graphical representation of the results.

Using Load Storm in conjunction with New Relic, we are able to see performance patterns. We look for average response times, peak response times, slow responding requests, error rates and try to find a point of failure.

New Relic gives us the ability to tune the site by giving us insights into database performance, which modules or transactions take the most time to complete and which parts of the application have the heaviest usage. This gives us visibility into where the limitations are and where to focus our efforts.

Load Storm is the preferred testing tool of Promet Source?

At the conclusion of load testing the application performs better and everyone has peace of mind that, once the site goes live, it will be a pleasant experience for the users and the technical staff supporting the site.

Video of Load Storm Demo on Drupal Commerce sites:

[embedded content]

Nov 25 2015
Nov 25

Last week, we released Drupal 8.0.0! This amazing milestone signals a new era in Drupal core development, with changes to the changes allowed in patches and a new release cycle with minor versions scheduled every six months.

Now that Drupal 8 is ready for building real sites, with contributed projects already available or being built, the immediate focus for Drupal 8 core will be fixing bugs to help those real sites, as well as fixing any issues in Drupal core that prevent contributed modules from being ported to Drupal 8. Another top priority is stabilizing and completing the core Migrate feature and its user interface, so that existing Drupal 7 and especially Drupal 6 sites can move to Drupal 8 reliably. Finally, a third priority is adding frontend and performance testing to help us make changes more safely. For the next six weeks, we will mainly be committing patches that move us toward these three goals.

Then, after January 6, 2016, we will begin a broader feature development phase for innovations in 8.1.x, 8.2.x, and beyond, so long as we are able to resolve critical issues consistently and keep 8.1.x stable for a reliable scheduled minor release. Read more about the proposed development, beta, and release candidate phases for minor versions.

Drupal 8 core branches and the core issue workflow

Starting today, all patches that are accepted to core according to the priorities above will be committed first to the 8.1.x git branch (even when they are filed against 8.0.x-dev in the core issue queue). Patches that are eligible for patch releases will typically be immediately committed to 8.0.x as well. If we are close to a bugfix release window, the issue may be marked "Patch (to be ported)" and committed just after the bugfix release, to give ample time to catch any regressions or followups before each change is deployed to production sites.

Some patches will only be committed to 8.1.x (for example, if they are too disruptive for a patch release or if they make additions that are only allowed in minor releases). Keep in mind that the open feature development phase for 8.1.x has not started yet, so plan to work on general feature additions and BC-compatible API improvements after it does.

Note that for the time being, patch-release-eligible issues are still filed against 8.0.x-dev in the core issue queue and most 8.1.x issues are still postponed pending the open feature development phase. Later, we will update the core issue metadata and processes as we move into more extensive minor version development.

Nov 24 2015
Nov 24

One of the most exciting aspects of preparing for a DrupalCon is selecting the sessions that will be presented. It’s always incredibly cool and humbling to see all the great ideas that our community comes up with— and they’re all so great that making the official selections is definitely not an easy process! This time, the Track Chairs had almost 350 sessions to read through to determine which 50 would be presented in Mumbai. A lot of hours go into reading each proposal and in the end, they had to make some hard decisions, but are very excited about the programming we will be offering at the Con.

After all was said and done, we are looking forward to presenting 50 sessions by 72 unique speakers. These speakers are comprised of 86% males and 14% females. Coming from all over the world, we are happy to announce that 52% of the speakers will be attending from the South Asia region and will presenting alongside the other 48% of speakers who come from other global Drupal communities.

We look forward to announcing the schedule of sessions by 14 December for you to start planning your days in Mumbai!

See the Selected Sessions

See you in Mumbai!

Nov 24 2015
Nov 24

Photo Drupal has a pretty secure structure: a small, simple and stable core that can be extended with tons of modules and themes. From Drupal 7’s initial release on January 5, 2011 until now, there were only 17 core security updates, which is quite a small number for a period lasting longer than four years.

But when it comes to third-party modules and themes, the picture is quite different. Although only modules with official releases are reviewed by the security team, or have security announcements issued, the majority of the 11,000+ third-party modules and themes for Drupal 7 get weekly reports for security issues.

And using custom modules is even more dangerous if they are not tested properly. Let’s face it: no one uses Drupal without modules. That’s why I will share with you some of the best open source tools to improve the security of your website.

Knowing your opponent’s moves helps you better prepare your defenses. That’s why we will try to attack with every known-at-the-moment method of testing vulnerability. All the tools I will show are easy to use without any knowledge of the source code. And the best part is, you can use this strategy indefinitely, if you keep these tools up-to-date. Remember: update first, then test.

Being Up-to-Date

I can’t emphasize enough how important it is to keep all your stuff up-to-date, so let’s start with that idea: If one tiny part of your website has a security breach, the whole system is corrupted. That’s why you should check for updates for the core and the modules you are using. There are reports you can find on Drupal’s official page; if you find that there is a security update available, immediately apply it.

Metasploit + Armitage = Hail Mary!

Start with Kali Linux: it's small, and has Metasploit and Armitage pre-installed. Armitage gives you a GUI, exploit recommendations, and use of the advanced features of Metasploit Framework's Meterpreter. (But remember to get updates every time you're about to run tests.)

Then, get an exact clone of the server; same machine, database, structure, OS version, etc.

NOTE: It is not recommended you use this technique on live websites because there is a chance the server will go down.

Now you’re ready to put on the white hat and get the party started.

  1. Do a scan. Nmap Scan is integrated into Armitage. However, I recommend using it outside Armitage since you can configure the scan parameters better. There are a lot of different options to choose from. I use the GUI version Zenmap – which also comes preinstalled on Kali Linux – and the following command:
    nmap -sS -p 1-65535 -T4 -A -v
    • sS: Stealth SYN scan
    • p 1-65536: All ports
    • T4: Prohibits the dynamic scan delay from exceeding 10 ms for TCP ports
    • A: Enable OS detection, version detection, script scanning, and traceroute
    • v: Increase verbosity level
  2. After you scan, save the file (scan.xml).
  3. Add host: From the navigation menu “Hosts” -> “Import Hosts” and choose scan.xml.
  4. From the navigation menu, choose “Attacks” -> “Find Attacks”.
  5. From the navigation menu, choose “Attacks” -> “Hail Mary”.

PhotoHail Mary finds exploits relevant to your targets, filters the exploits using known information, and then sorts them into an optimal order.

Important: When you use msfupdate, the database doesn’t get all the possible exploits. When you find some exploit that you want to try on your site, you have to manually add it and execute it. Here’s how:

  1. Download the exploit from exploit-db or write a script on your own.
  2. Put it in the ~/.msf4/modules/exploit/<your_folder> directory. Any exploit put here will be detected by Metasploit when it starts.
  3. Execute it with: use /exploit/your_folder/exploit_name.


Wapiti is a powerful scanner. It supports a variety of attacks and, in the end, provides nice reports in different formats. You can read more about it on the official site. When you open the console and type in wapiti, the wapiti help will load. I use
wapiti <a href=""></a> -n 10 -b folder -u -v 1 -f html -o /tmp/scan_report.

  • n: Define a limit of URLs to read with the same pattern, to prevent endless loops, here, limit must be greater than 0.
  • b: Set the scope of the scan; analyze all the links to the pages which are in the same domain as the URL passed.
  • u: Use color to highlight vulnerable parameters in output.
  • v: Define verbosity level; print each URL.
  • f: Define report type; choose HTML format.
  • o: Define report destination; in our case, it must be a directory because we chose HTML format.

NOTE: It is possible that you’ll encounter “You have an outdated version of python-requests. Please upgrade.” The fix is pip install requests –upgrade.


So, CMSmap is another free open source vulnerability scanner which supports Wordpress, Joomla, and Drupal. It also supports brute force, but Drupal is solid there since it blocks the user after a fifth wrong password attempt.

CMSmap is not preinstalled in Kali, so you’ll have to download it: git clone <a href="">[/geshifilter-code]
To run the tool, type:

cd CMSmap/

I use the following configuration command:
./ -t <a href=""></a> -f D -F -o CMSmap_example_results.txt

  • t: Target URL.
  • f D: Force scan for Drupal.
  • F: Full scan using large plugin lists.
  • o: Save output in file.

That’s all, folks.

But remember: “The quieter you become, the more you are able to hear.”

Image: "Security" by Henri Bergius is licensed under CC BY-SA 2.0

Nov 24 2015
Nov 24

If you are still using the same Nginx configuration that you have been for Drupal 7 on your new Drupal 8 install, most things will continue to work; however, depending on the exact directives and expressions you are using, you might notice a few operational problems here and there that cause some minor difficulties.  The good news is that the Drupal configuration recipe in the Nginx documentation has been updated to work with Drupal 8, so if you have a very basic Nginx setup, you can just grab that and you’ll be good to go.  If your configuration file is a little complicated, and you do not want to just start over, the advice presented below might be helpful when fixing up any defects you may have inadvertently inherited.

Here are three signs that your Nginx configuration needs some fine-tuning to work with Drupal 8.

Can’t Run Update.php

In Drupal 8, the update.php script now displays an instructional dialog with a “Continue” button. Clicking “Continue” will bring the user to the URL update.php/selection, which runs the actual database update operation.

Expected Result:

Clicking the “Continue” button from the update.php script should run the update operation, and then display another dialog for the user.


Clicking the “Continue” button from the update.php script will bring the user to the URL update.php/selection, but the user is presented with a “Page not found” error, and the update operation does not run.


The URL update.php/selection is a little unusual, being a little bit like a clean URL, and a little bit like a mixed php-script with query parameters, except that /selection is used instead of query parameters. Some of the Nginx configuration examples were not written with these patterns in mind, so some location directives will fail to match them.

Nginx Configuration Fix:

Confirm that your location directives are not written to require that the .php extension appear on the end of the URL.

Note: The suggested URL is fairly strict, and only allows the unusual Drupal-8-style paths for the update.php front controller. Being very strict about which paths are matched allows us to continue route paths such as blog/index.php/title through Drupal, for sites that may need to maintain legacy URLs from a previous implementation. If your site does not need to route URLs that contain .php, then you might prefer to use a laxer location rule, such as:

          location ~ \.php(/|$) {

The benefit of using a less restrictive rule is that you will not need to update your Nginx configuration in the future, should a new version of Drupal start using this style of URL with front controlers other than update.php.

Can’t Install Modules from the Admin Interface

Drupal 7 introduced the feature that allows site administrators to install new modules from the Admin interface, simply by supplying the URL to a module download link, or by uploading a module using their web browser. This process relies on a script that determines whether the user has access rights to install modules. Under Drupal 8, this script is located at core/authorize.php; however, a bug in Drupal results in the URL core/authorize.php/core/authorize.php being used instead.

Expected Result:

When working correctly, installing a module through the admin interface will bring up a progress bar that installs the module onto the site.


If Nginx is not configured correctly for Drupal 8, then instead of the progress dialog, the user will see an Ajax error dialog that reports that core/authorize.php/core/authorize.php could not be found.


When the URL core/authorize.php/core/authorize.php  is accessed on an Apache web server, it will find the authorize.php script in the correct relative location once it processes the first part of the path; the second core/authorize.php is then passed into the script as the SCRIPT_PATH, which Drupal ignores. Using some recommended configuration settings will cause Nginx to attempt to process the entirety of core/authorize.php/core/authorize.php as a single route, which it will not be able to find, causing the error.

Nginx Configuration Fix:

Change the regular expression used to partition the SCRIPT_PATH and PATH_INFO to use a non-greedy wildcard match, so that only the portion of the URL up to the first authorize.php will be included in the SCRIPT_PATH.

By default, Nginx uses a greedy match.  +? is the non-greedy variant.

Some Navigation Elements are Missing CSS Styling

Drupal 8 uses Javascript to apply the class is-active to navigation elements on the that correspond to the current page that is being viewed.  This allows themers to apply CSS styles to highlight the active menu items, and so on.

Expected Result:

The styling used will vary based on the theme being used. In Classy, the default theme, if you move the main navigation menu to a side bar, then the menu item link that corresponds to the current page should be colored black instead of blue.


If your Nginx configuration is not correct, then the active menu item link will be styled exactly the same as all of the other menu items.


Drupal includes attributes in the navigation page elements that indicate which pages those elements should be considered to be active. Drupal’s Javascript in turn builds a selection expression based on the current path and query string from the current page URL. A misconfigured Nginx configuration file can cause the query string to be altered in such a way as to prevent the selection expression from matching the page elements that should have the is-active class added.

Nginx Configuration Fix:

This is less likely to be encountered, because the configuration that works with Drupal 8 is the same as the one that is also recommended for Drupal 7. You will only have trouble if you use the older configuration that was recommended for Drupal 6, or some variant thereof. Of course, there is a very large variation in the kinds of configuration files that can be created with Nginx, and not all of these will look exactly like the examples shown above. Hopefully, though, these explanations will go a long way towards explaining how to correct the configuration directives you have, should you encounter any problems similar to these.


I am endebted to Damien Tournoud and Michelle Krejci, who were instrumental in analyzing these configuration issues. I would also like to thank Jingsheng Wang, who first published the update.php fix.

Topics Development, Drupal Planet, Drupal
Nov 24 2015
Nov 24

Cache clearing nirvana may be two vsets away

tl;dr If your D7 site uses features or has many entity types, some recent patches to the features module and the entity api module may deliver dramatic performance increases when you clear Drupal's cache. The magic:

    $ drush vset features_rebuild_on_flush FALSE
    $ drush vset entity_rebuild_on_flush FALSE

The Backstory

Given that tedbow is a good friend in our little slice of paradise, aka Ithaca, NY, we decided that we were going to embrace the entityform module on the large Drupal migration I was hired to lead. Fifty-eight entityforms and 420 fields later (even with diligent field re-use), we now see how, in some cases, a pseudo-field system has real benefits, even if it's not the most future-proof solution. As our cache clears became slower and slower (at times taking nearly 10 minutes for a teammate with an older computer), I began to suspect that entityform and/or our extensive reliance on the Drupal field system might be a culprit. Two other corroborating data points were the length of time that feature reverts took when they involved entityforms. Even deployments became a hassle because we had to carefully time them if they required the cache to be cleared, which would make the site unresponsive for logged-in users and cache-cold pages for 5 minutes or more. Clearly, something needed to be done.


I'm sure there are better ways to handle performance diagnostics (using xDebug, for example), but given the procedural nature of drupal_flush_all_caches it seemed like the devel module would work just fine. I modified the code in Drupal's file to include the following:

function time_elapsed($comment,$force=FALSE) {
  static $time_elapsed_last = null;
  static $time_elapsed_start = null;

  $unit="s"; $scale=1000000; // output in seconds
  $now = microtime(true);
  if ($time_elapsed_last != null) {
    $elapsed = round(($now - $time_elapsed_last)*1000000)/$scale;
    $total_time = round(($now - $time_elapsed_start)*1000000)/$scale;
    $msg = "$comment: Time elapsed: $elapsed $unit,";
    $msg .= " total time: $total_time $unit";
  else {
  $time_elapsed_last = $now;
 * Flushes all cached data on the site.
 * Empties cache tables, rebuilds the menu cache and theme registries, and
 * invokes a hook so that other modules' cache data can be cleared as well.
function drupal_flush_all_caches(){
  // Change query-strings on css/js files to enforce reload for all users.

  // Rebuild the theme data. Note that the module data is rebuilt above, as
  // part of registry_rebuild().
  // node_menu() defines menu items based on node types so it needs to come
  // after node types are rebuilt.

  // Synchronize to catch any actions that were added or removed.

  // Don't clear cache_form - in-progress form submissions may break.
  // Ordered so clearing the page cache will always be the last action.
  $core = array('cache', 'cache_path', 'cache_filter', 'cache_bootstrap', 'cache_page');
  $cache_tables = array_merge(module_invoke_all('flush_caches'), $core);
  foreach ($cache_tables as $table) {
    time_elapsed("clearing $table");
    cache_clear_all('*', $table, TRUE);

  // Rebuild the bootstrap module list. We do this here so that developers
  // can get new hook_boot() implementations registered without having to
  // write a hook_update_N() function.

The next time I cleared cache (using admin_menu, since I wanted the dpm messages available), I saw the following:

registry_rebuild: Time elapsed: 0.003464 s, total time: 0.003464 s

drupal_clear_css_cache: Time elapsed: 3.556191 s, total time: 3.559655 s

drupal_clear_js_cache: Time elapsed: 0.001589 s, total time: 3.561244 s

system_rebuild_theme_data: Time elapsed: 0.003462 s, total time: 3.564706 s

drupal_theme_rebuild: Time elapsed: 0.122944 s, total time: 3.68765 s

entity_info_cache_clear: Time elapsed: 0.001606 s, total time: 3.689256 s

node_types_rebuild: Time elapsed: 0.003054 s, total time: 3.69231 s

menu_rebuild: Time elapsed: 0.052984 s, total time: 3.745294 s

actions_synchronize: Time elapsed: 3.334542 s, total time: 7.079836 s

clearing cache_block: Time elapsed: 31.149723 s, total time: 38.229559 s

clearing cache_ctools_css: Time elapsed: 0.00618 s, total time: 38.235739 s

clearing cache_feeds_http: Time elapsed: 0.003292 s, total time: 38.239031 s

clearing cache_field: Time elapsed: 0.006714 s, total time: 38.245745 s

clearing cache_image: Time elapsed: 0.013317 s, total time: 38.259062 s

clearing cache_libraries: Time elapsed: 0.007708 s, total time: 38.26677 s

clearing cache_token: Time elapsed: 0.007837 s, total time: 38.274607 s

clearing cache_views: Time elapsed: 0.006798 s, total time: 38.281405 s

clearing cache_views_data: Time elapsed: 0.008569 s, total time: 38.289974 s

clearing cache: Time elapsed: 0.006926 s, total time: 38.2969 s

clearing cache_path: Time elapsed: 0.009662 s, total time: 38.306562 s

clearing cache_filter: Time elapsed: 0.007552 s, total time: 38.314114 s

clearing cache_bootstrap: Time elapsed: 0.005526 s, total time: 38.31964 s

clearing cache_page: Time elapsed: 0.009511 s, total time: 38.329151 s

hook_flush_caches: total time: 38.348554 s

Every cache cleared.

My initial response was to wonder how and why the cache_block would take so long. Then, however, I noticed line 59 above, which calls module_invoke_all('flush_caches'), which should have been obvious. Also, given that I was just looking for bottlenecks, I modified both module_invoke($module, $hook) in, as well as the time_elapsed to get the following:

function time_elapsed($comment,$force=FALSE) {
  static $time_elapsed_last = null;
  static $time_elapsed_start = null;
  static $last_action = null; // Stores the last action for the elapsed time message

  $unit="s"; $scale=1000000; // output in seconds
  $now = microtime(true);

  if ($time_elapsed_last != null) {
    $elapsed = round(($now - $time_elapsed_last)*1000000)/$scale;
    if ($elapsed > 1 || $force) {
      $total_time = round(($now - $time_elapsed_start)*1000000)/$scale;
      $msg = ($force)
        ? "$comment: "
        : "$last_action: Time elapsed: $elapsed $unit,";
      $msg .= " total time: $total_time $unit";
  } else {
  $time_elapsed_last = $now;
  $last_action = $comment;

/** From */
function module_invoke_all($hook) {
  $args = func_get_args();
  // Remove $hook from the arguments.
  $return = array();
  foreach (module_implements($hook) as $module) {
    $function = $module . '_' . $hook;
    if (function_exists($function)) {
      if ($hook == 'flush_caches') {
      $result = call_user_func_array($function, $args);
      if (isset($result) && is_array($result)) {
        $return = array_merge_recursive($return, $result);
      elseif (isset($result)) {
        $return[] = $result;

  return $return;

The results pointed to the expected culprits:

registry_rebuild: Time elapsed: 4.176781 s, total time: 4.182339 s

menu_rebuild: Time elapsed: 3.367128 s, total time: 7.691533 s

entity_flush_caches: Time elapsed: 22.899951 s, total time: 31.068898 s

features_flush_caches: Time elapsed: 7.656231 s, total time: 39.112933 s

hook_flush_caches: total time: 39.248036 s

Every cache cleared.

After a little digging into the features issue queue, I was delighted to find out that patches had already been committed to both modules (though entity api does not have it in the release yet, so you have to use the dev branch). Two module updates and two vsets later, I got the following results:

registry_rebuild: Time elapsed: 3.645328 s, total time: 3.649398 s

menu_rebuild: Time elapsed: 3.543039 s, total time: 7.378718 s

hook_flush_caches: total time: 8.266036 s

Every cache cleared.

Cache clearing nirvana reached!

Nov 24 2015
Nov 24

In Drupal 8, many functionality has been replaced by Plugins. The replacement for "hook_menu()" is the plugin Derivative (/d??r?v.?.t?v/) in combination with a "".

If you had static items in your hook_menu(), you can define them in the, if you had generated menu items, let's say from content, a Derivative Plugin is the new way to go.

You can define your own Derivative Plugin by creating the following folder in your module:

In that folder you can create the file:

In your PHP file you should create a class that extends DeriverBase and implements the ContainerDeriverInterface. The following example adds all nodes of type "page" to the main menu.

class MyModuleMenuLinkDerivative extends DeriverBase implements ContainerDeriverInterface {

   * {@inheritdoc}
  public static function create(ContainerInterface $container, $base_plugin_id) {
    return new static();

   * {@inheritdoc}
  public function getDerivativeDefinitions($base_plugin_definition) {
    $links = array();

    // Get all nodes of type page.
    $nodeQuery = \Drupal::entityQuery('node');
    $nodeQuery->condition('type', 'page');
    $nodeQuery->condition('status', TRUE);
    $ids = $nodeQuery->execute();
    $ids = array_values($ids);

    $nodes = Node::loadMultiple($ids);

    foreach($nodes as $node) {
      $links['mymodule_menulink_' . $node->id()] = [
          'title' => $node->get('title')->getString(),
          'menu_name' => 'main',
          'route_name' => 'entity.node.canonical',
          'route_parameters' => [
            'node' => $node->id(),
        ] + $base_plugin_definition;

    return $links;

Your "" in the root of your module should look like this:

  deriver: \Drupal\mymodule\Plugin\Derivative\MyModuleMenuLinkDerivative

If you want advanced stuff like configurable menuitems and tweaking the menu link cache tags/contexts, create the following folder in your module:

In that folder you can create the file MyModuleMenuLink.php.

class MyModuleMenuLink extends MenuLinkDefault implements ContainerFactoryPluginInterface {
  // Class overrides here.

In the root of your module change the content of "" to:

  deriver: \Drupal\mymodule\Plugin\Derivative\MyModuleMenuLinkDerivative
  class: \Drupal\mymodule\Plugin\Menu\MyModuleMenuLink

Here is the complete code of the basic example:

Here is the code of the advanced example with your own Menu Link Class:

Nov 24 2015
Nov 24

Last November, launched on Drupal and became one of the highest trafficked websites in the world to launch on an open-source content management system (CMS). Today, we're proud to announce that we have been recognized with a 2015 Partner Site of the Year Award from Acquia for our work on The award recognizes outstanding visual design, functionality, integration and overall customer experience for a media website. 

 This year’s winners exemplify what can be done with great technology, beautiful design, and a customer-first mindset...Ultimately, it came down to a hair-splitting exercise to determine which sites serve their audience’s needs in the most effective, seamless way possible.

-Scott Liewehr, CEO and Co-Founder of Digital Clarity Group

The Weather Channel's Journey to Drupal

The Weather Channel (TWC) teamed up with Mediacurrent in 2012 to begin the process of a full migration from their previous content management system to Drupal. 

By taking the time to understand the requirements and the impact of every decision, Mediacurrent planned a resilient architecture, allowing both parties to quickly respond to changing business needs without major disruptions. Our goals were to help TWC adopt an open-source solution and ensure that the new website also had drastically improved page load times and reduced infrastructure requirements. 

Mediacurrent's team rose to the challenge, creating 30 completely custom modules, 120+ custom features and custom code on the final web platform. In a recent blog series, Senior Drupal Developer Matt Davis detailed Mediacurrent's approach to architecting a custom "presentation framework" for TWC and shared how we increased content portability, improved page load times, and created flexible widgets across multiple devices. 

The Results now serves millions of pages to more than 100 million people each month. Weather’s move to Drupal shows how complex, content-rich sites benefit from an open, agile platform to deliver an amazing experience for every site visitor.

-Dries Buytaert, Acquia CTO and Drupal project creator

  • Increased feature velocity and scalability to support 100M unique visitors monthly
  • Streamlined editorial process by 175%
  • Improved cache efficiency from 50% pre-launch to 96.3% post-launch, with an increase to 99.6%  3 weeks post-launch

For a complete case study, you can read more about Mediacurrent's work on here or at  

Q&A With | Video
Migrating the Weather Channel to Drupal | Webinar A Novel Presentation Framework | Drupalcon 2015 Presentation Recording

Nov 24 2015
Nov 24

Much of the conversation in the Drupal 8 development cycle has focused on “NIH vs. PIE.” In Drupal 8 we have replaced a fear of anything “Not-Invented-Here” with an embrace of tools that were “Proudly-Invented Elsewhere.” In practice, this switch means removing “drupalisms,” sections of code created for Drupal that are understood only by (some) Drupal developers. In their place, we have added external libraries or conventions used by a much wider group of people. Drupal has become much clearer, much more explicit about its intentions by making this kind of change all over the codebase.

Replacing drupal_http_request with Guzzle

For instance we have gotten rid of our own “drupal_http_request()” and replaced it with the invented-elsewhere Guzzle library. Guzzle is a stand-alone tool written in PHP for making HTTP requests. Here is the change record that describes how code written in Drupal 7 would be modified to use the new library in Drupal 8. Ultimately it was Guzzle’s superior feature set that made it replace drupal_http_request. Guzzle can do a lot more than drupal_http_request and it does so in a much clearer fashion.

From the change record we see an example of Guzzle:

$client = \Drupal::httpClient();

$request = $client->createRequest('GET', $feed->url);

$request->addHeader('If-Modified-Since', gmdate(DATE_RFC1123, $last_fetched));


Compared to an example from Drupal 7:

$headers = array('If-Modified-Since' => gmdate(DATE_RFC1123, $last_fetched));

$result = drupal_http_request($feed->url, array('headers' => $headers));


The intentions of the code from Guzzle are much more explicit. The method “addHeader” is being called. Any developer could read that line and see what is happening. In the case of the Drupal 7 code the reader would be guessing. And sure, it might be easy enough to guess what drupal_http_request will do when it is passed multidimensional arrays. But it takes a lot of mental overhead for developers to think through the implication of each key within a multidimensional array.

It is not a coincidence that Guzzle, a library shared among many PHP projects, requires developers to be very clear about their intentions. Replacing drupal_http_request with Guzzle made Drupal’s code more explicit and comprehensible. There are numerous other examples where adopting or pursuing a concept from outside Drupal made Drupal itself clearer.

Classed Objects

Perhaps the clearest example of this shift is the switch to classed objects. Prior to Drupal 8, much of Drupal Core still showed its roots in PHP4 when support for object-oriented concepts was immature. Now instead of Drupal entities being represented simply as a “stdClass”, each entity type has its own class with defined properties and methods. Writing actual classes, methods, and interfaces encourages the Drupal community to think harder about what each entity is meant to do.

Drupal has a history of taking our “node” concept and bending it mercilessly to replace less developed parts of core. Anyone else remember usernode, which made a node for every user? When users and nodes were both shoehorned onto the same type of generic class it was easier to justify using one to make up for the shortcomings of the other and muddle our definitions by doing so. Actual classes force us to think more clearly.


Along with the usage of classed-objects has come the adoption of interfaces. One of the problems interfaces have helped solved is the pain of registering new functionality like field widgets. In Drupal 7 and prior, adding a new field formatter meant writing a set of hooks—some of which were absolutely required and others varied by use case. Writing hook_field_formatter_info implies writing hook_field_formatter_prepare_view, but it doesn’t require it. In Drupal 8 the we have Drupal\Core\Field\FormatterInterface to tell us exactly what is needed by a formatter and module writers can extend Drupal\Core\Field\FormatterBase to avoid rewriting boilerplate.

Interfaces also enable Drupal 8 to put services in a Dependency Injection Container. Again, Drupal is replacing NIH with PIE. Previous versions of Drupal assumed that any portion of code could access the global state at any time for any reason. This assumption implies that isolating a section of code so that it can be replaced is very difficult or impossible. In Drupal 8 many corners of Drupal, like breadcrumb handling, have be rewritten into a “service” which is carried in a “container”. The service should declare exactly what it depends and exactly what it will do (through an interface). This enables developers to replace one service with another version. Here is a detailed breakdown from Larry Garfield on how to do so with breadcrumbs. Again, for Drupal to use an outside concept, it’s own code must be more explicit.


Chasing an invented-elsewhere caching strategy has made Drupal’s internal caching system much clearer. Inspired by Facebook’s Big Pipe caching strategy, Drupal developers led by Fabian Franz and Wim Leers have made huge improvements to Drupal 8 caching. And of course they have made the caching system more explicit in doing so. The idea of Big Pipe is simple: make a page load fast by sending only a skeleton of markup and then filling in all of the separately-cached blocks of content. For that strategy to work, each block must be very explicit about how long it can be cached and which changes to context or content would invalidate it. Now, when rendering something, a developer is expected to explicitly state:

  1. The cache tags. These are data points like node ids. The idea is that if a node is resaved, every cache that declared the node’s id as a cache tag can be invalidated.

  2. The cache contexts. Some render elements vary based on more global concepts like the language of the current request/user or the role of the current user. This addition makes it much easier to do something like showing a full article to subscribers and a truncated article to anonymous users.

  3. The max-age of the cache. Some elements have to be regenerated every 10 minutes. Some can stay cached as long as their tags and contexts remain unchanged. Before Drupal 8, cache ages were much more of a guesswork operation.

For more information, watch this talk from Drupalcon Barcelona from Wim Leers and Fabian Franz.

Configuration Management

Drupal 8’s configuration management strategy is perhaps the most touted new feature and it brings plenty of PIE. The Configuration Management Initiative helped pave the way for standardized, exportable configuration; a concept developers from other systems expect as a matter of course. The discussions within the Configuration Management Initiative considered a number of different export formats like JSON and XML. YAML was ultimately chosen and that format is now used throughout Drupal for different purposes like the definition of services, libraries, CSS breakpoints and more. Even the drupalism of .info files in modules and themes has be replaced with this widely understood, invented-elsewhere format.

Additionally, core has taken concepts from CTools module for how configuration moves from the file system to the database to a cache. Now in Drupal 8, configuration can be exported to the file system (in .yml files) to be committed to git and moved across environments. The .yml files can then be imported into a database in a consistent fashion where they are stored and cached.

The main improvement over Drupal 7 is the consistency across Drupal subsystems. In Drupal 7, a developer had to remember that “overridden” meant one thing when Features module used that word in relation to Field configuration and “overridden” meant a slightly different thing when Views UI used it in relation to an exported View. By treating configuration in a consistent manner across subsystems the whole architecture becomes more cohesive.

Increased explicitness often was not the main goal of the above changes. The developers leading those changes often just wanted a better system that was easier to work with. In doing so, we’ve made a version of Drupal that should be clearer and more understandable to developers new to Drupal. We do not have to explain the difference between Filter module storage and Panels. We can just say “our configurations are all stored in the same way”. Drupal becomes more approachable and will travel further because of it.

Topics Drupal Planet, Drupal
Nov 24 2015
Nov 24

By Valentin Garcia 23 November 2015

Put your Drupal Site in Maintenance Mode Manually

Drupal allows to set a website offline with a few clicks via the admin interfacte.

However, we've seen situatuons where the admin interface becomes unavailable, often via a white screen of death.

In this tutorial, I'm going to show you a manual way to force your Drupal 7 site in maintenance mode.

Step #1. Edit the settings.php file

  • Edit the file sites/default/settings.php file, using a FTP client or through cPanel:
Put your Drupal Site in Maintenance Mode Manually
  • At the very end of settings.php, add the code below:
$conf['maintenance_mode'] = 1;

Step #2. End result

Your site will now display the "Site under maintenance" page:

Put your Drupal Site in Maintenance Mode Manually

Step #3. Put your site back online

Remove the line of code from Step 1, or change the value to 0 to put your site online again:

$conf['maintenance_mode'] = 0;

About the author

Valentín creates beautiful designs from amongst the tequila plants of Jalisco, Mexico. You can see Valentín's design work all over this site and you can often find him helping members in our support forum.

Nov 24 2015
Nov 24

The issue at hand

As most Drupal 6 site owners are aware, after a prolonged development period, Drupal 8 was officially released (8.0.0) last week on November 19th, 2015 Dries’s birthday with a corresponding many, many a lively party: Drupal 8 celebration #celebr8d8Like this fancy one in downtown Durham atop the rooftop bar of The Durham Hotel.

Drupal 8.0.0 is a BIG DEAL and generally speaking is great for the community of Drupal site owners and site builders.

However (there’s always a but), with the official release of Drupal 8, support for Drupal 6 will end on February 24th, 2016. Given the U.S. holiday season has begun, there is little productive time remaining to undertake a site upgrade before Drupal 6 End Of Life (EOL). If you are a site owner fortunate enough to have survived a Drupal site upgrade in the past, you are well aware that the upgrade process can be time-intensive for complex sites. It is never as easy as the click of a button. For most Drupal 6 site owners, it is the fact that their sites are so complex that they have avoided going through the upgrade process for as long as possible.

This presents responsible yet practical site owners who don’t have unlimited budgets with difficult decisions, each with associated pros and cons to weigh. In part 1 of this series, we’ll help walk you through the following topics at a high-level, with a follow-up post examining each topic in finer detail.

  • What does Drupal 6 EOL mean for me?
  • What are the risks to not upgrading?
  • What are my options?
  • Should we upgrade to Drupal 7 or Drupal 8?
  • How do we decide what to do?

N.B.: if you don’t fit into the aforementioned category of having budgetary constraints, please contact us immediately. ;)

What does Drupal 6 EOL mean for me?

Like any good (and probably the bad too) Drupal advisor will tell you, it all depends. Helpful, right? But truly, it’s necessary to understand the organization and its technical requirements very well to assess the risk of operating a Drupal 6 site after EOL. As an agency that leverages open source technology to build modern web applications, on a daily basis Savas relies on the Newtonian

…shoulders of giants…

to perform sophisticated tasks with the click of a button (or more likely a command in the terminal). That Drupal community that we access and contribute to for features is the same one that provides security maintenance. After EOL for Drupal 6, that click of a button access goes away both for features, but more importantly for security fixes. In other words, it means (almost) no one is watching Drupal 6 after February 24th 2015. For sustainability purposes, that huge community (~100,000 active contributors) must use its time and energy to support the newer platforms.

State of Drupal 6 sites in production

Drupal 6 has been around for a long time. As of mid November 2015 there are at least ~125,000 reported instances (likely underrepresented) of Drupal 6 sites in the wild. So you are not alone (…I am here with you…) and there is some comfort in that. If you’re reading this and have not begun your upgrade process yet, it is very likely you will be spending at least some time outside of support for your Drupal 6 site. We will dive into this at a deeper level in part 2, but some of the factors that are worth taking into consideration as you strategize the upgrade are:

Considerations to assess risk
  • How well-known is your organization?
    • Larger organizations with high public profiles are systematically targeted more frequently than smaller, lesser-known organizations.
  • How many contributed modules does your site utilize and how well supported are those modules?
    • Attack vectors that remain for Drupal 6 are likely to be modules that have not received a lot of historical support, but are in some way identifiable to the public when they are in use on a site.
  • How much does your site rely on custom code?
    • Custom code has the advantage of not being publicly known, but the large disadvantage of only being vetted by one site.

What are the risks?

High-level risks, more closely examined in part 2 are as follows from most severe to least.

  • Complete site compromise and control with consequences dictated by the whim of a hacker.
  • Site incompatibility with mandatory server security upgrades that fall out of sync with Drupal 6 (PHP 7 comes out in late 2015).
  • You do not keep up with modern web development practices. After all, Drupal 6 came out January 1st, 1970 (I just checked) and given that makes it older than 6 months on the web, it’s ancient.
  • You expose yourself to a decreasing market of developers that are able to serve you. With each major release, especially two in row (7 and 8) with significant architectural modifications to the former, skills honed in development for the current version of the software, provide diminishing returns the further back in versions you go.

What are my options?

In considering a Drupal 6 upgrade you have a few simple options.

  • Do nothing, and keep your fingers crossed.
  • Upgrade Drupal 6 core to a supported version (probably Drupal 7) and match existing functionality.
  • Engage a robust redesign/rebuild (Drupal 7 or 8).
    • Simultaneously harden the site to best mitigate attack vulnerabilities as the rebuild may take 6-18 months to complete.
  • Select a different solution than Drupal, and migrate to that.

Drupal 7 or Drupal 8… heck, what about Drupal 9?

This is another one that, I know…shocker, depends. The factors that effect this choice which we’ll discuss more in part 2 are:

  • Organizational tolerance for risk: Drupal 8 is less tested, and is inherently riskier earlier on in the life cycle of your site.
  • Willingness to support community: In some cases Drupal 8 contributed modules will need extra polish to be up to production snuff.
  • Complexity of site: Drupal 8 core has many more bells and whistles, but the contributed module landscape has a long way to catch up to Drupal 7.
  • What is the future/life of the site: Drupal 8 is much more forward-thinking in its approach, whereas though vetted, Drupal 7 is over 4 years old.
  • Existing developer’s skill set: Drupal 8 architecture, coding style (object oriented) and PFE (proudly found elsewhere) approach that leverages strengths from the rest of the PHP community all mark substantial shifts from Drupal 7. Therefore the skills required to succeed in these two realms differ.
  • Get out of here with that Drupal 9 talk! It’s neither prime nor even!

What is our recommendation?

If you feel lost in these concepts or with answering some of these questions on your own, it’s best that you speak with professionals who have years of experience maintaining and upgrading Drupal sites. The upgrade process is a highly variable one, and is not especially easy to estimate as it is much more nuanced than typical feature development.

Reaching EOL for your existing Drupal site is a time that we encourage site owners to look at the process like moving into a new and better home. It’s best to take the time to envision and create what you want in the new space, rather than thoughtlessly replicate what you had in the old. Why make a carbon copy when you had good reasons to make the move after all (even if you were technologically strong-armed by volunteers)? It’s very common to have features and custom development that have outlived their usefulness to your organization’s mission; so it’s a good time to purge. Out with the old, in with the new!

Having said that, the desire to preserve content from the existing site is very common and often necessary. There are advanced migration techniques available from Drupal 6 to Drupal 7 or Drupal 8 that may be entirely separated from the rest of the rebuild, so porting content and matching site functionality can be completely decoupled.

We love talking through this process with site owners. We analyze what makes the most sense for your organization while addressing priorities for both short and long term goals. We have been building sites in Drupal 8 since May 2015 and sites in Drupal 7 since 2010 so we are well versed to the pros and cons of each. Reach out to further discuss and stay tuned for parts 2, and 3.

About the author

Chris Russo

Recent posts by Savas

Slides from Tim’s talk on building web maps using Drupal at the 2015 NACIS conference.

Attending and sharing experiences from the All Things Open conference.

Using composer manager to manage a custom module’s dependencies.

Nov 23 2015
Nov 23

We couldn't be more excited to bring DrupalCon to India: it's a unique and colorful nation with many amazing cultures. Though the Con itself will be held in Mumbai, we strongly recommend that anyone traveling to India for DrupalCon take the time to tour some of the many fascinating regions of India.

How much does India have to offer? Our friends at Niswey illustrated the Druplicon on a tour of the country, experiencing four unique cultures that India has to offer. Here's the comic, and you can see more information on each frame below.

Druplicon Experiencing Indian Culture

Drupal Anna: Mind It! This frame represents the Druplicon in southern India, and he's wearing a lungi below his shirt. In the backdrop, there are coconut trees and a beach, which can be seen only in the southern states. Anna is a word people in the southern states (Kerala, Tamil Nadu, Andhra Pradesh, and so on) use to call out an elder brother or just to address a random person. The phrase "Mind it" is an expression made popular by the famous movie star Shah Rukh Khan, when he played a cameo of a south Indian star. "Mind It!" means: "You better get that, because I'm the boss." This is the attitude with which South Indian stars are often depicted in the movies.

(Want to know more about the southern states? You can watch the Lungi Dance, a fun song made as a tribute to Rajnikanth, one of the most famous southern movie stars and a cultural icon. You'll learn some cool dance moves, too!)

Drupal Paaji: Chak De Phatte! This frame represents the culture of Northern India, mainly Punjab and Delhi. He is doing Bhangra, a dance form most popular in the states of Northern India. Paaji is another word for a brother in Delhi and Punjab. In the backdrop, there are mustard fields, a common sight in the northern states. Chak de Phatte is an expression used in excitement or at celebrations in the region. 

Drupal Dada: Khoob Bhaalo! Drupal Dada (another word for brother) is shown as a person from Eastern India. He wearing kurta and dhoti, traditional attire of people from East Indian states. In the background, there is a yellow cab and a tram, common public transports, and the white building is Victoria Memorial, a landmark in Kolkata, the most populous city in Eastern India. Khoob Bhaalo (in Bengali, a regional language) means "very good" and is famous among people across India. 

Drupal Bhai: Jhakaas! Drupal Bhai represents Mumbai, the city where DrupalCon Asia will be held, and the most popular city in Western India. The Mumbai Drupal Bhai (or brother) is dressed like a flamboyant movie fan, because Mumbai is also the city of Bollywood, one of the biggest movie industries of the world. In the background, you'll find Gateway of India, a landmark in Mumbai. The word Jhakaas is an expression for anything that is fantastic. It is made popular by a movie star Anil Kapoor, the actor who played the game show host in Slumdog Millionaire. 

Hopefully, you've explored India a bit through the Druplicon's journey. Regardless of whether you go on a tour of your own, we hope to see you in Mumbai this February!

The Drupal Association has partnered with Niswey, an India-based marketing firm, to provide marketing materials for DrupalCon Asia. Every few weeks, we'll be sharing the blogs and comic strips that our Niswey friends have created in anticipation of the convention.

Nov 23 2015
Nov 23

This tutorial is part of the "Build a Blog in Drupal 8" series:

  1. Content types and Fields
  2. Adding Comments
  3. Using Views
  4. Managing Blocks
  5. Create and Manage Menus

A website's navigation plays an important part in how easy a site is to use. It's essential that you spend time fleshing out the overall IA (Information architecture) or you'll end up with a site that's hard to use and difficult to navigate through.

Previous versions of Drupal have always offered a simple interface for managing menus, and Drupal 8 is no exception.

In this tutorial, we'll continue building our site by adding in some menus. We'll create a custom menu which'll be used to display links to popular categories, then create an "About us" page and add a menu link to the footer.

This tutorial is part of the "Build a Blog in Drupal 8". Make sure you've read the previous tutorials if you want to follow along.

How to Manage Menus

When you install Drupal 8 using the Standard Installation profile, a menu called "Main navigation" is used as the primary site navigation with the single link called Home. Another, called Footer, is used in the footer region with the single link pointing to the contact form.

Fig 1.0

Create Menu

Let's now create a custom menu which'll display a list of curated popular categories. On a blog, these links will help you promote categories and send traffic to those pages.

1. Go to Structure, Menus and click on "Add menu".

2. Enter "Popular categories" into the Title field and "Curated list of categories." into "Administrative summary". Then click on Save.

Fig 1.1

Once it's been created, you'll be redirected to the menu edit page. You'll be able to manage all menu links from here.

Create Menu Link

1. Now click on "Add link".

2. Enter "Drupal content" into "Menu link title", enter in the taxonomy term URL to your Drupal category. On my site it's "/taxonomy/term/1" so I'll enter that in. Then in Description, enter in "Latest Drupal content."

Fig 1.2

The Link field is something which is new in Drupal 8 and it allows you to link directly to internal content pages by typing in the title of the content.

However, the autocomplete will only work for node content. You can't search for a taxonomy term. You can add one manually by adding the internal URI e.g, /taxonomy/term/1. You can also link to external pages or domains just by entering in the absolute URL.

Fig 1.3

Place Menu into Region

Now let's go and add our new menu into the footer.

1. Go to Structure, "Block layout" and click on "Place block" in the "Footer first" region. Search for "Popular categories" and click on "Place block".

Fig 1.4

2. Leave the "Configure block" modal pop-up as is and click on "Save block".

3. Don't forget to click on "Save blocks" at the bottom of the page.

4. Go to the homepage and in the footer region you should see the menu.

Fig 1.5

The menu links can be managed by hovering over it and clicking on "Edit menu".

Fig 1.6

Create About Us Page

Now we need to create an "About us" page and place a menu link in the main navigation so it's easily accessible. We'll add the menu link directly from the content edit form.

1. Go to Content, "Add content" and click on "Basic page".

2. In the Title field add "About us" and some text into the Body field.

Fig 1.7

3. In the right sidebar, click on the "Menu settings" vertical tab then check the "Provide a menu link" checkbox.

Fig 1.8

From this settings, you can set the menu link title; this is automatically pulled from the Title field. If you want text to appear when you hover over the link, then add it to the Description field.

The "Parent item" drop-down lets you select a parent menu link or a menu group. By default you can only add menus to the "Main navigation" but other menus can be accessible from this drop-down if configured.

Finally, the Weight field lets you control the order in which the links will be displayed. But I recommend you reorder the links from the menu page because it's much easier.

Once you've defined the menu link, scroll to the bottom and click on "Save and publish".

4. Now in the header you should see the "About us" before the Home link.

Fig 1.9

Reordering Menu Links

In the image above, "About us" appears before the Home link which is not ideal. Let's reorder the links so it's Home first then "About us".

To reorder the links you must go to the menu edit page and this can be done in two ways. First, you can edit the menu by going to Structure, Menus and by clicking on "Edit menu" in the "Main navigation" row. Another way, is to hover over the menu and click the edit icon then "Edit menu".

Fig 1.10

Once you're on the edit menu page, simply drag the Home menu to the top and then click on Save.

Fig 1.11

Now Home should be the first link in the menu.


From a site building standpoint, the UI for managing menus has stayed relatively the same. If you know how to manage menus in Drupal 7 then you should be fine in Drupal 8.

But from an architectural standpoint, the routing system in Drupal 8 has been rebuilt using Symfony components. If you want to learn more about the technical changes check out this great post, "What Happened to Hook_Menu in Drupal 8?".

Like what you see?

Join our free email list and receive the following:

  1. Discover our best tutorials in a 6 part series
  2. Be notified when free content is published
  3. Receive our monthly newsletter
Nov 23 2015
Nov 23

One of the great things about Drupal is its flexible system of nodes and taxonomies. This allows for bespoke categorization of many types of content.

At, we wanted to take advantage of that., which has an alliance with Acquia to bring joint tech solutions to the worlds biggest media companies, works with hundreds of digital publishers to provide audience insights through an intuitive analytics platform.

By using’s dashboards and APIs, publishers at any stage of the digital process can build online strategies that allow them to grow and engage a loyal audience.

Beyond precise measurement of views, visitors, shares, and time, includes breakouts of on-page attention, mobile devices, and visitor retention. Publishers can use this data to identify high-quality long-form content, engaging images and videos, new traffic sources for distribution, and audience interest segments that lead to loyalty.

Yet Drupal’s flexibility, while allowing for highly complex websites, has made it a challenge to take full advantage of’s capabilities, primarily because only experienced Web developers with HTML, CSS, and JavaScript chops could integrate the tools. Thus, integrating with a Drupal site heretofore meant each individual site had to make use of a dedicated Drupal developer to roll a custom solution.

The proposed solution: To alleviate this burden, we decided that a dedicated Drupal module which handled this integration for all sites wanting to use made a lot more sense. This would help publishers integrate with the platform to create fully custom sites benefitting from the full power of’s data-mining tools, without requiring them to have someone with in-depth programming skills to map the nodes and taxonomies onto’s back-end.

How it would work: The Drupal plugin would automatically insert the required page tag and JavaScript on all of the published pages and posts -- making it easier than ever to figure out what content is driving visitors to a site, and why.

Benefits of integrating + Drupal

The new for Drupal module is a great example of how well a proprietary platform can integrate with Drupal. For this, was fortunate to work with Forest Mars, founder at The Mars Group, to complete the first version of the Publishing Analytics project.

Mars said of the project: “ is a good match for Drupal because Drupal is a dynamic publishing platform with the ability to create and manage complex content relationships; this gives a high level of control over what content is reported and numerous integration points for control over how these analytics get reported.”

Some interesting aspects of the integration

The integration takes advantage of Drupal’s powerful framework and community of contributors.

Drupal is an ecosystem comprised of thousands of modules, built by thousands of developers. These modules offer site owners the unique ability to add new features and additional behaviors to existing code without having to modify the code itself.

To put it simply, developers can use combinations of modules, aka “recipies,” as building blocks to create additional functionality in Drupal. The initial module for enables sites to track certain content and reader actions, and, thanks to Drupal’s underlying architecture (or “Aspect Oriented Programming” in technical speak) other developers have the ability to take these integrations even deeper.

Anticipating interest from other developers in integrating the module with their own projects, the initial release includes a stub for future token integration in the build. Token, which is the 3rd most widely used of all contributed Drupal modules, provides small placeholders that  can be used in the Web interface to represent a data connection that would otherwise require writing a lengthy bit of code.

The module roadmap also includes possible integration with Metatag module which can provide the logic of when and where to output tags using tokens. The Metatag module also enables configuration inheritance.

Ultimately, the module will allow any data on a publishing website anywhere to be integrated in a way that is more customizable than traditional tools like Google Analytics.

Development made possible on Github

Rather than limit development to, the module is on Github, which is is automatically (some would say magically) synched to using the Hubdrop platform. In this way, any developer can fork the code from the repository on Github, and contribute changes with a pull request. Hubdrop then automagically pushes those changes to the module on This means that developers who are not familiar with the idiosyncracies of can easily contribute to using a more standard git process on the widely used Github platform.  

The integration is highly configurable.

The Drupal plugin is highly configurable and takes advantage of Drupal’s rich architecture. For tech newbies who who need to quickly and easily install the plugin and start tracking data on their website, it is essentially plug-and-play. However, for advanced power users, the plugin serves as a forward-looking toolset for any publishing website -- with lots of options for customization. As a matter of fact, in this first release, the configuration page has at least a dozen options -- all organized in drop-down menus so they are not so intimidating.

Using the Drupal module’s easy integration with Drupal modules is a testament to’s simplicity, and Drupal’s plug-and-play ecology. The module serves as a roadmap for deep integration with any data on any website. Data on your website that you need to view from a business perspective, you can view from the dashboard.

The plugin integrates analytics and metadata on your site in just a few clicks. Here’s how to integrate Drupal and

  1. Download and install the Drupal module from

  2. Enable the module in the “Modules” page of Drupal under the “Statistics” subheading, and hit save.

  3. Go to the settings page at: Configuration > Search And Metadata >

  4. Enter the Site ID (You can find your Site ID on your your settings page) and configure the plugin according to how your Drupal site uses nodes and/or taxonomies (the plugin requires you to choose one or the other to work).

  5. Click “Save” and your integration is ready to go!

A small piece of JavaScript code monitors user actions taken on your site and relays them to the analytics server. These insights allow you to see your data in the way that makes the most sense to you, with both real-time analytics to help you inform ever-fluid social strategies as well as historical data that can give you a unique perspective on your content and how your audience interacts with it.

Once is up and running, organizational elements within Drupal may be used as section tags for use in tracking via, thus avoiding the need for assigning individual tags to trackable elements.

Again, one of Drupal’s biggest benefits is its extremely flexible node and taxonomy system, and we’ve accounted for that flexibility within the plugin itself. Whether you use content types, or taxonomies and tags for managing your site's published sections, we’ll help you get your data into as quickly and painlessly as possible.

Because of the power and flexibility of both Drupal and, wiring the two together took some time. But now, by simply installing the plugin, you can experience the power and versatility of Drupal with insights from -- and see just how your audience interacts with your content, both over time and in the last ten minutes!

Nov 23 2015
Nov 23

One of the great things about Drupal is its flexible system of nodes and taxonomies. This allows for bespoke categorization of many types of content.

At, we wanted to take advantage of that., which has an alliance with Acquia to bring joint tech solutions to the worlds biggest media companies, works with hundreds of digital publishers to provide audience insights through an intuitive analytics platform.

By using’s dashboards and APIs, publishers at any stage of the digital process can build online strategies that allow them to grow and engage a loyal audience.

Beyond precise measurement of views, visitors, shares, and time, includes breakouts of on-page attention, mobile devices, and visitor retention. Publishers can use this data to identify high-quality long-form content, engaging images and videos, new traffic sources for distribution, and audience interest segments that lead to loyalty.

Yet Drupal’s flexibility, while allowing for highly complex websites, has made it a challenge to take full advantage of’s capabilities, primarily because only experienced Web developers with HTML, CSS, and JavaScript chops could integrate the tools. Thus, integrating with a Drupal site heretofore meant each individual site had to make use of a dedicated Drupal developer to roll a custom solution.

The proposed solution: To alleviate this burden, we decided that a dedicated Drupal module which handled this integration for all sites wanting to use made a lot more sense. This would help publishers integrate with the platform to create fully custom sites benefitting from the full power of’s data-mining tools, without requiring them to have someone with in-depth programming skills to map the nodes and taxonomies onto’s back-end.

How it would work: The Drupal plugin would automatically insert the required page tag and JavaScript on all of the published pages and posts -- making it easier than ever to figure out what content is driving visitors to a site, and why.

Benefits of integrating + Drupal

The new for Drupal module is a great example of how well a proprietary platform can integrate with Drupal. For this, was fortunate to work with Forest Mars, founder at The Mars Group, to complete the first version of the Publishing Analytics project.

Mars said of the project: “ is a good match for Drupal because Drupal is a dynamic publishing platform with the ability to create and manage complex content relationships; this gives a high level of control over what content is reported and numerous integration points for control over how these analytics get reported.”

Some interesting aspects of the integration

The integration takes advantage of Drupal’s powerful framework and community of contributors.

Drupal is an ecosystem comprised of thousands of modules, built by thousands of developers. These modules offer site owners the unique ability to add new features and additional behaviors to existing code without having to modify the code itself.

To put it simply, developers can use combinations of modules, aka “recipies,” as building blocks to create additional functionality in Drupal. The initial module for enables sites to track certain content and reader actions, and, thanks to Drupal’s underlying architecture (or “Aspect Oriented Programming” in technical speak) other developers have the ability to take these integrations even deeper.

Anticipating interest from other developers in integrating the module with their own projects, the initial release includes a stub for future token integration in the build. Token, which is the 3rd most widely used of all contributed Drupal modules, provides small placeholders that  can be used in the Web interface to represent a data connection that would otherwise require writing a lengthy bit of code.

The module roadmap also includes possible integration with Metatag module which can provide the logic of when and where to output tags using tokens. The Metatag module also enables configuration inheritance.

Ultimately, the module will allow any data on a publishing website anywhere to be integrated in a way that is more customizable than traditional tools like Google Analytics.

Development made possible on Github

Rather than limit development to, the module is on Github, which is is automatically (some would say magically) synched to using the Hubdrop platform. In this way, any developer can fork the code from the repository on Github, and contribute changes with a pull request. Hubdrop then automagically pushes those changes to the module on This means that developers who are not familiar with the idiosyncracies of can easily contribute to using a more standard git process on the widely used Github platform.  

The integration is highly configurable.

The Drupal plugin is highly configurable and takes advantage of Drupal’s rich architecture. For tech newbies who who need to quickly and easily install the plugin and start tracking data on their website, it is essentially plug-and-play. However, for advanced power users, the plugin serves as a forward-looking toolset for any publishing website -- with lots of options for customization. As a matter of fact, in this first release, the configuration page has at least a dozen options -- all organized in drop-down menus so they are not so intimidating.

Using the Drupal module’s easy integration with Drupal modules is a testament to’s simplicity, and Drupal’s plug-and-play ecology. The module serves as a roadmap for deep integration with any data on any website. Data on your website that you need to view from a business perspective, you can view from the dashboard.

The plugin integrates analytics and metadata on your site in just a few clicks. Here’s how to integrate Drupal and

  1. Download and install the Drupal module from

  2. Enable the module in the “Modules” page of Drupal under the “Statistics” subheading, and hit save.

  3. Go to the settings page at: Configuration > Search And Metadata >

  4. Enter the Site ID (You can find your Site ID on your your settings page) and configure the plugin according to how your Drupal site uses nodes and/or taxonomies (the plugin requires you to choose one or the other to work).

  5. Click “Save” and your integration is ready to go!

A small piece of JavaScript code monitors user actions taken on your site and relays them to the analytics server. These insights allow you to see your data in the way that makes the most sense to you, with both real-time analytics to help you inform ever-fluid social strategies as well as historical data that can give you a unique perspective on your content and how your audience interacts with it.

Once is up and running, organizational elements within Drupal may be used as section tags for use in tracking via, thus avoiding the need for assigning individual tags to trackable elements.

Again, one of Drupal’s biggest benefits is its extremely flexible node and taxonomy system, and we’ve accounted for that flexibility within the plugin itself. Whether you use content types, or taxonomies and tags for managing your site's published sections, we’ll help you get your data into as quickly and painlessly as possible.

Because of the power and flexibility of both Drupal and, wiring the two together took some time. But now, by simply installing the plugin, you can experience the power and versatility of Drupal with insights from -- and see just how your audience interacts with your content, both over time and in the last ten minutes!

Nov 23 2015
Nov 23

In Drupal 7, hook_page_alter was a convenient way to go when we needed to modify page elements that were added by other modules. Drupal 8 does away with this hook - hopefully for the better. To fill the void created by hook_page_alter’s dismissal, the following hooks have been introduced.

In addition, we can still implement hook_preprocess_page, which does let us override or add content to the page. However, this hook is intended to prepare variables for the template and isn’t supposed to make drastic changes to the content.

I have gathered a list of use cases that I often face when needing to adjust page elements. Let’s see what are some possible solutions for each.

Adding CSS and JavaScript files

This is the exact scenario that the new hook_page_attachments and hook_page_attachments_alter were created for. They allow you to add CSS and JavaScript files to certain pages based on some conditions. Assets that need to be loaded on every page may be declared in a theme’s .info.yml file instead of being added by these hooks. Note that Drupal 8 works with libraries instead of individual CSS/JS files, so you will need to bundle your assets into a library before attaching them to the page. 

Applying attributes to HTML elements

I often need to apply attributes - mainly CSS classes - dynamically to certain elements. This is a job for hook_preprocess_page. That hook can prepare and place the necessary HTML attributes into a variable, which in turn can be printed out at the appropriate place in the template file.

Adding elements to the page

Previously with hook_page_alter, we were able to stick new elements into any part of the page, be it the main page content or one of the regions. This is no longer possible in Drupal 8. However, hook_page_top and hook_page_bottom allows us to add our items to the top and bottom region of the page, respectively. These two behave similarly to an alter hook, meaning they receive an array argument where they can add their items, as opposed to returning them.

Changing the template file used

In Drupal 7, the preprocess function received a theme_hook_suggestions array. Modifying the values in that array allowed us to influence what template file was used for rendering. The counterpart to this functionality can be achieved with hook_theme_suggestions_HOOK in Drupal 8. This hook is supposed to return an array of new template suggestions, which normally extends the range of possible templates. Similarly hook_theme_suggestions_HOOK_alter can be used to remove the suggestions of other modules.

Nov 23 2015
Nov 23

DCO Fall 2015 students
A few days ago, we graduated yet another class of students from our 12-week Drupal Career Online training program. This was the seventh session of our unique Drupal training program (not to mention the two most recent Acquia U classes) and - like Drupal - we're constantly evolving. This session brought the most significant changes to the curriculum since we've started - integrating some Drupal 8 content as well as a re-structuring of the schedule to put more of an emphasis on development workflows and tools.

This session's class was comprised of five students - four of whom are existing full-time employees of organizations using Drupal. The students had a wide range of experience, but all had a desire to learn best practices and the skills necessary to extend and maintain modern Drupal sites. We met in a virtual classroom three times a week for the duration of the 12-week program to learn new skills, work on in-class exercises, review homework, and discuss issues that the students experienced with both class exercises and real-world Drupal projects.

This session's graduating class includes:

As part of their training, they've been given a healthy dose of community involvement, including the importance of using IRC, attending Drupal events, and participating in the community. As you see these folks around, please give them a nice welcome!

From the very beginning of the Drupal Career Online program in 2011 (then called the "Drupal Career Starter Program") our goal has been to provide professional long-form Drupal training focusing on best practices, community involvement, and sustainable site building. To this end, we're constantly improving and expanding the curriculum. Currently, students are provided with PDF lessons, screencasts, online assessments, all in addition to the 7 hours of live, instructor-led training that are provided each week.

With the recent release of Drupal 8, it was time to re-think our curriculum and begin making some wide-ranging changes. In addition to adding Drupal 8 to a number of various site-building lessons and exercises, we made a rather large structural change to the overall curriculum to put more of an emphasis on comment development workflows. This change was based on feedback from both graduates and employers. For example, in the past we had separate lessons for Drush, Git, and working with remote servers. The curriculum now begins with basic Drush and Git commands and continuously expands on them throughout the 12 weeks.

The goal is to get students into the habit of using Drush and Git as they work on the various parts of a site. As the course progresses, we introduce the concepts of remote repositories (utilizing the GitHub, WebEnabled, Pantheon, and Acquia platforms) as well as remote development, testing/staging, and production/live environments. The overall goal being preparing graduates to be able to be revenue-generating members of their organization from day 1.

We're extremely proud of all our graduates and know that we couldn't do it without the help of our volunteer community mentors and Work Experience Drupal partners. Our next session begins in early March, 2016.

Trackback URL for this post:

Nov 23 2015
Nov 23

If you want to grow recurring revenue by providing SLAs for your Drupal projects, automation is THE key to offering a reliable response time. Of course, you could build a dedicated 24/7 support team - but the cost will be exorbitant!

There are many tools out there for digitizing your support and automating some of the processes. A well-defined support concept is the key to success. In this blog you'll get an introduction in four foundations of automated support systems. Read more

Nov 23 2015
Nov 23

This is tutorial #7 in the Drupal Commerce tutorial series. In the previous article, you learned how to modify the checkout flow on your Drupal Commerce site to collect more information. In this article, you will learn how to enable Express Checkout to increase conversions on your site. It's a fairly simple procedure that allows the shopper to proceed directly to the checkout without visiting the Cart. This saves time and ensures that you are able to win the shopper's business quicker.

Here is how the Express Checkout button will look after I am done configuring it:

To get started, you will have to download and unzip the “Commerce Express Checkout” module. Visit the following link to access the module:

You can enable the module by clicking “Modules” on the top-level menu:

Search for “Commerce Express Checkout” and enable it:

Click “Save configuration”:

Let’s now configure an Express Checkout button. Go to the following path:

  • admin/commerce/products/express-checkout-links

You will notice a “Select Product” dropdown at the top of the page. It allows you to select a product of your choice to associate the Express Checkout button with. I chose the product 3-LED Flashlight. Click “Generate Code”. A code will be generated in the dialog box below as shown in the screenshot:

You will have to add this code to any page on your site. I am going to add it to the 3-LED Flashlight product page. Copy the code to a notepad. Go to your product’s page and click “Edit” as shown below:

In the Edit page, paste the code in the Body. Make sure the dropdown for Text format is set to “Full HTML”:

Click “Save” at the bottom of the page:

Head over to the product you wish to purchase. You will notice an “Express Checkout” button like in the screenshot below:

Click “Express Checkout” and you will be taken directly to the checkout screen as shown in the screenshot below:

Next: Enabling Authorize.Net Payment Gateway

Nov 23 2015
Nov 23

Drupal 8 is finally here! We’ve been digging into the code and learning how to install D8 in a way that allow us to sync sites and use it for production work. A lot of things have changed, which we covered in our previous article, Up and Running with Drupal 8. The next step is to see what’s changed in the theming layer, installing a basic theme, and working with the new Twig templating system. There’s a good deal to cover, so let’s jump in!

Creating a Theme

The steps for setting up a basic site theme are fairly simple: create a custom/THEMENAME directory in web/themes, and then add a file with the following:

name: THEMENAME Theme
description: 'D8 theme for THEMENAME site.'
package: Custom
# base theme: classy
type: theme
version: 1.0
core: 8.x
  header: Header
  content: Content # required!
  sidebar_first: 'Sidebar first'
  footer: Footer

Then you can enable your theme (administer » themes) in the interface. Note that uncommenting base theme: classy will cause you to set Classy as a parent theme. We feel that Classy is great if you want a lot of useful examples, but really clutters up the markup, so use at your own discretion. After rc1, the default theme will be ‘stable,’ and you may want to pull all of the core templates into your theme to ensure you’re working from the latest updated template code.

Also, the theme name must not contain hyphens. So /theme-name/ is invalid (it won’t even show up!), but /theme_name/ is fine.

Now we’ll want to start customizing our theme. Let us say we have a content type called ‘blog’ (machine name: blog), with a field type called ‘Publish Date’ (machine name: field_publish_date).

Despite setting the label of field_publish_date to ‘inline,’ it’s wrapping to a new line due to the fact that it’s a simple, unstyled <div>.

Worse, it has no classes to specifically style it. Let’s set ourselves some goals:

  1. Add the inline styling class(s).
  2. Change the markup for this field, so that we have a class for the label.
  3. Add CSS to style the label, but ONLY for the ‘Blog’ content type.

The documentation for this seemingly simple task is obfuscated and evolving right now, but we were able to get it working correctly using the following steps:

Step 1: Turn on twig debug mode. We also found it helpful at this point to make a copy of web/sites/example.settings.local.php in web/sites/default/ and uncomment the following in settings.php:

if (file_exists(__DIR__ . '/settings.local.php')) {
  include __DIR__ . '/settings.local.php';

This will allow you to disable caching during development, which is no longer a simple checkbox in the performance section. Note that disabling caching can be tricky; the drush cr (cache rebuild) command is the most reliable way to ensure the cache is really cleared. You’ll also have to rebuild the cache at least once after turning caching off, so the new cache settings are applied.

Step 2: Make a custom field template.

In this case, the suggested debug fields are:

   * field--node--field-publish-date--blog.html.twig
   * field--node--field-publish-date.html.twig
   * field--node--blog.html.twig
   * field--field-publish-date.html.twig
   * field--datetime.html.twig
   x field.html.twig
<!-- BEGIN OUTPUT from 'core/modules/system/templates/field.html.twig' -->

The highlighted line above shows the template currently being used, suggestions for increased specificity, and the file location (core/modules/system/templates/).

We want to update field_publish_date globally, so we’ll create a template called field--field-publish-date.html.twig

To do this, we copy field.html.twig from the core theme (see the ‘BEGIN OUTPUT’ line above for the path), and rename it in our theme’s folder to field--field-publish-date.html.twig. Now when we reload, we see the following (if your cache is disabled, of course, otherwise drush cr will clear the cache):

   * field--node--field-publish-date--blog.html.twig
   * field--node--field-publish-date.html.twig
   * field--node--blog.html.twig
   x field--field-publish-date.html.twig
   * field--datetime.html.twig
   * field.html.twig
<!-- BEGIN OUTPUT from 'themes/custom/THEMENAME/templates/field--field-publish-date.html.twig' -->

Now we can begin to update the markup. The relevant code is:

{% if label_hidden %}
  ... (we don’t care about the label_hidden stuff)
{% else %}
  <div{{ attributes }}>
    <div{{ title_attributes }}>{{ label }}</div>
{% endif %}

To add the inline styling class, we add the following to the top of the template (below the comments):

  set classes = [
    'field--label-' ~ label_display,

And then update the label’s parent div attributes:

before: <div> after: <div>

Now the correct class is in place, but we see no change yet - because the <div> isn’t populating any classes. To fix that, we add the following, again at the top of the template:

  set title_classes = [
    label_display == 'visually_hidden' ? 'visually-hidden',

And update the div:

before: <div></div> after: <div ></div>

Rebuild the cache (drush cr) and… success! well sort of - we still have to add CSS. Note that we also added a custom class of 'field__publish-date-label' in case we want to style it directly.

Step 3: Add a THEMENAME.libraries.yml file to hold attachment library definitions.

This is pretty simple; it’s a file with the following:

  version: 1.x
      css/blog.css: {}
    js/blog.js: {}
    - core/jquery

We then add the directories (/css and /js) and files (blog.css/js). We’ve also added a jQuery dependency, just so you can see how that’s done. If we had something simple that could be done with Vanilla JS we could leave it off. Note that this won’t actually do anything until we follow step 4 below.

Step 4: Add a THEMENAME.theme file to hold theme hooks (this is actually a PHP file, so start it with <?php).

This is the code that appends the library based on the content type. The trickiest part of this is figuring out the correct format of hook_preprocess_HOOK():

function THEMENAME_preprocess_node__blog(&$variables) {
  $variables['#attached']['library'][] = 'THEMENAME/blog';

The theme hook format for content types is to use node__MACHINENAME format - two underscores.

After that, rebuild your cache (drush cr), and your CSS and JS files should be loading on every instance of that content type, regardless of the page. (full or teaser)

And that’s it! Note that we could have changed the markup in any number of ways to suit our designs, or even make the template specific to the content type as well as the field.


The post was written at the end of 2015 while Drupal 8 was still in a Release Candidate stage. While some effort will be made to keep the post up-to-date, if it’s after 2016, you should probably add the current year to your Google search, or better yet, check the docs on

Nov 23 2015
Nov 23

Our First Site Built with Drupal 8 - How we did it.

  Posted on November 23, 2015 by Bob Kruse

I'm happy to say that we relaunched our parent agency's site on Drupal 8 within one day of Drupal 8's release, however it would have been the same day if we didn't encounter some last minute "drush up" fails causing us to rebuild some parts of the site (all the the page manager variants that magically disappeared in the updates). Regardless, we got it up and here are the highlights of our experience and also a few mini tutorials.

Building a real site in Drupal 8

We started in the D8 Beta stage with a fresh install, then scratched our heads because our usual building block D7 modules weren't ready yet, like page manager, panels, panelizer, webform, to name a few. I feel like we were a bit spoiled in D7 because we leveraged contrib modules so much that going back to template files felt a bit foreign. So this forced us to rethink and get back to the basics of building a Drupal site.


Working with Twig

There are a ton of great tutorials out there to get you started with building a new twig theme, so I won't go there. Once you get past those nuances, the actual theming process is very similar to D7. Just edit your template files and add the twig variables.

The coolest part about Twig is enabling the Twig debugging, which shows you in the code where theme file suggestions begin and end. This made it really stupid-easy to find out what theme files we needed to edit.

Twig Debugging

The hardest part about working with Twig is getting the variables you want. You can use {{ dump }} which always caused me to run out of memory or {{ kint() }} which worked but didn't always show me what I was looking for. Ex. When I was seeking out the url of an unrendered image field, if took hours of searching to find the right answer. Thank god for stackexchange because many answers are there, but I think we're in need of a resource to explain how those answers were derived.

For example, to display an image field URL in a twig template file, it's {{ node.field_your_image.0.entity.uri.value }}. This wasn't something we could find in the array dumps.

To sub-theme or not to sub-theme

We never really needed subthemes. When we first started building Drupal sites back in 2008, we always built our own themes. If you're starting with pre-built html and css mockups, then just inserting Drupal's theme variables is quite easy.

I think it's best to start out this way because then you get a feel for what drupal outputs naturally, whereas if you always used a base-theme, you don't know if the output you're looking at was a product of native drupal or some magic of the sub-theme. Some people may not care about this, but you will care when you have to debug something and you don't know where to look first – was it drupal, the sub-theme, or a module?

So our approach with Twig was the same, no sub-theme. The cleanliness of Drupal's output in D8 is wonderful and very easy to work with.

Adding in some Bootstrap

We're huge fans of the bootstrap framework and in D7 we had the best setup – bootstrap base theme with the panels bootstrap layout builder. This allowed us to rapidly build bootstrap sites extremely easily.

In Drupal 8, the bootstrap base theme wasn't really necessary for our site as we could just simply add in the bootstrap coding through our theme files. In the past, the area where we really needed the bootstrap theme's magic was for theming form elements since bootstrap has a particular group of form classes and structure that takes some finagling to get drupal to output. Luckily in our case, we only have one form and it was easy enough to form_alter to get the structure needed.

Site Building

In Drupal 8, site building feels very familiar to Drupal 7, so getting accustomed to the new system wasn't difficult at all. However the feeling of impotence set in when we realized that our usual method of building a site had to change since our goto toolset wasn't available.

The scary world of contrib modules

Everytime we enabled a module, it was a scary, cross-your-fingers moment. So many known reliable modules from Drupal 7, could easily blow up a site in D8. Backup and Migrate, Admin Menu, and Webform caused fatal errors for us making the site unusable. We quickly learned that deleting the module and then deleting everything in /sites/default/files/php was a way to recover.

Page Manager & Panels

We use Page Manager, Panels, and Panelizer a lot. And for the custom layouts we needed for the new site, we had to make them work. Page Manage actually kinda works and Panels kinda works. Panelizer, as of this writing, does not.

We used a custom (Page Manager) page for each page in the site and then created custom panel layouts for each – since the panels layout builder doesn't work yet. There isn't documentation for how to actually add custom layouts so we figured that out with some trial and error. Here's a mini-tutorial on that:

How to create a custom Panels layout in Drupal 8

1. Add a yourtheme.layouts.yml to your theme. Here is an example with for our blog layout:

  label: Blog Layout
  category: Blog
  path: layouts/blog
  icon: blog.png
  #css: blog.css
  template: blog
      label: top
      label: left
      label: right

2. Create actual files for the custom panel layout in your theme. In this case it's:

  • sites/themes/yourtheme/layouts/blog/blog.html.twig
  • sites/themes/yourtheme/layouts/blog/blog.png
  • sites/themes/yourtheme/layouts/blog/blog.css

3. In blog.html.twig you simply add your custom markup and variables for the regions you defined in the yourtheme.layouts.yml file. So in this case, our file looked like

<div class="container">
  <div class="row">
    <div class="col-md-12">
    {{ }}
  <div class="row">
    <div class="col-md-9">
                {{ content.left }}
    <div class="col-md-3">
        <aside class="sidebar">
                {{ content.right }}

And that's basically it. Clear your cache and now you should be able to select it when you add a Panel to your Page.

Views rocks

It's great having views right out of the box. It works just like Drupal 7, so no surprises there. I was right at home. Now that all the taxonomy pages are driven by views, that made it really easy to theme them without the need for an extra module like TVI or Taxonomy display.

No views theming suggestions

One feature missing in D8 Views, that was extremely helpful in D7 views, was the Theming Information link in each view that showed you all of the theme file suggestions you could use to theme each part of the view output. The syntax of the files names are always so long and confusing, and then you have single and double dashes with underscores and more dashes, it can be a nightmare for someone with a little dyslexia (like me). So we had a separate D7 install with the same views just so we could get the theme filename suggestions. Eventually, not having the theme suggestions, forced me to learn their syntax, so I guess that made me a better themer in the end.

Views Theming Information missing in D8

Blocks rocks

I found that a majority of my content now lives in blocks. In D7 there was this big anti-block movement, but in D8 it's kind of the only available tool. When building a Panel layout, you can't create custom content panes, they aren't there yet, so the only option is to add blocks.

What's nice about D8 blocks is that they have block-types, can have fields added, and can be added more than once on the blocks layout page. The UI is a little confusing because when you delete a custom block from the blocks layout page, it just deletes its placement, not the actual block. But once you get used to it, it's all very functional.


For many years Webform was our goto form module. In D8, it's not ready. Entity form was our next option (eform in D8) and it does allow you to build form with native fields, however it relies on Rules to send emails… and Rules isn't ready yet. So the only option left, which I didn't even consider was the built-in Contact module. For years, it's been a pooped-on module no one uses. But in this case, it was the only option that actually worked. And paired with Contact Storage, which saves the form submissions, it's a workable solution.

While Contact module does work, I consider it a temporary solution until webform is ready. It's not very customizable, like you can't change the email formatting or the button label without digging into code.

For client projects, we'll need something easy for them to use to build and edit forms with and Webform fits the bill. People have been complaining for year about Webform not using Drupals built-in fields, but from a UI stand point I don't want to have to explain to clients was Booleans are or what a List (Integer) is versus a List (float). Webform makes it easy and end-users like easy.

For spam protection, Honeypot is available! And you know how we love honeypot.

What I'm looking forward to

The site building experience for Druapl 8 was ultimately a positive one. Once all the contrib modules catch up it will be useable for our client projects.


For SEO, we don't have a metatag module that works yet, so we had to add meta descriptions by code. That wasn't too fun. Here's another mini tutorial:

How to add a meta description tag in Drupal 8

Open up your up your yourtheme.theme file and add the following:

 * Implements hook_page_attachments().
function yourtheme_page_attachments_alter(array &$page) {
        $current_path = \Drupal::service('path.current')->getPath();
        switch ($current_path) {
                // Home page
        case '/home':
                        $viewport = array(
                                        '#type' => 'html_tag',
                                        '#tag' => 'meta',
                                        '#attributes' => array(
                                                'name' => 'description',
                                                'content' => "Home page description",
                                $page['#attached']['html_head'][] = [$viewport, 'viewport'];
                case '/node/1':
                        $viewport = array(
                                        '#type' => 'html_tag',
                                        '#tag' => 'meta',
                                        '#attributes' => array(
                                                'name' =>'description',
                                                'content' => 'some other page description',
                                $page['#attached']['html_head'][] = [$viewport, 'viewport'];
                } //end switch

You need to create a case for each url.

The Admin menu

I'll admit, I don't like the built in toolbar. It takes too many clicks to get around and I'm always moving it to the left, then top, expanding options on the left, but you can't expand options from the top – it's very frustrating. I want the Admin Menu module. It might not be mobile friendly, but when building a site on a desktop, I'll take all the speed I can get and Admin Menu lets me move quickly.

Global Redirect and Redirect

When you're redesigning a site, the urls are going to change, so the redirect module would be really handy to handle that… it's not ready yet. Instead we have a huge htaccess file of redirects and a stupid 404 page with a mullet guy. For Drupal 8, Global Redirect and Redirect are merging into Redirect, so don't install Global Redirect, also it will crash your site.  

Final thoughts

Overall we used a lot less modules than we would have used in Drupal 6 or 7. The lack of available modules forced us to think outside the box and sharpen our chops when it comes to theming and site building. If you want to check out our parent agency site, click here. It's certainly not perfect, but it's our guinea pig Drupal 8 site and will be a continual work in progress. 

About the Author

Bob Kruse is the founder of Drupal Aid and a Drupal fanatic since 2008. He is also the creator of Cart Craze, an ecommerce website design gallery and Sick Journal, an online tool for keeping track of your family's health, sicknesses, and medications.

Nov 23 2015
Nov 23

You might wonder whether you need automation task runners like Grunt or Gulp with Drupal. Common usecases for these tools are css/js aggregation/minification but these are already handled well by Drupal, or if you need more control by modules like Advanced CSS/JSS aggregation.

There are however at least two ways in which a task runner can help you out: frontend testing and "livereload". I won't be covering frontend testing here, that's something for another post, but it's worth mentioning because it is comething which is currently often lacking in Drupal project. Note: there is an attempt in this issue to bring frontend testing into drupal core using behat/phantomjs.

Browser syncing
Browsersyncing will inject newly created CSS (compiled from Sass) into your browser without the need for a hard page refresh. This saves a lot of time, especially on pages which needs a lot of clicking to get to the right elements.

Here is the setup:

  • Install Gulp (you will need nodejs on your system)

Goto your theme folder and run:

npm install gulp gulp-sass browser-sync

This will install gulp and 2 plugins: gulp-sass and browsersync. This will also create a node_modules folder in your theme dir.

Note: gulp-sass uses libsass which is *a lot* faster than ruby-sass. If you are using phpstorm with a compass watcher, you can now disable that for your projects.

Next, create a gulpfile.js in your theme folder and edit the following code. You might need to replace folder names according to your own.

var gulp        = require('gulp');
var browserSync = require('browser-sync').create();
var sass        = require('gulp-sass');
// sassOptions are optional but things like sourceComments (line_comments) can be pretty handy.
var sassOptions = {
    errLogToConsole: true,
    outputStyle: 'expanded',
    sourceComments: 'normal'
// Defining our 'serve' task which is called at the end.
gulp.task('serve', ['sass'], function() {
    // if you are using a VM or something like MAMP you will want to use a proxy:
        proxy: 'http://my-site.localhost'
    });"sass/*.scss", ['sass']);"scripts/*.js").on('change', browserSync.reload);
// Compile sass into CSS & auto-inject into browsers
gulp.task('sass', function() {
    return gulp.src("sass/*.scss")
        .pipe(sass(sassOptions).on('error', sass.logError))
        .pipe(browserSync.reload({ stream: true })) // this is where the magic happens
gulp.task('default', ['serve']);

What this javascript basically does is: define two tasks ('serve' and 'sass'). When gulp starts, serve will be called which in turn watches your *.scss files. If there is a change, it will call the sass task which compiles it to css and inject the css to your browser. If there is a *.js change, it will do a hard refresh.

Next, install browsersync module. For a normal non-drupal project this might be sufficient, but for Drupal we will need this additonal module for two reasons: 

  1. browsersync needs an additional javacsript embedded at the end of your page to make it work with a proxy setup
  2. Style sheets need to embedded with the <link> tag instead of @import. Drupal 7 & 8 use @import when aggregation is turned off in order to workaround the limitations for including a maximal numer of CSS files up to IE9, but we won't be needing that anymore.

Note: there is a functional release for Drupal 8 of this module in this issue.

Last, you will need to fire up Gulp by starting it using the command below, executed from the theme folder:


This command will fire up a browser tab which will read localhost:3000 but it will show the site you defined in your gulpfile as proxy. You should briefly see "Connected to BrowserSync" in the upper right corner. Now, try edditing and saving a sass file.

Note: as a bonus you get the BrowserSync UI which has some nice goodies. Watch your console after you startup Gulp for the URL.

Grunt vs Gulp
I focussed on Gulp in this post because I think it's a better fit for Drupal: it seems enforce less and be more flexible and I'm more familiar with it, but It's probably possible to achieve the same goals with Grunt.

Nov 23 2015
Nov 23

Drupal Public Sector

Drupal Public Sector

As a tax payer I want companies who provide frontline public services to make the data they gather in the provision of such services available through Open APIs to other actors in the ecosystem, so that such actors can utilise that data to provide new and innovative services to the public.

News from Australia shared with the DPSX BoF at DrupalCon Barcelona back in September was both good and bad, whilst the Australian government is spearheading adoption with the GovCMS distribution, efforts are we were told loosing steam as the distribution in its current form is quite restrictive requiring significant customisation by individual departments adopting it. The question is why fork it? why not modularise it? To get some answers that may help us in the UK I reached out to my Acquia colleagues in Australia to shed some light on the matter and this is what they had to say:

govCMS is growing and maturing at a good rate after a slow start. The fundamentals have been adjusted to allow for greater openness and govCMS_logo (3)_1

govCMS_logo (3)_1

community interaction with the distro via github. The Australian Government is delivering on their aim to work with the community. We are expecting to see further iterations of the govCMS product over the next 12 months that will improve the ‘out of the box’ experience and allow clients to get sites up and running quickly/cheaply. Expect to see improvements that either reduce the need for customisation and make custom work easier.

The restrictions you mention are by design – they largely relate to the modules available to developers. By providing best of breed modules, the distro can avoid bloat/cost. The other effect is to focus expertise on those modules so they become easier to implement via experience and documentation that are relevant to this client space. That said, the process of requesting changes has also moved to github in the last few months and is less a ‘black box’ than it was initially.

As to why govCMS was forked – this largely related to the need Australian Government had to work with a stable platform where they could apply their own governance controls. This will probably mean a distro that evolves at a slow and steady pace, with a focus on security and compatibility. Australian Government is also sensitive to appearance that they are endorsing one vendor over another, or becoming subject to vendor lock in, taking ownership of the distro removes this issue and makes further broad investment by a range of departments more likely.” Gavin Tapp | Program Director | Acquia

There are valuable lessons for local councils in the UK seeking to create a local government distribution, which ought to make for engaging conversations at the 13th January 2016 meetup of the DPSX in London. If you’d like to a part of the conversations please register for the free event here:

Nov 23 2015
Nov 23

There are a lot of different reasons why people need a site audit. For example, you may be transferring a project from an old team to a new team that needs to understand the project what they're taking over.

Or maybe there's an internal management change inside a large organization.

For example, in an audit I'm doing now, the site was managed by one team and now they're splitting up the company and that team is not going to manage the site anymore. The people taking over have no experience with the site and they want to find out what they're dealing with.

Was it Done Right?

They might have specific concerns like security or performance that they want to audit. They might be planning a whole new phase of their project and they would like to understand where they're at with their site beforehand.

Sometimes an audit is requested to validate a hunch. Sometimes a manager doesn't think a site was built well, and wants an audit to show that. On the other hand, there are times when a developer wants an audit to show their boss that they did do things right. For example, we had somebody who wanted an audit because his boss kept on telling him that he built the site wrong because he used multiple content types and his boss was sure that you should only ever have one content type. So he wanted an audit that would back him up and say he did a good job, and he did actually do a great job.

Update to Drupal 8

Another reason you might have an audit in 2015-16 is that you're considering upgrading to Drupal 8 and nobody can give you a good estimate of how much it's actually going to cost you to upgrade because nobody knows what your site does or even what problems it has. You might need an audit just to help you evaluate that.

Here Comes Judge Jody

At work, they call me Judge Jody. Being judgmental is one of those personality traits that’s both positive and negative. But when it comes to doing certain types of tasks, being judgmental is very useful. You might have some people on your team that are very open and accepting who say, "Oh, that's an interesting idea" to just about everything. They don't disagree strongly with much of anything. These folks are not necessarily the best ones to do an audit because they'll go through and all they can come up with is, "Oh, that's interesting." Someone who really has strong opinions can go faster and decide what looks problematic.

One Judge...Or Many?

You could have just one of your top people doing an audit, but you can also split it up into multiple domain experts. I also like to have an assistant when I'm doing the auditing, someone more junior who can help me write up the document, do the document formatting and learn while we're going along. As you're working on an audit you're not just learning how to do a site audit, you're also learning a lot about Drupal and the different issues people can get into making sites. I've learned more from looking at all of the awful sites that we inherit and rescue than I would have just building sites on my own because you see the consequences of all the different bad common practices that people make, where it leads, and how much work it is to clean it up. It makes me feel more strongly when I say, 'we never do this this way and this is why. We've seen what happens.’

It's also good if someone on the auditing team will potentially continue working on this site if this becomes an ongoing project. No matter how much people write in their reports, they're also putting a lot in their heads getting to know this project. That's really valuable and you want them to continue working on the site. It actually takes a long time to really get to know a project if it's a pretty complicated site, or just a particularly troubled one.

Manual or Automated?

There are parts of an audit where you should use automated tools. But it’s also important to do a lot manually and just look everywhere. I'll look from the top left pixel all the way across to the bottom right. Then I'll look at the server, the code and every page I can. I'll look at the HTML, the CSS, the navigation, and the content itself. One of the amazing things I take away at the end of some site audits is that after a week of looking at some sites I still have very little idea of what the organization does, or perhaps how to purchase a product from the company. Noticing that the site does not serve its primary mission is something automated tools will not do for you.

Document Everything

I start an outline in a Google Doc, and I follow my curiosity around the site. Productive procrastination is my main mode. When I don't feel like looking at the permissions, I go look at the design, and keep jumping around until the outline starts to fill itself out.

The first step is to get access. If it is a problem to access the server, the code base, or get a copy of the database, that in itself can be a finding of the audit. If the people you're working with don't know how to get you a copy of the database or access to the server, or they don't have SSH keys, that is part of the environment that the site is living in. It could itself be a finding. These sites don’t exist in a vacuum.

If the client refuses to give you access because they have some security reasons and nothing you can sign is going to do anything about it, you'll be really limited so you'll have a smaller scope to your audit.

Ideally, work locally and get a local copy of the site set up. That way you can click around everywhere, run all the automated reports you want, and not have to worry about messing anything up. As an auditor, you change nothing. Click everywhere, but never hit save.

Typically in an audit the more you find, the better. You're not going to lose points for looking at things that people didn't think you were supposed to be looking at. Take notes the entire time you're looking so you can eventually write those up into a proper document.

Talk it Over

It’s critical to set up a series of meetings as part of the audit. First, have a kick-off meeting to get basic background information: a little about the organization, how this site came to be, what it's supposed to be doing, and who's involved. Confirm the boundaries of the audit- for example should you be auditing everything at one subdomain, or more. Also make sure you have access to everything you need. There’s no need to get into too much detail at that kick-off meeting other than a basic situational awareness.

After a day or two of digging into the site, I like to have another meeting because then I have some questions and I'm very focused on the project at that point. Then I like to really dig in and ask questions about their specific concerns and odd things I’ve started to uncover.

You want to make sure that you're auditing and paying special attention to things that that the client is focused on and concerned about. It's also important to have these meetings to get a sense of the client’s technical vocabulary and background and whom you're actually addressing in this audit. It's easy to make an audit that makes you look really smart, and they will not use it at all because they don't understand what you're talking about and you’re not making your points clearly enough. Then we just have this huge, intimidating pile of paper. It’s about clear communication and not being pedantic.

Stay tuned for Part 2: Top Three Priorities of A Site Audit.

Nov 23 2015
Nov 23

You want to grow your Drupal business an important part of this is going to be how you engage with your employees so they stay interested in what you do. As a manager of your business, your employees are just as important as the clients as you may need these employees as some point to keep your customers happy.

You may not have the current skills to keep employees engaged with your business and clients. This is where good management skills come into play. When you have happy clients, you get more referrals and repeat business. It’s in your best interest to ensure that all employees are engaged with the business and that this attitude is translating to how they interact with clients and customers. This article Looks at ways you can keep employees engaged with your business. You may have overlooked some of these and some you may not have even considered before.

Why Keep Employees Engaged?

As your Drupal business grows, you need to have employees that are engaged. You can tell if you have an engaged employee because they are enthusiastic for the company and work that they do for you. They believe in the objectives and goals that the company has set forth and are actively working towards those goals.

When you have employees that have the above characteristics they will make the decisions that are in the best interest of your company and the clients you work for. You need a team and not just a bunch of individuals that so their own thing. When you have engaged employees it makes it easier for you to sleep at night because you’ll know that everyone is on the same page and working as a team should towards the goals the company has.

Secret to Engaged Employees

If you run a Drupal business, things are hectic all the time as you have plenty to do. You may have deadlines and some of the team member may not carry their weight in the way you would like. As a small business, even small problems can feel like monumental ones. You may blame employees on factors that are external, but it really comes down to your management skills. You can improve this to become a better manager so employees are more engaged.

Some stats from the Harvard Business Review that will let you know why good management is important:

  • In a study of 27 million employees and many organizations over 20 years its estimated that 70% of the variance of employee engagement is caused by management.
  • In 2012 30% of employees said they are engaged at their work

The studies said that only one in ten have the qualities of a good manager which are:

  • An ability to motivate the employees
  • Assertiveness to get employees to complete a task or reach a deadline
  • Good managers have accountability
  • They can build transparent and open relationships
  • They focus on productivity and not office politics

These skills can all be practiced which will make you a better manager so your Drupal business is more successful.

Nine Creative Ways for Employee Engagement

You need to put your skills to use to engage employees. Here are some ways to put them to use in your Drupal business.

1. It’s “We” not ‘I”

You need a team and not individuals so the word “I” should be replaced with “we.” To grow your business you need a team effort so get everyone on the same page. A solo freelancer can think of themselves as ‘” I,” but if you want your business to grow and have your employees all work together, you need a team!

2. Open Communication

You want to have open communication. You have to be able to communicate things to your client as well as your employees. If you have honest communication, then employees will feel more comfortable communicating with you too. Encourage employees to discuss their opinions and thoughts even if they are the wrong ones or you don’t agree with them.

Try to have an open office environment free of cubicles if possible. You may have a corroborative space in the office area. If you do a lot of work online with your team use Hangouts, HipChat or Slack. Keep your employees up-to-date about what is going on with the business so they feel engaged. Let them know about the goals you have and how their work is going to help. The employee will feel like they are accomplishing something and will work harder toward the goal. Employees want to have a purpose with your company so communicate with them and get them excited about the job.

3. Consistent Management

You need to let employees know what is expected of them. If you’re not clear, then things are not going to get done in the way you want them to. You don’t want to have employees that are unsure about what to do. If employees don’t know what to do, they won’t be as committed to the work and may even make costly mistakes. Try to keep expectation consistent and communicate when changes are being made so employees know what to do. Your team will be committed if they know what your expectations of them are.

4. You Lead by Example

If you make exceptions for yourself, employees may too and the business will suffer as a result. You have to be the one that sets the standard for the business so others will follow your lead.  For example, don’t talk poorly about a client even if you feel like it, as the employees may do this as well. You want employees to follow the vision of the company so be the leader they look up to for direction.

5. Employee Opinions Matter

You want employees to feel like they are part of a larger vision. When an employee discusses something with you or shares an idea, it should be looked at and investigated. This keeps the employee engaged as they feel like a contributor to the business. Employees want to have an effective voice in the company and feel like they are a larger part of it.

6. Reward those with a “Think for Yourself Mentality”

You want to delegate tasks to the right people when it’s needed. You also need to encourage employees to think and act on their won to get things done. Don’t discourage employees from taking a calculated risk or using imitative if this is in the best interests of the company or a client you’re working with. You want employees that have an entrepreneurial mindset and will think outside of the box as they think about the business. Give your employees opportunity and when they do well, reward them for their actions.

7. Professional and Personal Growth Should Be Encouraged

Employees will be engaged in the business if they feel like you’re engaged with their lives. You can accomplish this by helping them with professional and personal growth. Maybe the employee needs a bit of time off of work for a project or just needs a vacation. If you help employees as much as you can, then they will bring their “A” game to work and give you better results.

8. Respect for Personal Time

There are many people who dedicate their time and energy for Drupal. People will work hard for you, but they need personal time as well. You want employees to give 100% at work, but they need to have an opportunity to give 100% to other things that are important to them. This will include, leisure, family as well as vacation time. You want employees to be fresh and ready to work so they need time to themselves. We all can’t work 100% of the time. An employee that has balance between personal life and work life will be more engaged and will give their best when they are at work.

9. If You Critique Others, you Have to Accept it Too

You want to have open communication, but you have to be open to critique of your management skills. You want engaged employees to be able to offer their opinions. You may find that some employees may have suggestions that can help you be an even better manager. Constructive critique can’t hurt you and it will only help you manage better than before. This will help not only you, but the entire team perform at their best and work towards those important goals you have for the business.


Keeping employees engaged in the business can be difficult, but you can get it done. Your Drupal business will benefit a great deal if you’re working on your management skills and becoming the leader you need to be to move the business forward to reach your goals.

You may not be a great manager now, but you can learn to become a great one. By working on your management skills and ensuring your employees are engaged in the business, you’ll grow your Drupal business like never before. It really comes down to how you treat your workers and the respect that each member of the team has towards each other. When you all work on the same page, good things will happen.

Nov 21 2015
Nov 21

By Nick Savov 20 November 2015

Installing Drupal 8Drupal 8 just launched and we're starting to release videos from the Drupal 8 Beginner class.

In this video, Rod will show you how to edit your content from the front-end. This inline editing is a really cool and useful new feature in Drupal 8. It will make life much easier for site editors.

All about Drupal 8's inline editing

About the author

Nick is the Director of Support at OSTraining and you can find him in almost every area of the site, from answering support requests and account questions to creating tutorials and software.

Nov 20 2015
Nov 20

Now that Drupal 8.0.0 is released, let's take a look at all the components of the Drupal migration ecosystem and where they stand now. To provide context to those familiar with migration under Drupal 7, I will show where the pieces came from. First, general migration support:

Feature D7 D8 D8 status Basic migration framework migrate (contrib) migrate (core), plus destination plugins in core modules Experimental General-purpose drush commands migrate (contrib) migrate_tools (contrib) The most common commands (ms, mi, mr, etc.) are working General-purpose UI migrate_ui submodule of migrate (contrib) migrate_tools (contrib) Just basic display of migrations and their status so far CSV source plugin migrate (contrib) migrate_source_csv (contrib) Working XML source plugins migrate (contrib) migrate_source_xml (contrib) A basic initial implementation exists, still needs work JSON source plugin migrate (contrib) migrate_source_json (contrib) A basic initial implementation exists, still needs work List source plugin migrate (contrib) migrate_plus (contrib)? Currently assessing how to architect this in D8 - most likely will be helper classes or traits in migrate_plus Other source plugins migrate (contrib) Contrib To be implemented as needed, by the people who need them Migration groups migrate (contrib) migrate_plus (contrib) Hopefully we'll finally get this into core for 8.1 Basic programming examples migrate_example submodule of migrate (contrib) migrate_example submodule of migrate_plus (contrib) Working but needs an image migration example Advanced programming examples migrate_example submodule of migrate (contrib) migrate_example_advanced submodule of migrate_plus (contrib) Skeletal at the moment Migration support for contrib modules Ideally in the contrib modules themselves - some legacy handlers are still in migrate_extras Contrib Each contrib module is responsible for implementing its own destination plugins (for general migrations), plus migrations and source plugins for migrations/upgrades from another Drupal site Migration from manifest files (lists of migrations with configuration overrides) N/A migrate_manifest (contrib) Only supports template-based migrations from SQL sources

And then, features specific to migrating from another Drupal site:

Feature D7 D8 D8 status Major Drupal version upgrade (drush command) pm-update (in Drush itself) migrate_upgrade (contrib) Working - to be moved to Drush itself (hopefully by Drupal 8.1.0) Major Drupal version upgrade (UI) /update.php migrate_upgrade (contrib) Working - to be moved to Drupal core (hopefully by Drupal 8.1.0) Framework for migration from Drupal 6 and 7. migrate_d2d (contrib) migrate_drupal (core), plus migrations and source/process plugins in core modules Experimental. The D6 support is essentially complete; D7 is lacking support for some secondary core modules, file/image fields, etc. Framework for migration from Drupal 5. migrate_d2d (contrib) migrate_drupal_d5 (contrib) Very basic support for key core data (taxonomy, users, nodes). Not updated in a few months and probably needs rerolling for 8.0.0. Framework for migration from Drupal 8 N/A migrate_drupal_d8? (not yet created) Planned. Most likely will be initially implemented in contrib, to be submitted to core in a later minor release. Support for custom migrations from Drupal migrate_d2d (contrib) migrate_d2d (contrib) Not yet begun

Notes on the statuses above:

  • The migration support in core is currently marked "Experimental". This means there are still some holes to fill (particularly for upgrading from Drupal 7), and still some leeway to make backwards-compatibility-breaking changes for Drupal 8.1.
  • I say "Working" rather than "Supported" for a few things above because A. All of these components are dependent on the core framework which is still subject to change, and B. To this point none of this has had substantial real-world testing, so there are likely significant issues still to be addressed.

So, you may be asking yourself "what can I do today, and what modules do I need to do it?"

I want to upgrade from Drupal 6 or 7 to Drupal 8

You can do this today with migrate_upgrade. As stated above, the Drupal 6 migration path for core modules is pretty much complete. If you're looking at upgrading from Drupal 7, review the meta issue for Drupal 7 migrations to see if any of the missing pieces are important to your site. See my previous blog posts for detailed run-throughs of performing the upgrade through the UI or with drush.

I want to implement an upgrade path for my contributed or custom module

Unfortunately, documentation is lacking at the moment to help module authors implement upgrade paths from previous Drupal versions - I hope to work with others on this (and also post to my blog) in the coming weeks. For today, the tl;dr is:

  1. Contributed modules are no different from core modules when it comes to the upgrade path (with one small caveat below), so
  2. Find the core module most similar to your module in terms of the kind of configuration and data it manages, and see how its upgrade path is implemented (specifically, look in its migration_templates and src/Plugin/migrate directories).

The one caveat is that for non-core modules, running the upgrade process through the UI will incorrectly report that no migration path is found for your module. This is due to the fact that currently there is no automated way to identify the source module for a migration, thus the UI is working from a hard-coded table of core migrations. This is a cosmetic issue only - your module's migration will still be run.

I will also note that in terms of debugging your upgrade path, the drush migrate-upgrade command has a very handy --configure-only option, which runs the configuration portion of the upgrade (turning migration templates into migration configuration entities) without actually running the imports. When debugging a specific upgrade migration, I will use this option, then (with migrate_tools installed) import all the migrations previous to the one I'm testing. At this point I can do drush sql-dump >/tmp/backup.sql. It's much faster to test the migration, tweak it, and restore the backup for another try than it is to go all the way back to the beginning.

I want to perform a custom migration from Drupal

Ultimately, there should be tools like the migrate_d2d UI in Drupal 7 to enable you to customize what you're importing and how it's mapped into your Drupal 8 installation - but that's going to take some time. At this point, the simplest approach is to run the drush migrate-upgrade --configure-only command to generate the migration configuration for a straight upgrade, export that configuration to config/install in a custom module, and edit the migration .yml files to suit your needs.

I want to perform a custom migration from not-Drupal

You'll need the migrate_tools (drush commands and basic UI for running and managing migrations) and migrate_plus (provides group functionality migrate_tools needs, plus examples) modules. In migrate_plus, open up migrate_example/README.txt and it will guide you through the basics of implementing SQL-based migrations. It's simpler than you think!

If you're importing from source data not in an SQL database, there are CSV, XML, and JSON source plugins available. It's still well worth going through migrate_example to understand the general structure of migrations - it's just that the configuration (and potential extension) of the source plugin will differ.

I want to help

Obviously, there's a lot left to do here, both in the core framework and in the contrib tools. Please, by all means, report any issues you find in the relevant issue queues, and feel free to submit patches to fix bugs or add additional features.

At this stage, the best thing you can do (especially if you're not a developer) is test the upgrade path for your Drupal 6 or Drupal 7 site and report what you find. The diversity of Drupal sites in the wild is staggering - to get the upgrade path nailed down and fully supported in Drupal 8.1, we need a wide variety of sites to go through it.

Nov 20 2015
Nov 20

Every drupaler’s heart was beating faster yesterday. Expectation, excitement, and absolute joy! Yes, it finally happened! Drupal 8.0.0 was officially released yesterday! Did we celebrate it? You bet we did! InternetDevels Drupal development company threw not just one, but 3 parties in different Ukrainian cities to honor the latest and coolest version of our favourite site-building platform. So let us tell you a tale of three cities...and of three awesome cakes as well. Here we go! Get ready for the “tasty” story :)

Drupal 8 release party in Lutsk: the sword of honor!

Our story begins in the city of Lutsk because it’s the heart office… well, head office of InternetDevels, at least :) Our colleagues and guests from other cities couldn’t wait to hear the amazing “Drupal 8 module development” report given by our CEO Pavel Makhrinsky and our top Drupal developer Sergiy Scripchuk. That was really something new to learn! After the report, everyone had a friendly chat, as well as some yummy treats.

The awesome Druplicon cake was quietly standing on the table attracting everyone’s attention and making their mouths water. And finally the cake’s time came! A knife is not good enough to cut such a masterpiece. So our CEO used his souvenir sword for that purpose. A thrilling and fascinating scene! Hurray to Drupal 8!

Drupal 8 release party by InternetDevels in Lutsk

Drupal 8 release party by InternetDevels in Lutsk

Drupal 8 release party by InternetDevels in Lutsk

Drupal 8 release party by InternetDevels in Lutsk

Drupal 8 release party by InternetDevels in Lutsk

Drupal 8 release party by InternetDevels in Lutsk

Drupal 8 release party by InternetDevels in Lutsk

Drupal 8 release party in Rivne: the “warm blanket” of friendliness

The first epithets people give about the Drupal 8 release party in the city of Rivne is “friendly” and “homelike”. You felt like you were wrapped in a warm blanket wearing cosy slippers. This atmosphere helped everyone get closer to each other...and understand Drupal 8 better.

Two reports were given by top developers of our Rivne office. Yuriy Petryk shared his ideas on “Symfony 2 components in Drupal 8”. Oleg Vegera and Roman Khimin told the audience about “What is new in Drupal 8”. Great stuff to listen to!

All work and no play is not a drupaler’s way :) So we also had chats, treats, beer, and gifts. Who got those cute 3D Druplicons? The winners were determined by the draw. And the Rivne cake was amazing as well!

Drupal 8 release party by InternetDevels in Rivne

Drupal 8 release party by InternetDevels in Rivne

Drupal 8 release party by InternetDevels in Rivne

Drupal 8 release party by InternetDevels in Rivne

Drupal 8 release party by InternetDevels in Rivne

Drupal 8 release party in Lviv: full drupalization drives inspiration!

Our Lviv office experts, as well as guests from other cities and from abroad, had a really awesome time celebrating the Drupal 8 release. It all began with the report of our top developer Ivan Tibezh. “Switching to Drupal 8. Comparing the code” was something worth hearing about. The audience was really active with their questions.

What else is necessary for full drupalization? Just like in the other cities, we had the beautiful and delicious Drupal 8 cake, cute Druplicon gifts, and a lot of fun. But that wasn’t all! A live band played covers of famous songs, and there was a special beerpong game all the guests enjoyed. Did you think it was just a game for boys? Guess again! The beauties from the sales department of our Lviv office were the winners! :)

Drupal 8 release party by InternetDevels in Lviv

Drupal 8 release party by InternetDevels in Lviv

Drupal 8 release party by InternetDevels in Lviv

Drupal 8 release party by InternetDevels in Lviv

Drupal 8 release party by InternetDevels in Lviv

Drupal 8 release party by InternetDevels in Lviv

That’s the end our party story. But everything is just beginning for Drupal 8! If you want to know more about how to build a site with it, read blog posts by our developers like this or this and follow our next publications. If you want someone to build an amazing Drupal 8 website for you, upgrade your existing one or add new features, don’t hesitate to hire us. Drupal 8 has come! Let’s celebrate it and enjoy the amazing innovations it has to offer!

Nov 20 2015
Nov 20

Photo Large website projects involving multiple people in different roles face special challenges. The work needs to be coordinated and scheduled in such a way as to allow for parallel development of different parts of the project on different systems. As a consequence, sooner or later the different parts of the whole must be brought back together and integrated into the project’s main development trunk. Often, this process happens seamlessly; at other times, overlapping changes must be integrated manually.

In a Drupal 8 project, the Configuration Management module allows the website configuration files to be stored in a Git repository alongside the project code. As an added bonus, Git also provides features that facilitate distributed development, allowing work to be done on branches and merged together as required. When there are conflicts, external tools are available to visually present the conflicts to the user, making it easier to determine what happened in each instance.

Recently, the Drush project introduced a new command, config-merge, that streamlines the tasks needed to manage the configuration workflow steps to fetch and merge changes from a remote Drupal site.


Image A shows a typical workflow for using Git to manage configuration changes between a local development server and a remote staging server. Releases are deployed to the staging server by first committing them to the master branch in Git, and then making a tag – <T1> in the diagram above – to keep track of what was deployed. Both code and configuration files are stored in Git. The deployment process on the staging server involves first checking out the tag being deployed and then running updatedb and config-import. Later, if configuration changes [a] and [b] are made on the staging server at the same time the developer is making configuration changes [u] and [v], these changes will need to be merged. This could, of course, be done manually, by running config-export on both the staging and development server, committing them each on their own branch, and then using git fetch followed by git merge to combine them together into commit (M) on the development machine. Doing this all takes quite a few steps, though, particularly if using the configuration management admin interface in a web browser to export and download the configuration files. All of this can happen much more quickly with the Drush config-merge command.

Drush's config-merge tool is a lot like drush sql-sync, which has saved Drupal developers countless hours by combining the sql-dump, rsync, and sql-import operations to move a database from one Drupal site to another. config-merge operates on the same principles, except that it uses config-export, git fetch and git merge, and config-import instead. To merge configuration from a Drupal site @dev with the configuration from a remote site @stage using Git, run:

drush @dev config-merge @stage –git

If there are no conflicts, then you will find the merged configuration imported on your development site; you are then ready to test it and deploy the combined changes back to the staging server. If there are conflicts, though, then config-merge will launch a three-way merge tool and allow you to manually resolve the differences.

A three-way merge is so named because it works with three distinct revisions of each conflict:

  • The revision that came from our repository, called "local" or "ours";
  • The revision that came from the other repository, called "remote" or "theirs";
  • The original state of the text, prior to either change being applied, called “base”.

All three of these revisions are shown together, side-by-side-by-side, and controls are provided to allow the user to select which changes to keep and which to discard. Usually, the user is also supplied with an editable fourth pane, where the final state of the file is shown, post-merge. In some cases, the final desired state requires that the "ours" and "theirs" revisions be combined or reordered in some way. In this event, the user may edit the text manually to fill in any gaps that the tool could not derive automatically.

Image B shows a screenshot of kdiff3, one popular three-way merge tool available for Linux and Mac OS.


It offers an example of where two different users have changed the same property – in this case, the region that the search block is displayed in. In the first of the three columns at the top, labeled the “Base” revision, we can see that the search block was originally in the sidebar_first region. On the local system, shown in the middle column, it was moved to the header region; at the same time, someone else moved search block to the sidebar_second region. A block cannot be placed in more than one region at once, so we are going to have to choose one value to keep. Kdiff3 provides three buttons, labeled “A”, “B”, and “C”, that can be used to select the text from the base, local, or remote revision, respectively, and copy it into the output pane on the bottom of the window.

This is just the beginning of what you can do with config-merge and kdiff3. For more details, see the Pantheon Systems GitHub repository, Drush Configuration Workflow.

This repository contains documentation that describes the workflow discussed here in greater depth, and also contains another workflow based on rsync, for use in instances where configuration changes are being made on a system that does not have access to commit to the central repository. There is even a handy quickstart script to help you get up and running quickly, should you not happen to have multiple copies of a Drupal site to work with.

With a little investment in time, you’ll be using config-merge like a champ. In the long run, the time you save will astound you.

Image: "spot the differences" by Giulia van Pelt is licensed under CC BY-NC-ND 2.0

Nov 20 2015
Nov 20

DrupalCon Chicago was the birthplace of Drupal 8 in 2011. Drupal founder Dries Buytaert created the Drupal 8 development branch in front of a crowd during his State of Drupal address at the Chicago conference. 

That's right, Drupal 8 was born in the City of the Big Shoulders, that Midwestern metropolis where monsters roam the midway, hot dogs never come with ketchup and office towers scrape the sky. Back in 2011, Chicago was host to DrupalCon and Dries was giving his State of Drupal address to a crowd of more than 2,000 attendees. It was during this address that Dries created the development branch for Drupal 8 and the future of the Drupal project started to take shape.

We created the Drupal 8 branch live at DrupalCon. Screenshot attached. /cc @sboyer #drupalchi #drupalcon

— Dries Buytaert (@Dries) March 10, 2011


Dries creating the development branch for Drupal 8 in Chicago, 2011. Photo credit: Ariane Khachatourians

It's amazing to think how much has changed about the web since those humble origins four years ago. Dries had the following guidelines laid out in his head before he went ahead and created the Drupal 8 branch:

- The HTML5 initiative

- Mobile responsiveness

- Configuration management

- Web services API

The realization of all these features (and a couple hundred more) in the new version of Drupal started from a bold declaration for the future of the platform; Drupal wasn't going to scale down, rather it would scale up and continue to grow into an even more sophisticated content management system. The focus on accessibility, multi-language support and interopability sets Drupal apart from other CMSes because it makes it an even more attractive platform for large, enterprise-like web applications.

Chicago was a fitting point of origin for this declaration that Drupal would continue to grow bigger and better. Chicago's Drupal community gathered to celebrate the official release of Drupal 8 on November 19, 2015 and there was some appropriate comparison to the robust architecture surrounding revelers in downtown Chicago. The first modern skyscraper with a steel skeleton was built just a few blocks from where Dries wrote the first lines of code for Drupal 8. That's a bold example to follow and there's no doubt that Drupal 8 will continue to stretch the limits of what's possible for a CMS, growing larger and larger over time and supporting even more complex web applications than it already does today.

The Drupal community should be proud of what it's done in the intervening years to contribute to Drupal 8's release. Chicago's Drupal community was responsible for more than 600 contributions to D8 core that came from individuals, companies and universities. With such an active and passionate community behind it, the sky's the limit for Drupal 8.

chicago drupal8 contribution stats.jpg

A snapshot of contributions to Drupal 8 from Chicago's Drupal community

Nov 20 2015
Nov 20

On November 13th and 14th in New York City, several hundred people gathered to talk about the problems of an online economy reliant on monopoly, extraction, and surveillance— and discuss how to build a "cooperative Internet, built of platforms owned and governed by the people who rely on them."

My experience at the Platform Cooperativism summit was Wow, everyone here really gets it and so many are doing awesome things; and then Hmm, there are still some really important differences to be worked out; and then We'll have to continue for months to figure out strategy for building fair platforms and we also need to restructure the whole economy.

Some definitions

In the sense technologists use it a platform is, like a physical platform, a technology that holds a lot of people up. It convenes people and gives them a chance to do something they wouldn't otherwise be able to do. Platforms can often be natural monopolies due to capturing the benefits of network effects (one person with a telephone is pointless, having nearly everyone available by telephone is incredibly valuable). Amazon and eBay are both platforms for sellers and buyers, Uber and Lyft for drivers and riders, Mechanical Turk and TaskRabbit for piece-workers and buyers of their work.

A cooperative is a jointly owned and democratically-controlled enterprise formed by people voluntarily uniting to meet their common needs and aspirations. Agaric is a small worker-owned cooperative, Mondragon is a very large group of integrated worker cooperatives, consumer cooperatives are businesses owned by their customers, credit unions are financial institutions owned by their members (with a one person, one vote governance), and producer cooperatives like CROPP Cooperative are formed by member businesses (which are not necessarily cooperatives themselves).

A platform cooperative, then, is a platform owned and controlled by the people directly affected by it. A company must be accountable, and as Omar Freilla put it, accountable means those impacted make the decisions.

The power to do harm

This summit was a follow-up to the Digital Labor summit held one year before which detailed myriad ways centralized online platforms extract value from dispersed workers who have few options or bargaining power. Control of online platforms by the representatives of capital has or will have negative effects on workers, similar to exploitation in global manufacturing (think electronic devices and clothing), and negative effects on customers (think the massive money grab by oligopolies of fossil fuel and telecommunications corporations).

Agaric's Michele Metts told the Digital Labor summit organizers every chance she got that cooperatives and Free Software were the answer to exploited labor in the Internet economy, but something even more powerful than Micky's advocacy must have been at work: nearly every participant at Platform Cooperativism spoke of the need for workers to own the platforms that control their work, and people presenting on technology took for granted that source code and algorithms have to be open for democratic control to be meaningful. As Micky said on her panel, "You cannot build a platform for freedom on someone else's slavery."

The opening presentations made the case that platforms will exploit us unless we take control, and we moved on to discussing strategies for building platform businesses that are cooperatives of the people using the platforms. We also celebrated those already starting, like Loconomics, Fairmondo (in Germany), and Member's Media.

Building for shared power and uplift

The biggest unsolved, but acknowledged, problem is getting the resources to build platforms that can compete with venture capital-funded platforms. Dmytri Kleiner made the claim that profit requires centralization, and, moreover, that centralization requires organizing along the lines of a profit-taking venture. How can people get the resources to build without both having to give up control and having to exploit people using the platform? Robin Chase reminded us that it costs millions of dollars, at least, to build a viable platform. Her solution is to continue to seek venture capital and work for some environmental or community goals while compromising on control.

A more popular possible solution is to replace centralized systems with decentralized ones, even to the point of replacing specific software with protocols, so the cost of building and operating platforms can be more widely shared, along with the benefits. However, as Astra Taylor summed up the widely felt point, decentralization does not always mean distributed power. Therefore control of technology decisions, and so democratic control of platforms, is more important than technology itself.

The potential positive role for government regulation was often mentioned, as Sarah Ann Lewis summarized the sentiment in a tweet: Platforms are not special snowflakes that must be exempt from regulation. If you can only succeed by exploitation you deserve to melt. Indeed, the centralized and surveillance nature of most platforms would make it much easier to ensure non-discrimination and fair wages.

More excitement came from the mention that local government has long played a role and can play a stronger part in democratic ownership of physical spaces. Several speakers urged people to get involved in local government, where harmful policies may be more the result of a lack of knowledge than of embedded corruption. Government can also get involved in mandating an open API for ride hailing services, which would remove the monopoly power from centralizing companies.

On ownership and control

Hundreds of possible solutions faced lively questioning and debate, yet in all of this the titular solution, cooperative ownership, did not get the scrutiny it merits. Jessica Gordon Nembhard's Collective Courage has made me see that the connections and overlaps between worker cooperatives and other types of cooperatives are much more significant than I'd thought, but there are still differences. And I'm not sure the differences are made clear by people building platform cooperatives.

If Brianna Wettlaufer refers to it as a multi-stakeholder cooperative and it has been around since 2012 so they've surely worked it out, but this question is at the heart of how platform cooperatives must operate and it was hardly addressed at all.

The answer can be simple. The Black Star Coop brewery and restaurant in Austin, Texas, is owned by its customer-members while the workers manage it. The workers are internally a democracy, but there's no question they work for a businesses which is managed democratically by the customers. This makes even more sense for a quasi-monopoly platform: It's more important for, say, millions of people relying on a platform for livelihood or transportation or communication to own it than for the relatively small number of people who built it to own it.

This brings up another question that went largely unasked at the conference: does ownership mean anything when it's spread out among thousands or millions of people? Federated structures can mitigate this, but in general whoever controls communication among members effectively controls decisions. It may be possible to have horizontal mass communication by way of democratic moderation. At a small workshop I held at the conference, participants discussed ways collective control can be made real as democratic platforms scale—but that's a topic for another discussion.

The sense that displacing an app or website is easier than reconstructing global supply chains fueled a lot of the excitement at the conference. Notwithstanding, the need to restructure the rest of the economy so that it works to serve the needs of people, rather than sacrificing people's needs to the dictates of the economy, was never far from people's minds. Videos of most sessions are online and will certainly make you think about the opportunities for cooperative ownership of services and structures that define our lives, online and off.

Nov 20 2015
Nov 20

Building Drupal 8 with all of you has been a wild ride. I thought it would be fun to take a little end-of-week look back at some of our community's biggest milestones through Twitter. If you can think of others important Tweets, please share them in the comments, and I'll update the post.

Feeling nostalgic? See every single version of Drupal running!

Do you remember how #Drupal 1 looked like? Or Drupal 3? Are you curious? Check out all the Drupals! #Celebr8D8

— Cheppers (@cheppers) November 19, 2015

Here is how we opened the development branch for Drupal 8: live at Drupalcon!

The secretsauce of #drupal isn't code or features or market share, important thought they are. The secret sauce is community.

— Sean Yo (@seanyo) March 10, 2011

@dries branching D8 #drupalcon #drupalchi #drupal

— Jeff Geerling (@geerlingguy) March 10, 2011

Drupal 8's first beta showed the power of community

Drupal 8.0.0 beta 1 released! Ahh the power of COMMUNITY driven software! :-)

— Doug Vann (@dougvann) October 1, 2014

Congrats all on epic work on Drupal 8.0.0 beta1 :) Now go sleep or party as appropriate ;) #drupalhugs

— Gábor Hojtsy (@gaborhojtsy) October 1, 2014

We had issues ... but the queue steadily declined

Today there are zero #Drupal 8 beta blockers! Here's what's next: Of note: finish beta deadline issues by Sept. 28.

— xjm (@xjmdrupal) September 19, 2014

Drupal 8.0.x-rc1 release window is today. Good sign of real stability is major issue count going down for 6+ weeks.

— catch (@catch56) October 7, 2015

We held sprints around the world: here are just a few

EVERY SINGLE #Drupal 8 critical is RTBC or currently being addressed at the 10-person #D8Accelerate London sprint! @DrupalAssoc @brightlemon

— xjm (@xjmdrupal) July 5, 2015

Working on D8 Criticals at the Ghent DA critical sprint, this is how the "My issues" page looks for me right now!

— Sascha Grossenbacher (@berdir) December 13, 2014

Yay for a crowded core office hours sprint! #drupalcon

— Cameron Eagans (@cweagans) March 23, 2012

And we created many game-changing features

#Drupal 8 now ships with page caching enabled! Anon users: <10 ms response time, yet instant updates! #FastByDefault

— Wim Leers (@wimleers) April 8, 2015


— webchick (@webchick) October 22, 2012

Config entities dependencies in action! @swentel @yched goodbye field_system_info_alter()

— Alex Pott (@alexpott) February 15, 2014

With Content + Config Translation in core D8 core is more translatable than D7 with all of contrib. #drupal

— Tobias Stöckler (@tstoeckler) November 18, 2013

Amazing to see Drupal 8's multilingual capabilities explained on the multilingual release page (for example Farsi):

— Gábor Hojtsy (@gaborhojtsy) November 19, 2015

The founder of PHP said: Drupal 8 + PHP7 = a lot of happy people

Here are the two graphs: and - Drupal 8 + PHP 7 will make a lot of people happy!

— Rasmus Lerdorf (@rasmus) April 21, 2015

We reached the first release candidate and celebrated ... a little

Congratulations to EVERYONE in the @drupal community who has worked so damn hard to reach this moment. Celebrate! #drupal8rc #Drupal8

— Whitney Hess (@whitneyhess) October 7, 2015

Just LOOK at it. 8.0.0-rc1 is GREEN Download - Let's build something to celebrate! #drupal8rc #drupal

— Manuel Garcia (@drupalero) October 7, 2015

Kudos to the 3000+ contributors and to the entire Drupal community that helped make this happen.

— Leslie Glynn (@leslieglynn) October 7, 2015

And, just yesterday, we painted the world blue and celebrated Drupal 8 ... a lot!

Let's paint the whole world blue! Add your #Celebr8D8 Release Party here #Drupal8

— Drupal (@drupal) November 10, 2015

With over 200 new features & improvements #Drupal8 is released! Thanks to all contributors!

— Drupal (@drupal) November 19, 2015

At the Amsterdam #Drupal8 release party!! #Celebr8D8

— Taco Potze? (@tacopotze) November 19, 2015

The Moment We've All Been Waiting For: Drupal 8 is Here! #Celebr8D8!

— Duo (@DuoConsulting) November 19, 2015

#Drupal8 release party in #Lahore #Pakistan with @JibranIjaz @NaveedSukhera #Celebr8D8

— Shakeel Tariq (@shakeeltariq) November 19, 2015

From Peru we're celebrating the new era #Drupal #Drupal8 #Celebr8D8 @Dries

— Agustin Rojas Silva (@Aguztinrs) November 19, 2015

Happy #Drupal 8, everyone! I am so happy to know and work with all of you beautiful #opensource people!

— HornCologne (@HornCologne) November 19, 2015

Karma party in #drupal-contribute #Celebr8D8

— webchick (@webchick) November 19, 2015

We're literally printing money here. @Dries Dollars by @LeakyTweety for #Celebr8D8 Manchester

— Paul Johnson (@pdjohnson) November 19, 2015

Acquia and downtown Boston are ready to celebrate Drupal 8! #Celebr8D8

— Dries Buytaert (@Dries) November 18, 2015

Nov 20 2015
Nov 20

The final Global Training Days of 2015 took place on November 20th and 21st, right after the Drupal 8 release. While many in the community were finishing their celebrating, the trainers were just getting warmed up to introduce people to the world of Drupal. Thirty-nine sites held a training in 21 countries. This included both training companies and local community groups. We could not be more proud of the global representation for the event and we look forward to more success in 2016 with our quarterly DrupalGTD events.

Thanks to Marina of ADCI we made a video to introduce attendees to the community. Trainers were invited to participate and fun was had by everyone.

[embedded content]

As for the spirit of Global Training Days, I think Mauricio of Agaric put it best in this tweet.

Organizing and presenting at #DrupalGTD takes effort, but seeing people smile when they build functional websites in hours makes it worthy.

— Mauricio Dinarte (@dinarcon) November 22, 2015

Check out the photos and updates at #DrupalGTD on Twitter. The full list of participants is on the 2015 page along with reports from the trainers as they come in.

Learn more about the program at or sign up to provide training at the next event.

Nov 20 2015
Nov 20

In Part 1 of this series, I showed an easy system for including oEmbed rich content in a WYSIWYG, including reusing that content. In this installment I'll step through how to set it all up in Drupal 7.

How to Set Up Asset and oEmbed modules

First of all, in order to use Asset module you can't use WYSIWYG module - you need to use CKeditor module. CKeditor module is great though - you have more control of your editor configuration than with WYSIWYG module.

Install Asset module from I typically enable only Asset, Asset document, and Asset image, out of the submodules in the Asset package.

Similar to how Media module works, you need to enable the Asset filter on your input format(s). On the CKeditor settings make sure you enable the Media Asset plugin.

Also add oEmbed module and enable its submodules oEmbed Field oEmbed Embedly. Add an API key to the oEmbed Embedly configuration.

Create a new Asset type (Structure: Asset Types: Add Asset Type) called 'Embed' and pick an icon for it. At 'Manage Fields' add a link field, and at 'Manage Display' choose oEmbed for the display formatter of the link (for both Default and Full Size modes). Go back the CKeditor settings and drag your new button into your WYSIWYG configuration.

If you're having trouble getting an embed link to show up, you may need to adjust the pattern matching for the provider in the oEmbed providers settings. Often the provider has started using www or https in their URL and you need to adjust the patterns to match. Watch out for security settings in CKeditor and in your input format: some of the oEmbed content will comes with Javascript that can get filtered out and change the display. If you need to reduce security filtering, be sure you are only allowing trusted users to use this CKeditor profile.

You may also want to do some templating and styling: I overrode the oembed.tpl.php from oEmbed to not show an extra title link to the embed. I also overrode the asset.tpl.php to likewise not show the Asset title.

OK, but what if I want to add this as a field, rather than in a WYSIWYG?

Media module has a nice ability to be used as a widget for a file field, letting you reuse media from your library or add new media. So how can we get a similar feature using our beloved Asset module library?

Because Asset is an entity type, you can create entity reference fields to reuse assets. A great widget for entity reference fields is Inline Entity Form. This lets you add a new or existing asset of any type as a field. We contributed a patch for Asset to add support for Inline Entity Form, which is in the latest Dev release of Asset module.

Using Inline Entity Form, you can add a new or existing asset as a field.

Adding a new Embed Asset within Inline Entity Form.

Do I have to do this for every new site I make?

Of course not. This is the kind of setup you should do in a starter-kit: an install profile that you use for every site. We've added it to our Bear Starter-kit, which you're welcome to fork.

OK, but what if I use Scald or Media module and can't switch to Asset?

If you're not ready to make the Asset module plunge, you can still use oEmbed. If you like Scald, you can do a similar setup using this Embedly Scald module. And if you use Media module you can use the Media oEmbed submodule (included in oEmbed module).


Stay tuned for Part 3 in which we report on what we've done to make it easy to embed 3rd party content in Drupal 8.

Nov 20 2015
Nov 20

Previously we talked about currencies and stores. This week we’ll focus on products.

Drupal 8 product list.

Before describing the improvements we’ve made, let’s remember the previous implementation.

Commerce 1.x

Commerce 1.x has a flexible but slightly unfriendly product architecture.

Products represent individual purchasable SKUs: a small red t-shirt, a file, a conference ticket. Products can have attributes, which are special fields such as a Size or Color field used to switch between grouped products on the Add to Cart form. Products are grouped together in product display nodes. A product display node is a node that has a product reference field, allowing a “DrupalCon T-Shirt” product display to reference the individual SKUs (combinations of color and size).

Products need to be created individually in their own UI, then referenced from a product display node. This means having to use two different UIs to do what is essentially one operation. Back in 2012 we developed Inline Entity Form, allowing products to be managed directly on the product display form, and used it as a basis of the then new Commerce Kickstart 2.x distribution. It has since become a standard for managing products in Commerce.

Kickstart also tried to relabel the relevant entity types, calling the commerce_product entity type “product variation“ and calling product display nodes “products”. This rename was only skin deep (limited to the UI), and created confusion for documentation writers and readers.

Looking back, what caused the most trouble?

  1. Inline Entity Form

    Not having / requiring Inline Entity Form from the start.

  2. Mixing product and non-product content

    This made it necessary for Kickstart to create separate views for product and non-product content. The same was done for content types.

  3. Different ways of creating attribute fields

    Attribute fields can be any field with an options list, such as taxonomy_term_reference fields (pointing to a vocabulary of terms) or list_string fields. This increases the documentation burden, and creates the question of “which approach to use“. Kickstart standardized on taxonomy_term_reference fields, but at that point it was already obvious that too much choice is not always a good thing.

  4. Data model paper cuts

    Product displays weren’t required (even though most people used them), so there was no canonical way of getting the product’s display. Modules had to reinvent this relationship using EntityFieldQuery. Deleting a product display node didn’t delete the referenced products, since there was no guarantee they weren’t going to be referenced elsewhere. Once again this had to be done in Inline Entity Form.

    Products had required titles, even though attributes were usually displayed instead. Inline Entity Form thus had to offer an option to auto-generate the title, which was sometimes buggy.

Commerce 2.x

In the new architecture, a Product entity references one or more ProductVariation entities. Thus the product entities replace D7 product display nodes (and match the D8 nodes visually) while the variation entities replace D7 product entities. Each product type has a matching product variation type. A product always references variations of the same type.

Variations are only manageable from the parent product, using Inline Entity Form, which is now a Commerce dependency. Variation titles are also no longer stored. They are dynamically constructed from the attribute labels instead, so there’s no more need for auto generation on insert. Deleting a product deletes its variations. Adding a variation to a product automatically creates a backreference on the variation, accessed via $variation->getProduct().

Drupal 8 taxonomy list.

Attributes are now entity reference fields. Referencing entities such as terms allows the usage of fields to hold things such as the image representation of the attribute, the color value for a color swatch, etc.

But what happens if a variation type has no attributes? For example, a product is only selling a single file. In that case, the Inline Entity Form widget will render the variation form as a regular fieldset on the product. This piece is still in progress but will be ready for the alpha release.

Custom product architectures

When it comes to product architectures, there is no one true answer. Furthermore, different clients might have different needs. That’s why it’s important for Commerce 2.x to support any number of product architectures.

The ProductVariation entity class implements the PurchasableEntityInterface:

Code snippet of the PurchasableEntityInterface.

Any content entity type that implements this interface can be purchased. The order module doesn’t depend on the product module, the product module just provides the default (and most common) product architecture. A product bundle module will probably want to define its own product architecture, etc.

Line items have a purchased_entity reference field. The target_type of that reference field is different for each line item type.

Drupal 8 line item type form.

Here the line item type points to the product variation entity type, indicating that the "Product variation" line item type is used to purchase product variations.

Early in the Commerce 2.x cycle we explored the idea of hierarchical products, but after initial exploration found out that the idea required several months of extra effort (having to rewrite the Tree module, reinvent an IEF like widget, UX and performance considerations). We removed it from the roadmap with a heavy heart, but now that Commerce 2.x supports custom product architectures, we can easily explore the idea in contrib at a later date.


Commerce 2.x ships with much better UX out of the box, thanks to a revamped product architecture. It also features under the hood improvements that allow developers to implement custom product architectures for different use cases.

Nov 20 2015
Nov 20

Today marks the release of Drupal 8, and the birthday of its founder, Dries Buytaert. This release is more than just a new digit, it's an entirely new platform with something for everyone to love, but it's particularly big for web site owners.

What's the big deal? The biggest, most powerful, one of the most successful open source projects in the world has two major, fundamental changes that change everything you thought you knew about it.

Well, not everything. Lots of the things that people love about Drupal are getting some nice improvements:

  • Mobile, responsive support straight out of the box -- it's actually a nice experience administering a D8 site on your phone!
  • The information architecture is the same as always -- content types, vocabularies, comments, anything you've learned about how content is organized in Drupal is the same, but...
  • Lots of powerful modules like Views and CKEditor are now in core, and much less quirky than ever before
  • Deploying updates and configuration settings between multiple copies of the site is completely overhauled, and now very simple to do
  • Caching support is baked in, enabled by default, so in spite of doubling in code size it uses less computing resources and responds much faster, especially on busy sites
  • Loads of other improvements.

All of that is great, and we could go on for hours, days about how much of an improvement this is. And that is the stuff you will notice today, next week, next month. But that's not the big change, that's not the killer feature of this upgrade for site owners.

The killer feature is what happens in 6 months, in 1 year, in 5 years. And that is, the great big upgrade cost you don't have, when it's time to upgrade to 8.1.0, or 8.2.0, or even 9.0.0.

Two Fundamental Changes.

Ask any Drupal site owner where their biggest pain is. You'll run into two big complaints: How hard it is to find decent Drupal developer talent, and how painful it is to migrate to the next version. Those both change with Drupal 8.

The next version

The current version of Drupal 7 is 7.41. The new version of Drupal 8 is 8.0.0. The next version of Drupal 7 will be 7.42. The next version of Drupal 8 will be 8.0.1. Notice anything different? It's called "Semantic versioning," and yes, it's just one more number between the dots (or added to the end). But the change behind that simple little version number is enormous.

Drupal is changing its entire release process to have "minor" version releases every 6 months. That means 6 months from now will be 8.1.0, and in a year, 8.2.0. These are calendar-based releases that contain new functionality, AND maintain backwards compatibility with the previous minor version. Upgrades from 8.0.4 to 8.1.0 should be completely transparent, nothing breaking as a result -- but new stuff available.

Drupal has never maintained backwards compatibility like this before -- this is a fundamental change in the project, and it represents the maturity the platform has reached.

There will only be a Drupal 9 when there's enough changes that are not backwards compatible that it's time for a new major release. But this "minor release" plan provides plenty of notice of functionality being deprecated to allow people to transition away from those things that are going away, long before 9 arrives.

That means an update to Drupal 9, will mostly be a matter of making sure you've either moved away from stuff being changed in Drupal 8, or have added an alternative. And then update, potentially like any other minor release.

No more completely rebuilding your site in the new version! For the first time ever, major version updates in Drupal should be relatively painless, as long as you keep your site relatively current and pay attention to changes as they develop.

"Drupal Developers"

Drupal has always come with a steep learning curve, particularly for developers. This is because it has developed out of procedural code, with a "hook" system and naming conventions that make a lot of things happen "automagically". It takes a couple years to get your head around the many Drupalisms, code patterns, hooks, conventions that are not seen or used in most other projects. You need to be very proficient in coding, using a debugger, and having an open mind to be a good Drupal developer... until now.

"Object Oriented" is a term that came in vogue in development circles... in the 1960s. It became the dominant way of programming in the 1990s, particularly with the rise of Java in popularity, and it's at the heart of .NET as well as many open source practices. And while Drupal uses a lot of object-oriented concepts in its information architecture, it has never been fully object-oriented in its code... until Drupal 8.

Why should a site owner care about this? Two huge benefits -- the same two I'm talking about here:

  • Drupal development now shares the same programming architecture as 90% of the rest of the industry, instead of being its own thing. Now you don't need to find a good "Drupal developer" -- a good developer should be able to pick it up and figure it out without years of learning the specific incantations and magic charms of all those Drupalisms.
  • Updates. Because we now encapsulate all this code into objects that extend other classes, this allows for upgrading smaller bits of functionality without affecting the rest of the site. This means that it should be possible to upgrade some modules to Drupal 9, before the site itself.

I think a lot of people in the Drupal community don't fully realize how huge a change this is (and it is interesting to see some backlash to the changes from those who may fear some of this change).

In other words, when Drupal 9 eventually arrives, it won't be such a big deal -- it should be possible to run exactly the same contributed modules for Drupal 8 and Drupal 9, with no changes whatsoever -- and even if something important does need to change, it can be changed by inserting a "shim" class that translates the API changes as appropriate -- it will almost certainly be possible to run Drupal 9 modules in Drupal 8, and vice versa. And you won't have to find a Drupal-specific developer to do this for you, either.

The new world of web applications

Drupal has long been a compelling platform in terms of functionality, the speed that new functionality becomes available, and the power built into the system. Drupal 8 is not just another release -- it is the maturing of this platform into something that is completely up-to-date and capable of staying that way for at least the next decade, if not more.

If you are looking for a new content management system, a new project management system, a new platform for managing all kinds of communications between groups of people, you can't pick a better base for doing so than Drupal 8. Give us a call, and let's discuss what you want to build!

Nov 20 2015
Nov 20
More a log than a guide, but you get the idea! its a lengthy log this week, a lot got undone, done and then some. Backlog for the week:
  • Fonts
  • Contact Form (customise it)
  • Translations (Lingotek)  
  • Take the site online 
  • Toy around with Drush
Not part of the backlog, decided to update core, followed the instructions to the letter, used Drush and broke the site completely! ha! ‘A little learning is a dangerous thing; drink deep, or taste not the Pierian spring’ … and yes did not back it up did see Drush had created a back up but have failed to locate it! was going to take it online anyhow, so decided to rebuild on Acquia CloudSite folder on DT02

Site folder on DT02

Would be interesting to see how long it takes to rebuild it! good organisation should make the task a tad bit easier! 
Revisions made to node/1 were not in the .txt file, extracted them from node_revision_body from the database (a little learning can be a useful thing too) – a small win on a rough day!
  • Logged into Acquia Cloud, spun up a free subscription, installed D8.rc3, and got cracking! 
  • Only downer is can’t add contrib modules without figuring out how to SFTP, or using Drush. For now staying clear of Drush! fear of the terminal is back!
  • Set up path aliases, was a quick and easy introduction and gets rid of the node/n in the address bar, of course good for SEO and all that jazz.
  • I know there is an easier way to justify text alignment via CSS but that’s going to take some time to get to grips with so taking the long but short cut with HTML to <p style=”text-align:justify”>.
  • It was a good day, a forced refresher on getting sh*t done and it took less than 2 hours to get the site back on track a little ahead of the previous version too! wooHoo! 
  • Tested the contact form but it won’t work, a bit of digging around and seems SMTP Authentication Support needs to be installed, am after a quick win today, decided to install and toy with Lingotek instead.
  • Dang it! can not upload to Acquia Dev Cloud, dug around, need SFTP or SSH access, ok set up my SSH Public Key, downloaded FileZilla, followed the instructions and nada! time to put the fear of thescreen-grab-lingotek


    terminal behind me (again) bounced around from page to page but finally got in WooHoo! installed LingoTek in the wrong place Blistering Barnacles!
  • Tried to uninstall LingoTek, could not (commands I’m seeing online don’t work for me), Ok so the next best thing is to install LingoTek in the Dev folder but nothing in the sites folder! Bizarre! or may be not!
  • Anyway reading up on Drush and installing modules on Acquia Cloud and WTF! there is aenable live dev

    enable live dev

    simpler way to do so! Why is this nugget buried so deep! Evidently all I needs to do is go to my Sites/Cloud and ‘Enable Live Development‘ 
  • That done time to check out LingoTek, copy link address, install, enable, wait, enable dependencies, enable job done! Lingotek Translation itself, lemon squeezy!

LIngo Tek grab 04

LIngo Tek grab 04

  • Ending day 2 on a colossal WIN, I have translations for basic pages and articles in Arabic, Bulgarian, French, Hindi, Spanish and Urdu, the main and footer menus are not translated as yet, neither do I have language select buttons/icons enabled, to access the languages I have to go by the language code in the URL and its not perfect I still need our Peace Through Prosperity volunteers to check and edit  multilingual content but they’ll  have less to do. LingoTek kicks ass!
  • Time to take on the font challenge!
  • Noticed whilst on my local environment I was having problems installing modules, kept getting error messages that told me nothing other than it’s an error (FFS!), however haven’t been getting many of those on the Cloud.
  • AnyHoo, for fonts decided on Google Webfont Loader API, comes highly recommended by @Dakku and has a D8 recommended release out too, so what could go wrong. Installed, enabling took ages and it works but… there are only two font added to the library of fonts  (not exactly a library!), all a bit anti-climatic!
  • Not quite what I expected, font attempt five or is it six now is a fail! uninstalled the Google Webfoot Loader API and am going to start exploring the CSS route one of these days. 
  • Its Menu translation day – why hasn’t LingoTek got an automated workflow for menu item translations? got it done but what a pain! suggested improvement for LingoTek: have multiple language translations for a menu item on the same page please! a lot of unnecessary back and forth in the workflow.
  • Decided to spend time on CSS so that I need not rely on modules to change fonts and to get the menu translations in place between day 4 and 5, SMTP set up and the contact form will have to wait its seems a bit complicated and will need help on this in the know, as a starter have bookmarked CSS architecture (for Drupal 8) and Drupal 8 Theming Fundamentals to my reading list.
Its a big day, the WIP site gets opened up for demo on the blog!  Retro time!
  • Fonts – tackled again, failed, avoided (need dragon glass to tackle this one)
  • Contact Form (customise it)
  • Translations (Lingotek)
  • Take the site online
  • Toy around with Drush
  • Backlog grooming
..and disaster strikes! somehow managed to lock myself out! can’t recall the password! dang it! it was such an awesome run! need help on this, tried SSH, can SSH but getting access denied for getting DB backups and hesitant to do too much using Drush, remember day 1’s lesson well. Added @Dakku to the Site ’Team’ on Acquia Cloud and its all good.  Week three has been an epic adventure! am clearly trying to run before I can walk but am finding the platform is coaxing me to do so! what little surface I have scratched has opened up a whole bunch of stuff to add to the open social backlog and am getting pretty confident quite a bit of it could be handled by myself! yes humility is a must have EM trait!. Week four will start with an upgrade to Drupal 8.0.0 WooHoo…! in the mean time feast on this… seven languages! Open Social Transformation PTP03

Open Social Transformation PTP03