Mar 03 2015
Mar 03

I gave a talk at Drupal Camp London this year, focusing on the UX of CMS users a.k.a the forgottten Drupal user. Below are the slides and a few notes to accompany them.

Things to consider

When creating a new site user experience is usually focused on the end users, their goals and tasks. This is evident from the vast popularity of the topic as well as the number of software and tools available to aid this purpose (such as eye tracking software, user testing labs etc). Often CMS users are left with only the basic tools to manage their site. A few simple modifications and modules can be used to make their job quicker and easier.

The first thing to consider is who will be using the site. Are they a single user, a group of people, do they work alone or as part of a team. This will affect how the site is used and interactions should be accounted for.

The next step is what. What do they need to achieve on a daily, weekly or monthly basis? What do they want to get out of the site? Tasks that need to be performed frequently should be the easiest or else they simply won’t be done as often as they should, or even worse, at all.

The third thing to consider is the priority of the site to the user(s). If managing or using the site is only a small part of their role it’s more likely to be neglected if tasks are difficult to accomplish. On the other hand if the website is their only task and it’s difficult to use they’ll dread each time they’ll need to log in.

Theme and navigation

My personal go-to theme is Adminimal, giving users a cleaner, clearer experience with subtle changes across the site such as colouring buttons, highlighting tables and making important text stand out more. Check out the theme for yourself here:

Replacing Drupals core toolbar with Navbar is an infinite improvement. Responsive out of the box it allows navigation on tablets and mobiles to be a breeze meaning that updating configuration or content whilst away from a desk is more likely to be done.

Content Management

The most basic need to CMS users is to manage their content overview page. Admin views makes use of views and vbo to override the default overview to allow filtering/searching and retain the mass action functionality. Being a view it’s easily configured to suit the needs of the person/company. As a bonus it also overrides the overview pages of comments and people.

Another option is Workbench. A better (imo) version of the core dashboard screen it provides configurable views on a summary page. The views can be modified or removed/added to using the available workbench hooks.

With the addition of Workbench Moderation content can be revisioned and placed in various states before being published. States and transitions can be modified and it’s all based on permissions and roles meaning you can have as much or as little power as you need. The CMS user will be able to see clearly what state content is at and modify it easily by viewing the content itself or the overview page.


Webform is a widely used module and there’s a few additional modules that allow you to extend it further.

Default fields allows you to set up default fields per webform enabled content type, meaning that a CMS user doesn’t need to create needed fields each time – perfect for event or other sign up forms.

Options element makes creating select lists easier, stripping the need to enter keys and separating out each option into its own text field.

A spam filter, such as honeypot, saves the user time having to delete any results that would otherwise clog up the system. There are of course other options for helping with spam, honeypot is simply my preferred choice.

Using hook_webform_select_options_info the default select lists available can be added to, including any taxonomies on the site.

File Management

This is one area Drupal has always struggled with. Adding the media module means you can reuse files that have been uploaded elsewhere around the site. An overview page is added allowing users to mass delete media as needed as well as bulk upload files. It's by no means perfect, but it's a great step forward for file management in Drupal.


Entering content can be a time consuming task, a few tips to help users out.

Select lists

With select lists there are a wide range of options, I've written about a few of my favourites before, below is a short summary of each.

Multiselect changes the standard dropdown into two boxes, with selected options appearing on the right. Options can be moved by double clicking or by selecting and clicking the arrow button(s).

Term reference tree has a butt load of options, including being able to force the user to only select child elements, select parents automatically when child terms are selected. This works fantastically for nested trees.

Select with style gives a visual edge to select lists, and can include custom images and css.

Simple hierarchical select There are fewer options available, but allows users the option to create new terms as well as force selection of only child terms. 


As well as using media a couple of additional ways of helping users is allowing them to crop images after they’ve been uploaded. A good comparison list can be seen online. Focal point provides a way for you to change the automatic focus of Drupals core cropping. Uploading multiple images at once is also a great time saver and can be done with an imagefield widget.

Other fields

A few additional options including setting up conditional fields. This allows the user to only see the fields they need to, making forms look cleaner.

Gmap allows the user to pick co-ords from a map, using for geo-location modules.

Linkit is great for linking to internal content, allowing the user to search for content on the site.

One of the most basic things you can do is include help text! Clearly informing the user what content you expect them to enter and how can save a great deal of headaches later on.

Additional modules and tips

A few others shared modules and tips they had for improving the experience of CMS users.

Paragraphs allows users to create blocks of content, selecting types of content along the way.

Beautytips moves help descriptions into mouse overs helping to make forms look cleaner.

Field groups allows you to place forms in collapsible groups that can be hidden and shown as needed, meaning you can initially hide fields that are infrequently changed.

A similar session covered this topic before, Tasty Backend had other tips on improving the lives of CMS users with an excellent write-up by Vicky Teinaki.

The end bit

I'd like to thank those that came and the people that tweeted nice things. If you have any experience, help or advice to share please do! Until next time.

Mar 02 2015
Mar 02

For cause-driven organizations, a website is a place to highlight impact, share resources, and build support. While a blog or brochure site can achieve some of these goals, it rarely does it all. Unfortunately, we all too often find organizations confined by the free and low-cost online platforms accessible to them. With that in mind, we’ve built OpenAid. It’s a free and open-source website starter kit developed for nonprofits and grassroots organizations. Its feature set is robust, its architecture flexible, and it can be installed in minutes.

We worked with activists, community organizers, and aid workers to build a platform that serves their organizations’ needs. Here are some of the features we’ve built to allow groups to inspire and connect with others on a scale that truly reflects their impact in the world.

  • Project mapping. Each project or program you add to the site is displayed on dynamic maps, allowing users to see the full scope of your work. Because OpenAid is flexible, you can easily adjust a project to instead be a city or chapter and still take advantage of all of the mapping features.
  • Blog and news. There are subtle but important differences between a News section and a blog, so we decided to build both for ultimate flexibility. Associate authors with your posts to create dynamic profile pages and allow users to track their favorite writer’s work. Reference a project with a post and it will display on a project’s page, creating almost a mini website for that project.
  • Resource library. Share the resources you’ve created with the rest of the world in an easy-to-find way. We’ve added metadata fields such as Resource Type and Topics and provided a filter set and search interface to allow users to quickly discover the tools and materials relevant to them, even if your library has grown to hundreds of documents.
  • Image galleries. Pictures are key to telling your stories and connecting with your supporters. Associate a gallery with one or more projects to highlight events, volunteers, and initiatives specific to that project’s work.
  • Beautiful, responsive design. Design is important and we want your website to look great regardless of device. A color picker allows you to easily adapt OpenAid to reflect your organization’s identity. We’ve also developed it with flexibility in mind so if you add new pages to the site or add fields to a content type, your site will retain that same great look and feel.

You can dig further into OpenAid’s feature set by spinning up a free sandbox site on Pantheon. Or download the distribution at to install on any server. If you have further questions or would like assistance getting set up with OpenAid, feel free to reach out to me at [email protected].

Mar 02 2015
Mar 02

Last week was awesome, sort of. I hit all the numbers on my guide launch I was hoping for, and then promptly got the stomach flu. After two years (lots of running in circles) of working through this process of launching I did it!

Now it could have just been being sick, but I ended the launch wanting something more. And the reality is this isn't the first time I've been down after a success.

Does that ever happen to you? You get so excited about something and launch it? Then the next day you wonder if you could have done better, or you aren't sure where to go next. It's happened with our clients, we work so hard, we push the code, we launch on time, and then the question of "Now what?" lingers.

So since I have been applying pragmatism to all sorts of problems, here is my solution to dealing with the post launch lows.

Take a little bit of time making your post-launch strategy, preferably before the launch. Having a place to land your feet is critical to keeping the momentum that comes with a deadline and a launch.

In web there's a lot of ways you can handle this, retainers, maintenance plans, continuous integration testing and plans. Whatever works for your client's needs, but whatever you do, don't leave them hanging.

Sure party, sleep, take a break and enjoy the moment of the launch. But know what comes next, what is the content creation pattern, the maintenance schedule, what tests do we run in the future etc. I have a full IceBox list to pull from, but having to dos setup specifically for the day after would have helped make today easier.

The things to make your list should cut down future relaunching costs, and make it easier for you to maintain clients, and for them to maintain their value to their customers and users. The bonus of this is with retainers and continuous integration plans, you are able to keep some cashflow coming in and not be so in trouble with big projects fade away. Planning for the post-launch is definitely going to a part of any consulting that we offer in the future.

Like all good plans it takes some prior planning and setup work to do it well. Do you have post-launch plans for your clients? What do they look like?

Mar 02 2015
Mar 02

This year in Los Angeles, the Higher Ed Summit will be part of the official DrupalCon program for the first time. Along with the Business and Community Summits, the Higher Ed Summit will meet on Monday, May 11.

Drupal summits for higher education, and education in general, are not new. Around 170 of us from 51 colleges and universities gathered for a pre-DrupalCon summit last year at the University of Texas at Austin. We also met for an Education Unconference back in 2012 before DrupalCon Denver. These summits are mainstays at some of the larger DrupalCamps too, such as BADCamp and NYC Camp. Format

We will start with a panel presentation and learn how some of our peers are using Drupal at their institutions. We’ll then break off into small group discussions for the rest of the day. Discussion topics will be decided as the Summit approaches, but will likely include tips for training content editors, managing campus-wide Drupal installations, and maintaining brand consistency across sites. There will also be ample time for BoF-style breakouts. Lunch and snacks will be provided.


The Higher Ed Summit is intended for anyone who uses Drupal in the context of a college, university, or other post-secondary institution. All skill levels and roles are welcome. You’ll meet site builders, developers, themers, project managers, support specialists, and more.


Although the Higher Ed Summit is part of the DrupalCon program, it (along with the other Summits) is a separate event and requires a separate registration. On your registration form, there is a section to select which topics pique your interest most, as well as an “Other” field where you can -- and should! -- suggest any other topics about which you are interested.

We are looking for folks to serve as topic facilitators, so if there are any topics about which you would feel comfortable leading a discussion (either among the topics listed on the registration form, or those you suggest yourself), please note that on your registration form. Don’t be shy!

A note about ticket price...

Those of you who have attended other higher education Drupal summits have probably noticed that there is a ticket price attached to this event while the others are usually free, or very low cost.

While we wish we could offer everyone a free ticket, there are operational costs associated with including the Summit in the official DrupalCon program and the convenience of meeting at the Convention Center. We hope the price will not dissuade you from coming to what is certain to be an informative, inspiring -- and fun -- event!

Mar 02 2015
Mar 02

Huh? What are we Electing?

In case you missed it, the Drupal community electing one candidate to serve a two-year term on the Drupal Association Board of Directors. There are two At-Large (community elected) seats on the Board. The other seat is currently held by Matthew Saunders. We've got a really global slate of candidates to consider, and we encourage you to get to know them by listening to the Meet the Candidates sessions and asking them questions on their candidate profile pages. 

Who can vote?

Voting is open to all individuals who have a account by the time nominations opened and who have logged in at least once in the past year. These individuals' accounts will be added to the voters list on and they will have access to the voting.

To vote, you will rank candidates in order of your preference (1st, 2nd, 3rd, etc.). The results will be calculated using an "instant runoff" method. For an accessible explanation of how instant runoff vote tabulation works, see videos linked in this discussion.

Elections process

Voting will be held from 9 March, 2015 through 20 March, 2015. During this period, you can review and comment on candidate profiles on and engage all candidates through posting to the Drupal Association group. We'll also be scheduling and announcing three phone-in all candidates meetings, where community members and candidates can ask questions and get to know each other.

Have questions? Please contact Drupal Association Executive Director Holly Ross. Many thanks to nedjo for pioneering this process and documenting it so well in the past!

Flickr photo: Kodak Views

Mar 02 2015
Mar 02

The Features module helps address the shortcoming in Drupal 7 of how to manage and deploy site configuration data.  There are times when you need to change a Feature.  The Features Override module can help with this, but sometimes doesn’t solve the problem completely.  In this article I will discuss all the different ways to override your Features and the common problems associated with that.  While this has been an issue for years, it’s become more common recently with the advent of Distributions such as Open Atrium and Panopoly which heavily use Features and which expect the users to upgrade to new versions.  Maintaining your site customizations when upgrading a distribution using Features Override has become a more common need.

The Problem

How do I override configuration from an existing Feature  within my site-specific project?


Cloning the base module (not recommended)

If you need to make extensive changes you might need to clone the base module and then customize it.  Disable the original module, uninstall it, then enable your site-specific module.

Pros Cons
  1. You have full control over all aspects of the original module.
  2. Keeps the overrides nicely separate in their own modules that can be enabled/disabled/deployed.
  3. The original Features will never be shown “overridden” (because the original is uninstalled!)
  1. Any future bug fixes, improvements, updates to the original module will not be available.
  2. Since future security patches to the original module won’t be available, this might add a security risk to the project or force maintainers to monitor the original module for updates and apply them to the cloned version.

Using settings.php

If you just need to change a variable (from variable_get) you can do this via the $conf[] array in your site settings.php file.  This method is typically used for environment-specific settings, such as databases, search servers, caching settings, etc.  You can also set the $conf[] array within a custom module if you need to deploy the change across all your environment.  Avoid using variable_set() to change the variable since that will update the database directly as mentioned below.

Pros Cons
  1. The original feature containing the variable (via Strongarm) won’t be marked as “overridden”
  1. Only works for Variables (Strongarm Features)
  2. settings.php not typically part of the code repo, so need to ensure it is version controlled some other way.
  3. Sometimes developers forget to check settings.php for variable overrides, making ongoing support tricky.
  4. Best for Environment variables rather than for any generic Drupal variable.

Update the Database directly

You can create an update hook, or other Drupal hook (hook_enable, hook_install) and update the database directly via SQL or other API functions.  For variables you can use variable_set() to save the new value to the database.  This is only recommended as the last resort for configuration not supported by Features Override.

If you must update the database directly, be sure to only do it once and not in a hook such as hook_init that runs with each page load.  Updating the database on each page load can kill the performance of your site.  With variable_set() you can do this by first calling variable_get() and only saving the value if it needs to be changed.

Pros Cons
  1. Sometimes it’s the only way.
  2. Can keep the overrides separate in their own modules
  3. Only applies specific changes and allows future updates to the base Feature to be used.
  1. Reverting the base feature will change the database back to it’s original value, forcing you to re-run whatever SQL is needed to override it. Can be alleviated by Locking the original base Feature to prevent any reverts.
  2. If the original feature is locked, future bug fixes or improvements might not be available.
  3. The original feature will always be marked as “overridden”.
  4. Some configuration is not stored in the DB, such as Views (or other ctools-based components like Panels) that exist purely in code.

Implement an “alter hook” in code

Most configuration has some sort of “alter” hook that allows it to be modified after it is loaded from the database.  For example, Views calls hook_views_default_views_alter(&$data) to allow you to change any part of a view, whether that view comes from the DB or is in code.  You can create a custom module that implements the desired alter hooks and override the data directly.

Pros Cons
  1. Base Feature will not be marked as “overridden”.
  2. Keeps the overrides nicely separate in their own modules that can be enabled/disabled/deployed.
  3. Only applies specific changes and allows future updates to the base Feature to be used.
  1. Not all configuration has the needed hooks.
  2. Each component has a different hook name and different data structure to modify.

Use Features Overrides module

Similar to the above “Implement alter hook” the Features Override module is designed to create the alter hook implementations for you and export those as new Features modules that you can enable, disable, deploy.

Pros Cons
  1. Base Feature will not be marked as “overridden”.
  2. Keeps the overrides nicely separate in their own modules.
  3. Only applies specific changes and allows future updates to the base Feature to be used.
  4. Features Overrides does the work of figuring out which alter hooks can be used and how to override the data.
  5. Provides a UI for inspecting overrides.
  6. Allows an entire component to be altered (e.g. entire view), or just a single change (e.g. just the title of a view)
  7. Works properly with Features. An Override is just another Feature module on the site.
  1. Not all configuration has the needed hooks.
  2. Can be tricky to “override an override”.

Typical Problems

Feature is stuck at being “overridden”

The most common difficulty is a base Feature marked as “overridden” that does not go away when the feature is reverted.  ”Overridden” simply means that the value of the configuration stored in the DB is different from what is stored in the exported Feature code file.  Features literally re-generates the feature export internally from the DB and compares the code with what is stored on disk.  Doing a “drush fd featurename” simply shows the code diff between the code stored on disk (shown in red) with the code generated from the current database (shown in green).

To determine if a Feature is overridden, Features actually takes the generated code, sanitizes it, sorts it, executes it, and then does an md5 checksum on it.  If the two checksum values are different, the Feature is marked as “overridden”.  However, the “drush fd featurename” command shows the actual code difference regardless of if it’s marked as “overridden”.

This behavior means that “drush fd” might output code differences that actually don’t cause the feature to be overridden.  For example, if you change the order of dependencies in your file and then run “drush fd” on the feature, you’ll see it display those changes, even though a “drush fl” won’t show the feature as overridden.

This makes it difficult sometimes to debug why a feature is overridden, since not all of the output of “drush fd” is relevant.  You need to look for actual value changes, rather than just re-ordering changes.

Adding a new module

Sometimes, just enabling a new contrib module will cause your Features (especially field features) to be “overridden”.  If the new module adds some new settings, formatters, widgets, etc then these settings will be active in the DB but not reflected in the code.  So the Feature will be shown overridden.  Reverting the feature won’t have any affect because there is no way to remove the new settings from the DB without uninstalling the new module.

These kinds of overrides are annoying, but not actually that important.  They don’t prevent the feature from being reverted when a new version of the base module is released.  They are not caused by any site-specific change that would be lost by a revert.  Typically it’s best to just document these cases and leave them as overridden.  Just be careful to not become complacent and make a site customization in the future to the same feature and then ignore that it’s overridden and lose your changes when you revert.  You should periodically do a “drush fd” on overridden features just to be sure what is shown is still just from the new module you installed.

A disabled module

Similar to the above, but the opposite case.  If you have disabled a module that was used when the original Feature was exported, then the code might have settings for that module that are no longer in your database.  Once again you won’t be able to remove this by reverting.  Again, you can just document these cases.  But make sure you really need to have the module disabled.  Having a module enabled that you are not using is not a big performance impact.  The time saved in long-term maintenance of the site it typically more important than worrying about an extra module.

A bad override

If you have used some of the not-recommended approaches for overriding a base Feature, such as writing directly to the DB, then you will end up with an overridden feature that cannot be reverted.  Or if the Feature is reverted, you might lose the change that was written to the DB and need to reapply it.  Even if the Feature is locked to prevent reverting, it will still be listed as overridden.

Another type of “bad override” is using the wrong kind of alter-hook to try to modify configuration.  If the alter hook is called in a way that makes it look like a DB change to Features, then Features is going to see a difference between the DB and code and mark it as overridden.

Overridden Views and Panels

Some modules, such as Views and Panels have their own “override” functionality.  These “pure” Features can exist purely in code with nothing in the DB.  When you make a UI change to a View, it gets copied from the code into the DB and your change is made to the DB.  The View is then marked as “overrides code” in the Views listing.  A View that came from code can be “reverted” within the Views UI.  This essentially just deletes the version of the view in the DB so that the code takes affect again.

Sometimes you can get a View stored in the DB that still matches the code.  For example, you change a View in the UI (causing it to be copied to the DB), then you edit the View and undo the change.  Now it matches the code again, but the view is still in the DB.  In this case, the View Feature will not be shown as “overridden”, but in the Views listing it will still say “overrides code”.

When changing a pure Feature like a View via code (like in an alter hook), your changes will take affect immediately, or possible after a cache clear.  No revert will be necessary because there is nothing in the DB to update.  However, in the above case where you have changed a view and then changed it back so it’s stored in the DB, changing the code will not affect the View until you revert the Feature to remove the DB copy of the old view.

In general, if you are having issues with Views, Panels, or other ctools-like pure Features, make sure they are not overridden in their respective UIs.  For example, click the Revert option for the View within the Views listing to ensure it’s actually using the View stored in code.

Wrong version of Features

If the code in the Feature was exported using a different version of Features than what is on your site, there might be changes that cause overrides.  Ensure your version of Features matches the version used to generate the export.  This usually only applies to major version numbers and is not normally a problem.  Normally updates to the Features module are made in backwards-compatible ways to prevent this.  But certainly be sure your version of Features on your site is not older than the version that generated the base code.  Always try the latest version of Features to see if it helps.

Nobody should be using the 1.x branch of Features anymore.  There is no reason for this.  All Drupal 7 sites should be on the 2.x branch.

Unsupported Component

As mentioned, not all configuration components support Features Override, or only support it partially.  For example, Panelizer works with Features, but doesn’t work well with Features Override because it still depends on the specific order of items in it’s config array and when the alter-hook generated by Features Override tries to change something, that array order might not be preserved.  Sometimes in this case you can create your own alter-hook implementation that overrides the code properly.

This might also be an opportunity to help improve Features Override or suggest patches to the module in charge of the configuration to better support Features Override.

Living with Overrides

What if you have tried all of this advice and your Feature is still marked as overridden?  And what if this override represents a specific site change that you need to maintain and ensure never gets reverted?  The solution to this is to “lock” your feature component.  Go to the Structure/Features page and select the Feature that is marked as overridden.  Click the small “lock” icon next to the overridden component in the right column.  The component will still be listed as “overridden” but when you revert your Features the locked component will be skipped, ensuring that your customization remains in place.

When locking your Features, try to only lock the specific component rather than locking the entire Feature.  The downside to locking a component is that any changes to that component from a new version of your distribution won’t take affect.  This is similar to the consequences of the “Update the Database directly” option listed above.  However, sometimes this is the only alternative.


Just keep in mind that both Features and Features Override are just implementing hooks (normal hooks for Features, alter-hooks for Features Override) that are exposed by Drupal or contrib module.  If those hooks don’t exist or don’t work properly there isn’t much Features or Features Override can do about it.  Drupal 7 doesn’t have any sort of configuration management in core, so every contrib module does it differently.  ctools-based modules have more of a standard framework, as does entity API.  Features itself tries to add code to handle core components such as Fields, Content Types, etc that don’t have the needed hooks.  But there is often a limit to how much Features can do and just patching stuff into the DB is not usually a good solution.

Don’t “hate” Features or Features Override.  Life was much worse without them.  They are the best solution to solving configuration management problems in Drupal 7.  They have been developed over years of experience.  Try to help improve them before trying to implement your own configuration or override architecture.

Drupal 8

Don’t count on Drupal 8 magically solving all of these issues.  The Configuration Management Initiative (CMI) within Drupal 8 was focused on handling site configuration, but not on “bundling functionality”.  It provides an API, storage mechanism, and framework for deploying configuration.  CMI helps a lot, but there are still issues around around component granularity and overriding configuration.  In Drupal 8, configuration is owned by the site rather than owned by a module.   This will make bundling functionality (ala Features original intent) more difficult.  We will be working on Features for D8 soon, but this is still mostly unknown territory.  For now, take a look at some existing modules such as config_packager and config_devel.

I’ve submitted a session to DrupalCon Los Angeles on Features in Drupal 8.  Add a comment and support!

Mar 02 2015
Mar 02

The monthly Drupal core bug fix release window is scheduled for this Wednesday. Unfortunately, due to travel, work, and various other scheduling issues, I was not able to find the time to volunteer to get a Drupal 7 release together for this month. There are also a number of important Drupal 7 patches in development that could probably use another month before they are ready.

Since there hasn't been a bug fix release of Drupal 7 since November, the hope is to get one out in the April release window instead.

Upcoming release windows include:

  • Wednesday, March 18 (security release window)
  • Wednesday, April 1 (bug fix release window)

For more information on Drupal core release windows, see the documentation on release timing and security releases, and the discussion that led to this policy being implemented.

Mar 02 2015
Mar 02

Stephanie El HajjIt is with a happy and heavy heart that I share with you the next step in my journey. After three great years, I am leaving the Drupal Association and packing up my worldly possessions and heading south to Texas, where I will be joining the awesome Austin team of Amazee Labs.

My last three years at the Drupal Association have been incredibly rewarding. I’ve learned so much from each of my (many) DrupalCon teams in Denver, Munich, Sydney, Portland, Prague, Austin, and Amsterdam.

To my Los Angeles and Barcelona teams, I’m sorry to leave you mid-planning, but I’m very excited to see where you take DrupalCon this year without me.

To my DrupalCon globals, thank you for helping grow DrupalCon into what it is today.

To the Portland Drupal community, thank you for being welcoming. Thanks for all the beer and pizza and letting me co-work with you at the Lucky Lab.

To all my volunteers, speakers, sprinters, and trainers, it has been a pleasure to work with you. The community is lucky to have such active, dedicated contributors.

To my colleagues at the Drupal Association, you guys are so weird. Seriously. And I’m going to miss you all dearly.

This may be an end but it’s not THE end. I plan to remain active in the Drupal community, and will be at DrupalCon Los Angeles and DrupalCon Barcelona, as well as MidCamp and possibly LinuxFestNW this year. I hope to see you there!

Stephanie El-Hajj
twitter,, irc: stephelhajj

Mar 02 2015
Mar 02
BeachsidePaul's picture

I hope the Camp is actually on April 11 not March 8 :-)

mherchel's picture

Yep! I derped by copying last year's post and not updating it properly :)

Mar 02 2015
Mar 02

During DrupalCamp London I met with Adam Hill and Michael Schmid who are both nominees in the forthcoming Drupal Association At-Large Board Elections.

They took time out to explain to me why it is crucial we all get involved and vote between 9-20 March.

[embedded content]

The At Large Members serve a vital role in providing representation of the community in the Drupal Association Board. As such it is important we all take time to review the candidates and come 9th March vote for our preferred nominee. To help you decide it is worth watching videos of interviews with all the candidates, available on The Drupal Association website.

Mar 02 2015
Mar 02

In a recent project, I had the opportunity to explore the world of REST web services with Drupal 7. It was a really good experience. I used a couple of modules such as "Services" and "Services Views". It took quite some time to configure the settings and end points to get it in views display.

I am glad to say that REST Export is easier to use with Views in Drupal 8. This is because modules such as "RESTful Web Services" and "Serialization" come under a package called "WEB SERVICES" in Drupal 8 core (Views module comes integrated with Drupal 8 core).  

In this article, I will demonstrate how to use REST Export with Views in Drupal 8. We are going to export the "Article" Content type through REST Export within views in Drupal 8. To achieve this, make sure you have content with the Article content type. 

1. Install/Enable the modules

Search for RESTful Web Services in Drupal 8

Click "Manage" in the administration menu bar and click "Extend". 

Once you are on the Modules page, search for "RESTful Web Services" and "Serialization". Enable both these modules.

Enable RESTful Web Services Module

2. Create the REST EXPORT views

Once the module installation is done, click "Structure" on the administration menu:

Click Structure

Then click "Views":

Go to Views

Click "Add new view": 

Add new view

Fill in the form as shown in the screenshot below. I have given the view name as "Article REST Export". Choose "Article" as the content type from the dropdown. Tick the box against "Provide a REST export" under "REST export settings".

Now you have to provide a link under "REST export path". This link is the end point from where you want to fetch the data. Here, in our example, we are going to create the path "rest/export/json/article". 

REST Export path

Click "Save and edit" and you will see the following page.Click "Settings" next to "Format:Serializer". You will get the option to choose the format of output data at the given end point "rest/export/json/article". 

Format Serializer Settings

Tick the box against “json” since the data will be in json format. Click “Apply”. Finally, save the view by clicking the "Save" button.

Set json value

Once you saved the view, you can test the end point using any REST client. Here, we are using "Advanced REST client", an extension of Google Chrome browser. For installing this, type in "" in your Google Chrome browser. Search for "rest client" as shown in the image below. You will find "Advanced REST client". Click "FREE" to install the application. 

Install Advanced REST client from chrome store

After installing the rest client, go to the path "chrome://apps/" on your Google Chrome browser or click the "Apps" icon on the bookmarks bar of your Google-Chrome browser. Then select the "Advanced REST client" application.

Select Advanced REST client

In "Advanced REST client", we need to provide the path of the end point. Here our path is “http://localhost/rest/export/json/article”. Select "GET" and click "Send" as shown in the following picture.

Provide path and select GET

After you send the request, you will get a response "Status Code: 200 - OK", which is a standard response for successful HTTP requests. This is how the successful response looks:

Status Code: 200 - OK

Final output

Mar 02 2015
Mar 02

In a previous article I showed you how to use the usort() and uasort() PHP functions to sort some more complex data using a comparator callback function. How cool was that?

Although powerful, this technique is quite restricting though because all the logic for the sorting happens inside the comparator function. In other words, you cannot pass parameters to this callback except for the actual default values that are being compared. So what's the problem with this?

Say you have an array of objects that have a name property that can be retrieved by a getName() getter method. And let's say they also have an address property retrieved by getAddress(). And you have a listing of this data and you need to allow for sorting by any of these properties both ASC and DESC. And forget for one second about the possibility of ordering them as they come out of your data store.

Implementing this with just the default usort() function means you will need 4 different comparer functions (one for each combination of property and sort direction). And what if you want to add more columns to the listing? Oh no..

As you can imagine, the solution to this problem is having a dynamic sorting function (or method in a class) to which you can pass the items to be sorted, the property by which to sort and the direction of sort. And then not have to worry about creating all these ridiculous comparer functions. So how might this look like?

function sortByObjectProps(&$items, $method, $order) {
  if ( ! is_array($items)) {
    return false;

  return usort($items, function($a, $b) use ($method, $order){
    $cmp = strcmp($a->$method(), $b->$method());
    return $order === 'asc' ? $cmp : -$cmp;

So what happens here? First of all, $items is passed by reference so we don't need to return it. The return value will just be a boolean indicating the success or failure of the sort. Additionally, we pass the method name that retrieves the property value ($method) and the direction of the sort ($order).

Then we run usort() on the items but - and here is the kicker - with an anonymous function that can use the passed in method and order values. Then it's just a matter of comparing the return values of the getter methods and negate the integer if the order is DESC. Pretty cool no?

So now you can have as many columns as you need and get them sorted in both directions. And obviously even more complex stuff.

Hope this helps.

Mar 01 2015
Mar 01

DCLondon-2015-01#DCLondon 2015 was nothing short of Epic, Drupal Camp London has in its own right become a mini-Con, with community members flying in from not only across Europe but the US, India, Australia and New Zealand it is hard to call it just a London camp!

London is the centre of the multiverse!
Drupal Camp London 2015It was awesome catching up with old friends, some new ones and finding an engaging audience for my session on using Empathy maps, content touch point analysis to develop a robust content strategy.

Bummed about not being able to catchup with everyone though!!

I’d like to reiterate my two asks from the community this March:

1) Like, Follow and spread the word on Bringing Peace Through Prosperity, it goes hand in glove with our activist nature and desire to make this rock a better place today, tomorrow and beyond.

2) Drupal Camp Tunis needs our support to bring their local community into the wider fold, the organisers at DCTunis are looking for speakers and support.

And a HUGE thank you to everyone who attended my session…

See y’all at the next Camp!
Mar 01 2015
Mar 01
[embedded content]

Graphics in the Terminal, for you geeking pleasure

If you're excited about this, you are most likely a developer - so here's the code.

If this data looks familiar to you, it might be because it's the same data you see via Hedley's Angular client.

Same data pulled into an Angular app

The demo is heavily based on the blessed-contrib repository by Yaron Naveh, with some notable changes:

  • No dummy data! All the data that you see in the terminal is real, and is being pulled from a real Drupal server with the data exposed via RESTful.
  • We are using RamdaJs to iterate over the arrays and objects (This repository was a good excuse to practice our functional Javascript).
  • Inquirer library was used to gather the data from the user.

By default, the demo uses the Hedley demo hosted on Pantheon, but you can easily yo hedley on your local, and set the URL to your local server. This will also let you change the geolocation of the events and see them change on the map in real-time!

So What?

Honestly, I don't know. Are there real life uses for such a dashboard? Maybe. All I know is that exercises like that help re-think our solutions. For us web developers, consuming the data not by a browser surely opens the door for some radical new solutions.

Mar 01 2015
Mar 01

This article is part of the Deploying Drupal Like a Pro series.

Application Files and Content Files

If you have just started playing with Drupal you will have something like this in your site's directory structure:




Do you recognize those paths? If so, you are either using symbolic links, or you have not correctly deployed your Drupal application. And that goes for all size and kind of projects.

To start with, you must know that every web application's files can be splited into two basic categories: application and contents.

Application files:

  • They are usually backed by a source control, so if something happens to them in your production environment (not a good thing...) you are fully insured.
  • They do not change frequently, and when they do, it happens in a controlled manner.
  • They do not change as a result of usage of the application. These are "design time" files.
  • Size and disk usage of these files can be easily controlled and forecasted, and is usually so small that size is not a concern.

Content files:

  • They are created as a result of the interaction of users with your application.
  • Size requirements not easy to control and forecast. It can be from the few megabytes to the terabytes scale.
  • Frequently changed, or their changes and growth cannot be forecasted as part of the application's design.
  • Some of this files are meant to be publicly accesible while others not.

Sample Setup

There are many ways to properly deal with that scenario and this is one of them.

Drop your application files (source code) to the system disk, on a path such as


Drop you content files on a separate data disk, on a path such as


Now create a symbolic link so that the contents directory is mapped to \sites\default

mklink -j "c:\inetpub\wwwroot\\sites\default\files\" "d:\contents?\\files"

?What we have just done is telling the operating system that whenever an application tries to acces the sites\default\files path they should actually access the contents folder you deployed on the data disk.

What about the settings.php file? It does not qualify as application or contents file: it's a hybrid between deployment settings and application configuration. If you have horizontally scaled your application you may have different settings.php files in every server, and probably this file will not be backed in your code repository.

What are the benefits of this setup?

  • Cloud SSD storage is x4 times more expensive than regular disks, so you are saving 3/4 of the storage bill (application file size is usually neglibile when compared to contents). Careful with this statement, you may identify that different parts of your contents have different speed requierements, and you could split them between SSD's and regular disks by also using symlinks.
  • You have an effective separation between contents and application files, so it is now easier to have different backup policies between them. You might indeed not even have regular backups of you application files because they are already backed up by the repository, so you only need to take care to backup up your contents.
  • You have eliminated the risk of a collapsing system disk due to unforcasted contents size growth. Of course you are monitoring disk usage, but the rush is less if you know that what is filling up is not the same disk that is holding the operating system and web server.
  • You have greater flexibilty and reduced downtime when performing server scaling on single server setups. Just dettach the contents drive from the old server and attach it to the new one. This takes less than 15 seconds on rackspace cloud.
  • On cloud deployments, storage blobs and content delivery networks are tightly integrated, so you contents file system can get out-of-the-box CDN capabilities.
  • On cloud deployments frontend machines can be volatile. Your application files can be part of the system disk image, and the contents can be shared accross frontend servers.

We haven't talked yet about security (permissions) and folder visibility.

On a regular setup, Drupal will need to modify files inside the files folder, so you need to grant the fast-cgi process identity full permissions on the "files" folder. This account is usually the IUSR account. PHP should not be able to modify the settings.php or application files.

Folder visibility is also very important here. If you left everything as is, you will be exposing to the whole world the private and temporary directories. These directories are meant to be private, and not visible to the outside world. To solve this issue you need to create a web.config inside the sites/default/files directory with the following contents:

NOTICE: We just placed the web.config file inside a IUSR writable directory. Either move the file a level up (and change it's inners) or only give the IUSR specific permissions to the temp, private and public directories.

Although this is not the recommened deployment for all situations, you have an insight in what are the considerations you need to make and what tools you have at your hands to properly deploy your application's files.

Deploying using the PHP deployment tool

The PHP deployment tool automatically takes care of all the previously described setup. In the global.config define a default application root and a default contents root:


Now give your application an alias in the application.config.xml file, define any required symlinks and optionaly override the application and content files folder:


Use the Site/DeployStructure to:

  • Create the application files folder if it does not exist.
  • Create the contents file folder if it does not exist.
  • Give the IUSR account the correct permissions on both folders.
  • Create the symlinks that will link you contents to you application files folder structure.

This article is part of the Deploying Drupal Like a Pro series.

Mar 01 2015
Mar 01

Building a Drupal site is difficult, developing a Drupal Based application is more difficult but correctly managing, deploying and keeping alive an application who's customer is paying you a 4, 5 or even 6 figure number per month is even more difficult. And if you want to do that one last thing in a cost effective way you must do it yourself.

What? That is wrong! Everyone will tell you to focus on your bussiness. If that is developing applications then it is not maintaining the supporting stack. That is true... until whoever is supporting the stack for you ends up eating your business. I know a business case where a Drupal application was moved away from Acquia, and the customer halved hosting costs saving $5,000/month while increasing the available hardware resources. Yes, their new hosting does not provide all the bells and whistles that come from an all inclusive hosting, but... with $5,000/month and depending on which country you do your business in you can easily get 2 full time senior developers.

And you can still get the most of the business critical parts of the add-ons such as test automation, workflow maganement, stagging and production environments all by your own and by saving thousands of dollars.

And the way to go regarding deployment and automation is not clear after all. A few years ago full cloud was the rage. Now Rackspace has started offering On Metal Servers. These are like private colocated servers but with the flexibility of the cloud (spun up and down in minutes). Of course, with the price to performance ratio of colocated. In the end, it is not so clear in what scenarios it is good to delegate all your deployment to a third party, and when not.

In the Deploying Drupal Like a Pro series of posts we will introduce you to what are (some) best practices for deploying a Drupal application to help you handle in a cost effective way your application supporting stack (managing your own infrastructure, of course).

Remember that every business case and application is unique, and that these series of articles are just "basic" guidelines.

When we talk about deployment we will be dealing with:

  • File structure
    • Application files and content files
    • Sample setup
    • Deploying with the PHP deployment tool
  • WebServer site, FastCGI and PHP configuration
    • ?Sharing a PHP binary set between your applications
    • Completely isolating the PHP runtime between applications (while sharing the binaries)
    • The PHP Virtual Runtime: know and control what logs, data and temporary files belong to what application.
    • PHP settings for optimum performance
  • Tunning Web Server Performance
    • Output Caching
  • Cron Jobs
    • How to properly set them up
  • Development and Production Environments
    • ?From you development box to production: an easy, simple but error proof flow.
    • Patch based testing.
    • ?Using the HOSTS directive of your PHP.ini to realtime debug your production environment with no permformance impact.
  • Server Setup
    • ?The Basics
    • Scaling horizontally is not easy. When should I do it?
  • Caching Backends?
    • Memory based caching
    • Memcache / Couchbase
  • Drush
    • Why you should be using it
    • How to install it
    • Basic usage
  • The PHP  Deployment tool

This table of contents is not definitive, we'll be updating it as the articles are writen! The first article Deploying Drupal Like a Pro - Part 1: File Structure is already available.

Mar 01 2015
Mar 01

It has been statistically proven that nobody likes a slow website. We have all moved on from the days when you’d patiently wait for a page to load over that lovely dial-up modem. Nowadays, people want their pretty content, and they want it loaded instantaneously (or at most by 2 blinks).

One very basic concept I learnt about website performance is: minimise requests to your server. This makes perfect sense to me. Say I had a shopping list with 12 items. If I went to the general store and asked the shopkeeper for each item separately, he’d have to make 12 trips and most likely end up being very pissed at me. It’s much more efficient and faster to get all my stuff in a single trip. So we want the server to send over everything the browser needs to display your website in its full glory in as few trips as possible.

Your new favourite word for today is cache. For users to see one of your pages on their browsers, the browser has to ask the server hosting your website for it. Caching just tells the browser to hold onto their copy of their asset for a while instead of asking for it every time it’s required. Loading from cache doesn’t require a request to the server. Less requests to the server equals faster page load.

There are a myriad of tools and checklists out there that can point you in the right direction when it comes to optimising your Drupal site. Tim Millwood’s article on the Top 15 Drupal performance tips is a good one. I followed most of them to optimise my sites but always wondered how these actions actually worked. So here goes, the newbie’s guide to Drupal site optimisation.

General good practices

  • Keep core and modules up-to-date
    • Although this seems like a no-brainer, I also understand that sometimes updating a module may OCCASIONALLY break something (trust me, I’ve been there). My advice? Always test on your local development environment before deploying.
  • Always disable and uninstall modules before removing them

Drupal performance options

This is available out-of-the-box with any Drupal installation. Go to admin/config/development/performance and you will see these options.

Drupal performance settings

  • Cache pages for anonymous users
    • When an anonymous user visits the site, the generated HTML will be stored in the cache table of the Drupal database.
    • This data will be displayed to all other anonymous users.
    • The page caches will not be cleared unless you say so.
    • This will override any block cache settings for anonymous users, which brings us to the next point.
  • Cache blocks
    • The default block behaviour in Drupal is no cache, so enabling this will cache blocks for both authenticated and anonymous users.
    • If block caching is enabled without enabling page cache, then the block cache settings will be used.
    • Given the default is none, you can use the Block Cache Alter module to change this to something more sensible.

Disclosure note: I had a hard time finding documentation on exactly how block caching works in Drupal 7 so please let me know if I’m wrong

  • Minimum cache lifetime
    • This value applies for all cached objects.
    • It tells the system to show cached content for the designated amount of time.
    • If this value is set to ten minutes, the new content you create on your site will not appear until ten minutes later.
    • For new content to appear, the set amount of time must have elapsed and a cache clearing function must be run.
    • If traffic on your site is not high, it’s better to leave it as none.
  • Expiration of cached pages
    • This sets the header Cache Control to public and the maximum age value in the header to the value selected in the dropdown.
    • This header will tell the caching system to serve their copy of the pages until maximum age, after which, the caching system will check back with the server to see if anything has changed.
  • Aggregate and compress CSS files
    • There are numerous CSS files in a working Drupal site, be it from themes, from modules etc. and this option combines all of them into one single file with white spaces removed.
    • Remember the general store example? One request is faster than many requests.
    • Point to note is that if your CSS contains absolute URLs, this may break your site as the URL will not be handled correctly in the combined file. Use relative URLs to be safe.
  • Aggregate Javascript files
    • Similar to aggregation for CSS, this option combines all the Javascript files from your theme and modules, again, to reduce the number of requests to the server.

Usually, it’s best to just check everything here.

Core modules to avoid

  • Database logging (dblog)
    • dblog will write all log messages to the database. Keyword here is all. Error messages, write. Debugging information, write. Module generated log messages, write. You get the picture.
    • This results in lots of database entries every time a page loads. The busier the database is, the slower your site will be.
    • This module is enabled by default for Drupal 7. Disable it and use syslog instead.
  • Statistics (statistics)
    • This module tracks site statistics on page views and site usage.
    • Unfortunately, it writes all these statistics to the database, and again, results in performance taking a hit.
    • Even Mr Millwood (mentioned at the very top of this post), the maintainer of this module, suggests you use Google Analytics instead.
    • This module is NOT enabled by default, and so just leave it be.
  • PHP filter (php)
    • Although there may be certain occasions when you need to have PHP code in your content, most of the time (if not all), you can put that code in a custom module.
    • Putting PHP code in your content means it has to be retrieved from the database before it can be executed, so it makes more sense to bypass this step by writing that code to a custom module.
    • Your database has better things to do than to fetch PHP code for execution.

That about covers all the low hanging fruit for improving the performance of your site. There is definitely more that can be done, but even if you stop here, you should be able to see performance improvements already.

Feb 28 2015
Feb 28

At Code Drop we are looking forward to leveraging all of the incredible effort which has gone into the govCMS ecosystem and all which as gone into making Drupal the choice for Government organisations. Developers who work with or are hoping to work with the platform have a lot of stuff to look forward to in 2015.

Planned Features

While govCMS is the name for the overarching project to bring Drupal into government using turnkey solutions, it is powered by the Drupal distribution aGov. Part of the recent work that has gone into the platform is a planned set of features for a new version of aGov (7.x-3.x). These planned features have been posted on and do represent a really positive evolution in the profile, a quick summary of which can be found below.

A Modern Base Theme & Generated Styleguides

Although technology moves fast, it seems that front-end development has been moving at the speed of light recently. The Zen theme and generated styleguides are being lead by senior front-end developer John Albin. This is an exciting evolution that promises to enhance front-end development workflows for developers using govCMS.

Better Markup Validation

Better markup validation will assist users of the govCMS platform in meeting compliance needs. The move has hopefully been made to allow validation without calling out to an external web services. This should allow faster and local validation of markup.

Default Configuration

Features maintains and enforces a specific state of configuration. This isn’t ideal for install profiles because configuration is often the spring-board for further work. By moving to a solution which provides default configuration, it will prevent changes to the config from causing an "overridden" state in the feature modules.

More Granular Projects

By moving custom modules into their own projects, separate from the install profile developers will have the option to reuse useful components from aGov in projects not specifically related to government. As a developer, code reuse is always an exciting prospect.

Paragraphs Based Landing Pages

The "paragraphs" module can be seen as field_collection with bundles. This allows content admins to easily create chunks of content with pre-defined fielded bundles. This will change the way custom layouts are built and populated with content and will hopefully improve the content authoring experience.

Community Talks

Edge of the Web

Edge of the Web is a conference held across Australia (and streamed online). Christopher Harrop from Acquia will be presenting on the govCMS platform. The talk will be focused on "What is govCMS trying to achieve and how will it work?".

Canberra (and online)
March 26th, 2015

Drupal South

Adam Malone from Acquia will be presenting at Drupal South focusing on "the process taken by Acquia in conjunction with the Department of Finance to make govCMS a success".

3rd March, 2015

Birds of a Feather

The Drupal South wiki has a proposed session for "The aGov 3 Roadmap (govCMS, Drupal in government etc)".

Hands on Training

PreviousNext will be running a training day for people who want to learn about using govCMS which is free for Drupal South attendees.

4th March, 2015

Feb 28 2015
Feb 28

February may be the shortest month of the year, but it's certainly been one of the busiest for the Drupal Association, so I apologize for taking more than a week to get this summary post up! What's been keeping us so busy? Our first ever DrupalCon in Latin America and the Drupal Association At-Large Board elections. Both of these events have been huge positive milestones for the Association, and have involved dozens of volunteers from around the globe. In the middle of all that, we managed to sneak in a board meeting on 18 February. If you missed it, you can listen to the recording, read the notes, and peruse the materials. Or feel free to skim this summary!

Operational Update

  • We have a big initiative internally at the Association to reevaluate the metrics we use to illustrate the success of our work. We are also looking at ways to better display these metrics so that you can see more context. So over the next few months, you'll see the metrics in the dashboared shift and change. Just a bit of a heads up, and let us know if you have any feedback along the way.
  • The February board packet covered our January metrics, and things look pretty good one month into the year. We are especially pleased that the Engineering team has been able to bring site performance to our goal levels. 
  • The Engineering Team also took several big steps towards key areas of the roadmap in January. Step 1 of the roadmap is better Account Creation and Login, and several key issues were closed out.
  • The DrupalCon Team and Engineering worked together to launch in January as well. This shift means that Con sites are all on the same platform now. We no longer have to launch a site from scratch for each Con, which helps make Cons much easier to manage. Most importantly, we've been able to introduce key new features in reegistration for our community. Excited? Go ahead and register now! You can check out the new features yourself!
  • We are really lucky to work with the tireless Drupal 8 Branch Maintainers on the Drupal 8 Accelerate program. The program is picking up steam with a number of grants made and completed already. The next big grant will fund a Drupal CI (testbot) srpint in Portland at the end of March.

Content Strategy Update

Last year, the Content Working Group began a process of building a larger strategy for a reimagination of Our first work was focused on User Research, and completed that work in the fall, publishing the developed personas. The next phase has focused on developing a content strategy. With over 1.2 MILLION pieces of content on, a strategy for dealing with that content is going to be pretty darn important. You can check out the presentation, as well as the post that's currently one of those pieces of content on Advertising Strategy

Finding new revenue streams is vitally important to the Association. For the entire history of the Drupal Association, DrupalCons have been the primary way we have funded other community work. We want to do more to serve our mission: uniting a global open source community to build and promote Drupal. If we're going to do that, we need new revenue streams. The bonus? If we can find new funding sources, it takes the pressure off of DrupalCons to perform financially, which means we can make choices for those events that might not fuel the financial bottom line, but make the events better for the community. 

So how are we doing it? New programs like Drupal Jobs have launched. We are also introducing advertising on and to visitors. We working to develop advertising products that are meaningful for advertisers (enough traffic, good clicks) and also deliver value to our community. We've drawn a few clear lines - we won't advertise on issue queues, for example, and will focus on users who are not logged into the site. We'll also be developing a variety of programs so that small shops can participate alongside bigger firms. 

For all the details, check out the presentation.

The End

Thanks so much for checking in on this board meeting and, as always, please let me know if you have any questions or thoughts.

Feb 27 2015
Feb 27

Grass roots enthusiasm, D8 teen spirit, much needed long absent leadership and community courage facing up to critical issues should overflow into DrupalCon Los Angeles in May

An incredible DrupalCon, DrupalCon Latin America, ended a couple weeks ago and I haven't seen any cool DrupalCon wrap-ups capable of really sharing with the rest of the Drupal community what an extremely well-organized and just plain special community experience it was. I am sure I'm not the only one who felt completely invigorated by it all. Let's take a look at why, and see how we can make it contagious.

Great Venue
Attendees from all over
Quality of presentations
Drupal 8 properly positioned
Now we know when to start switching to D8
Much Needed Drupal leadership
Huge participation in the Sprints and beyond

Great Venue

The venue was well chosen, which gave a great feeling of security, organization and just plain competence all-round. For those of us staying in the hotel on the same premises, we had the feeling of forming part of some kind of Olympic Drupalean village and the foyer was just a natural meeting place for everyone as they arrived each day, and even for a few days after the DrupalCon was all over. Everything just worked, even the WiFi was no more spotty than any other conference (except during the sprints, well what do you expect with record percentages of attendees participating)? One great touch was how Lingotek, a cloud-based translation management system, pitched in to provide live interpretation for presentations ¡Espectacular!

Attendees from all over

It wasn't huge. Yet despite the modest number of people attending (just under 300) those who are never fooled by numbers knew it was truly an international conference and didn't have the flavor of a DrupalCamp at all. It was a Señor DrupalCon! A cursory view of the attendees list shows that all major players knew they had to be there, and 99% knew they had to say something coherent when they did. Latin America is poor, in revolt, with a 500-watt amplified local settings version of the world economic crisis, but we're obviously a firm part of the future, and most presenters (99% as I say) went out of their way to highlight solid and extremely active Latin American participation in the Drupal community and project.

Quality of presentations

Training camps plus DrupalCon prequels...

Not only were the presentations interesting but cut to the core of what people are concerned and anxious about at this critical time in Drupal, and in website and web application development in general. That's why the conference was a success. It had this way of facing up to stuff with courage as a community.

There was a proper debate among the keynotes. Something for everybody? A lot of wishful thinking? Time will tell. But a “pushy” Big Tech rerun by Dries (rerun because big data aggregation (“Netflix... Google... development efforts will shift towards using contextual data collected through passive user behaviors”, and the like, in fact already being implemented on – do people realize that?) was roundly countered by a slogan that figured prominently in “the other keynote” (see following section): “Drupal 8 – For everyone, out of the box”.

See the full list of presentation videos .

My own picks:

So, facing up to stuff that worries and concerns people who actually work for a living and need to exercise their right to access Free Software. That's what needs to be replicated in the Drupal Community time and time again and that's what made for the high quality of the presentations.

Drupal 8 properly positioned

For too long now there's been a widespread tendency awash in the Drupal Community according to which Drupal 8, and hence the Drupal Project in general, has turned somehow into something reserved only for Big Drupal: big shops, big agencies, big companies with huge resources. That Drupal 8 is out of range, too difficult and too big and maybe even cumbersome for single developers, small shops, for companies on a budget. Once said, this impression has been left floating there for quite some time. However, this DrupalCon absolutely smashed these misconceptions, many of which I myself have shared for some time, and provided a much clearer view of what's going on:

  1. Even if you stick with Drupal 7, you still have to learn a bunch of new stuff to learn in this day and age (front-end stuff in terms of javascript frameworks and SASS, backported stuff from Drupal 8, REST, distributed apps, etc.) so get used to learning new stuff. Learning new stuff is good.

  2. The best route is to stick with progress and the industrial mainstream, development fellowship with what's really moving. For those who feel PHP is being superceded by a new generation of programming languages and their attendant frameworks, there exist many new fast-moving eco-systems, in the Javascript world, in the Scala and Java world, in the Go world; too fast-moving some would say and they have their fair share of framework choice panic themselves. Most of these can be used perfectly well in conjunction with modern Drupal 8 distributed approaches. But for many it's all about the PHP renaissance, and one area that's definitely moving is the Symfony eco-system, so strong in itself it's a safe bet for many, independently of the fortunes to be faced by Drupal in the future.

  3. Hear this: Drupal 8 is for everybody:

Larry Garfield, in his presentation at DrupalCon Latin America 2015 in Bogotá summed up the benefits of Drupal 8 in startling fashion (see [video]( and [slides]( when he explained that not only is Drupal 8 a new generation PHP Platform, but that far from what we have been led to expect, namely that it will only be useful for experienced developers and for large companies with huge resources, in actual fact it can do much more than any other CMS framework, for everyone, right off-the-shelf even for plain old site-building right in core without any configuration. It's worthwhile going into a little detail here:

  • Benefits for site builders **for everyone, out of the box**: Build real sites with what comes in core, without any configuration

    • More fields in core (Entity Reference, Date, Link, Email, Telephone) with the Field API (rich data model just with core)

    • Views API and UI in core (saves 6 months in terms of being able to use Drupal 8 after initial RC release, compared to having had to wait for views when Drupal 7 was released, without Views in core)

      • Admin uses views, much more customizable (VBO in core!)

      • Content modeling, editing, assembly, delivery out of the box

      • Content delivery

    • Configuration management based on versionable YAML text files; the configuration is no longer mixed with content in the database

      • Much better solution for dev -> testing -> production workflow and deployment

      • Everyone, large and small, has the right to have access to configuration management tools

      • Real Configuration API

      • Config import/export built in

      • Modules can include default config

    • Translation (of interface, content AND configuration!) has been completely revamped, compacted, improved and better integrated in core

  • Benefits for content editors

    • Rich editing experience (in core: WYSIWYG editor, editing in place, more usable forms; works without configuration)

    • Back to site button (instead of overlay :) )

    • Accessibility WAI-ARIA, keyboard control, voice control with Drupal Announce API so that reportedly a sight-impaired person may edit in place. Best accessibilityt there is. All built in and automatic.

    • New text-based help system (including context-sensitive help)

  • For themers

    • Out with IE6-8

    • Module for IE8 if you need it

    • HTML5 + CSS3

    • Everything responsive out of the box (including menus and toolbars)

    • HTML5 Forms which also work on mobile!

    • Twig ( template engine.

    • 25% fewer divs

  • Benefits for coders (under the hood)

    • Modern version of PHP 5.4, re-visioning how Drupal uses a modern language.

      • Interface-driven development

      • Loose coupling

      • "Hack core without hacking core"; fewer Drupalisms

      • No more Not Invented Here; now Proudly Invented Elsewhere

        • Symfony2 components (HttpFoundation, HttpKernel, DependencyInjection, EventDispatcher, Routing, Serializer, Validator, Yaml)

        • Symfony CMF (Content Management Framework, co-authored by the Symfony, Easy CMS and Drupal communities)

        • Zend Feed (including Atom, and with greatly reduced dependencies)

        • Doctrine Annotations

        • Guzzle (best Http client in PHP)

        • EasyRDF

        • Twig

    • Plugins: same pattern used all over

    • Unified entity API, used all over

    • Unit tests with PHPUnit

    • RESTful pipeline

    • Drupal has gotten off the island, meaning that general development experience in many PHP projects transfer to Drupal 8 and multiple platforms

    • Drupal Console built on Symfony Console for scaffolding and code generation, instrospection and profiling

In addition

A very recent article by Alex Pott, “Drupal 8 and the Enterprise” also does a good job of outlining how Drupal 8 really is for everyone, out of the box. (However, the point raised by Nedjo Rogers concerning difficulties with Drupal 8 support for installation profiles or something similar to features module is worthy of consideration, see my comment (and also the author's very clear reply).

Now we know when to start switching to D8

“The Other Keynote” even included excellent criteria for knowing when we can start using D8 for actual projects, stating that the single most important block for this is the current absence of an automatic upgrade path for beta to beta releases. And it’s best to wait until a release candidate is out or about to be out.

Much Needed Drupal leadership

The “Other Keynote” as I am calling it was very refreshing, almost like a breath of fresh air in its defense of the project and its positioning in terms of free software for everyone. But, such a keynote is neither more nor less than what you would expect Drupal leadership to say. It's just that we haven't had that kind of spirit here since nineteen sixty nine...

I was also impressed by the leadership shown, for example, by Cathy Theys (@YesCT) both in making sure the event was a success, as well as in gaining support for the sprint events and sharing “The Drupal Way” to many first timers, despite language differences.

Huge participiation in the Sprints and beyond

I think a record was broken in percentage of attendees participating in sprints. The level of enthusiasm was enormous and quite a bit was done. Just another indicator of this having been a very special DrupalCon.

Bookmark/Search this post with

Feb 27 2015
Feb 27

If you are playing around with Drupal 8, you may want to install version 7 of Drush on your computer. However, Drush 7 is currently only available as the master branch at github, and you may not like to throw out your existing Drush 6 in favor of the Drush development version, which is not stable. I’d like to share with you a way you can have both installed at the same time. I used a Mac, though these commands should work well also under Linux. They will obviously not work on Windows.

1. Clone Drush master branch from git

We want to get the master branch from the Drush github repository. This will be placed under “usr/local/lib” as a new folder named “drush”. Launch your Terminal and type:

> cd /usr/local/lib/

> git clone --branch master

2. Get composer

Drush 7 requires composer to install, so you need to get that if you don’t have it already. We also want to move composer to /usr/local/bin/ so that it’s easier to use.

> curl -sS | php

> mv composer.phar /usr/local/bin/composer

3. Install Drush

We can now install Drush through Composer. At the end, Composer will generate some autoload files, though you can ignore the suggestions.

> cd drush

> composer install

4. Create an alias for Drush 7.

To make Drush 7 a bit easier to access, we can create an alias that you can use in the Terminal. Type:

> vi ~/.bash_aliases (Linux)

> vi ~/.bash_profile (Mac)

This will open the “vi” text editor. To move around, use your cursor keys. Type “i” to edit the text. When you’re done, type “esc” followed by “:wq” to save and close the editor. Inside this file, we want to add:

alias drush7='/usr/local/lib/drush/drush'

5. Go ahead and unleash the power of Drush 7

Now it’s time to test that everything we did works well. Type:

> drush7 version

It should return this text:

Drush Version   :  7.0-dev

Your Drush 6 will still be there and untouched by this installation. Enjoy!

So what’s new in Drush 7?

Drush 7 adds the following commands to your default arsenal:  browse, core-cli (php), image-derive (id), cache-rebuild (cr, rebuild), config-export (cex), sql-sanitize (sqlsan). Some of them are Drupal 8 specific. I’ll write about these commands in a future blog post.

Feb 27 2015
Feb 27

Begin to design a Drupal website with a million nodes in mind. We build a Drupal website. It runs well at beginning. Until one day, the system has hundreds of thousands of node. We found the site became slow. We need wait many seconds before we can open a new page. Not only it is slow, but also sometimes we got errors like memory exhausted.

Most time the problem was existed at the beginning stage of a system. When designing a site, there are something we as a developer have to take care. We need bear in mind the site will grow and more and more nodes will come. Everytimes creating a function, we need to make sure the function will work fine when there are hundreds of thousands of nodes in the system. Otherwise, those functions may time out or finish all the memory by those ever increasing nodes in the system.

PHP have a maximum memory limit for each user. Sometimes it is 128 MB. Sometimes it is 256MB. The number is limited, and it is not infinite large for sure. There is no limit on how many nodes can exist on our website. As our system getting larger and larger with more nodes created, we will face the memory limitation sooner or later if we did not take it into consideration at the beginning.

Here is a quick sample. Drupal have a function node_load_multiple(). This function can load all nodes in the database to memory. Here are some codes from one of our contributed module.

foreach (node_load_multiple(FALSE) as $node) {
// Modify node objects to be consistent with Revisioning being
// uninstalled, before updating the {taxonomy_index} table accordingly.
revisioning_update_taxonomy_index($node, FALSE);

This code is in an implementation of hook_uninstall. It will run into a problem if there are over 10,000 nodes in the system. As a result, we can not uninstall this module. Here is the error message:

Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 36 bytes) in ...

It used up all 256MB memory before it can load all the nodes. As the result, the module can never be uninstalled from the site.

It is an extreme case. As we troubleshooting an existing site, we may notice similar case here and there. I also notice that we can do something on the field_sql_storage module to make Drupal running faster and keep SQL database smaller.

Feb 27 2015
Feb 27

It's the Drupalize.Me podcast!

This week on the podcast, I chatted with Jesus Manuel Olivas about the Drupal Console project.

Listen here: Podcast Episode 58: Drupal Console

What is the Drupal Console?

The Drupal Console is, at this time, a suite of tools that you run on a command line interface (CLI) to generate boilerplate code and interact with a Drupal 8 installation.

Similar tools include:

  • Module Builder: (Generates Drupal 6, 7, or 8 module scaffolding)
  • Drupal Module Upgrader: (Converts modules from Drupal 7 to Drupal 8; generates static help file with links to relevant change records)
  • Drupal 8 Tools: (Drupal code generator written in bash)
  • Drush (Interact with Drupal installation via CLI, create aliases, create custom commands)

What makes Drupal Console unique?

From the ground up Drupal Console is using the modern PHP practices introduced into Drupal 8, including object-oriented PHP. The Drupal Console isn't a Drupal module, but was built with the Symfony Console Component and other libraries, such as Twig, to generate PHP, YAML, and other file types used in Drupal 8 module development. It is a tool designed for anyone using or planning to use Drupal 8. At the moment, it is used via a CLI, but there are plans to make it accessible through the Drupal administrative interface. Drupal Console works with Drupal 8, and because of the nature of its code base and use of modern PHP, will not be ported to work with Drupal 6 or 7, but instead plans to support Drupal versions from 8 onward.

How does Drupal Console differ from Drupal Module Upgrader?

Drupal Module Upgrader takes a Drupal 7 module and attempts to port it to Drupal 8. While it generates files like Drupal Console does, Drupal Console generates module scaffolding and code based on a series of interactive prompts, instead of analyzing an existing module and converting it to work in Drupal 8.

How does Drupal Console compare to Drush?

There are many similarities between these two tools, but the main difference is how it was built, using an object-oriented architecture and Symfony components. Read more about how the tools are similar in these two blog posts:

What kinds of things can you do with Drupal Console?

Drupal Console provides a number of commands for creating module scaffolding and boilerplate code. For any command, you will be asked a series of questions about what you want. In the case of module scaffolding, files are created and inside these files, classes—complete with namespacing and use statements—are created for you with the naming convention you specified in the command's prompts.

Here are some of the code generating commands currently available, or in active development, in Drupal Console:

  • generate:authentication:provider - Generate an Authentication Provider
  • generate:command - Generate commands for the console
  • generate:controller - Generate and Register a controller
  • generate:entity:config - Generate a new EntityConfig object
  • generate:entity:content - Generate a new EntityContent object
  • generate:form:config - Generate a new ConfigFormBase object
  • generate:module - Generate a module
  • generate:permissions - Generate a module permissions object
  • generate:plugin:block - Generate a block plugin
  • generate:plugin:imageeffect - Generate image effect plugin
  • generate:plugin:rest:resource - Generate REST resource plugin
  • generate:service - Generate a service object

Similar to Drush, you can also use Drupal Console to interact with your Drupal 8 installation, or use it for debugging during development. Here are some of the commands currently available (with more in development!):

Clear (rebuild) cache:

  • cache:rebuild - Rebuild and clear all site caches

Configuration Management:

  • config:debug - Show the current configuration
  • config:edit - Edit the selected configuration
  • config:export - Export current application configuration (Note: config:import is planned for development.)
  • config:override - Override config value in active configuration


  • container:debug - Display current services for an application

Migrate (depends on Migrate module)

  • migrate:debug - Display current migration available for the application
  • migrate:execute - Execute a migration available for application


  • module:debug - Display current modules available for application
  • module:download - Install module or modules in the application
  • module:install - Install module or modules in the application
  • module:uninstall - Install module or modules in the application


  • rest:debug - Display current REST resource for the application
  • rest:disable - Disable a REST resource for the application
  • rest:enable - Enable a REST resource for the application


  • router:debug - Display current routes for the application
  • router:rebuild - Rebuild routes for the application


  • site:maintenance - Switch site into maintenance mode
  • site:mode - Switch system performance configuration (Proposed by Joe Shindelar (@eojthebrave) and other Lullabots during DrupalCon Bogotá, this is similar to the Drush devify command.)


  • test:debug - List units-test classes available for the application

Similar to how a module can supply its own Drush commands, modules can also supply custom commands for use in the Drupal Console. Webprofiler is one example of a module that has supplied its own set of Drupal Console commands:

  • webprofiler:benchmark - Benchmark an url
  • webprofiler:export - Export Webprofiler profile/s to file
  • webprofiler:list - List Webprofiler profiles

To learn more about how the Webprofiler project provided integration with Drupal Console, see this blog post by Luca Lusso, Building Bridges - Webprofiler meets Drupal Console.

There are more commands and functionality in the works, and module developers are invited to provide their own custom Drupal Console commands.

Who is the intended audience for the Drupal Console?

Because Drupal Console generates boilerplate code—working example code—for the many different types of entities and objects in Drupal 8 core, this tool can be particularly useful for anyone looking to learn or teach Drupal 8 development. The goal of the project is to make a tool for people learning Drupal 8 that is relatively easy to use.

As such, the following groups in particular could find this tool advantageous to add to their learning Drupal 8 toolkit:

  • Drupal trainers and consultants (providing Drupal 8 developer training)
  • Contributed Drupal 8 module maintainers and developers
  • Drupal development companies (reducing development time for Drupal 8 projects by using the code generation tools)

As mentioned, there are plans to include a non-CLI interface, to make the tool even more accessible to all site administrators of Drupal 8.

Is it ready now? Who can I ask about it?

Yes, and the maintainers invite you to try it out and send them any questions or comments through Twitter at the following accounts: @drupalconsole, @dmouse, @jmolivas, @enzolutions or @omers.

You can download and learn how to set up the project at

What kind of help does the project need?

What features are planned for development?

  • Verbose code output for learning and leveraging docblocks
  • Complete config:import, site:status, and few a few other commands.
  • Import/export content between Drupal installations
  • Site aliases
  • Generate dummy content, probably using PHP Faker library or Default Content project.
  • Add a GUI for Drupal Console as an alternative to the CLI. This could be especially useful for site builders wanting to generate dummy content or issue site commands without needing to use the command line. It could also be used for code generation in the form of a downloadable compressed file.

Additional Resources Mentioned in this Podcast

Project links

Libraries or projects

Blog posts


Check out this Drupal Podcast in Spanish, hosted by Jesus Manuel Olivas and David Flores, two of the maintainers of Drupal Console.

As you can tell, this project is in full swing and looks to be a key resource for Drupal 8 users of all kinds. Listen to the full Drupal Console podcast and give the Drupal Console a spin!

Thanks to Jesus Manuel Olivas for providing a wealth of information and resources about the Drupal Console on the podcast and for this blog post.

Feb 27 2015
Feb 27

Access professional Drupal training at Drupalize.Me

A product of Lullabot, Drupalize.Me is a membership-based instructional video library. It can be supplemented with on-site training workshops, custom built for any organization.

Go to Drupalize.Me
Feb 27 2015
Feb 27

You ask and you shall receive. That is exactly what happened. Roman, the supporter of the Range Module, asked us to review his module. So that is what we did.

The Range module allows you to add a CCK field that holds two values or a range. Like similar CCK fields there are a bunch of various configuration options available. Those include setting label text, minimums, maximums, etc. Also, the Range module provide three different types: integer, float and decimal. Depending on your need you can choose the best type for you. In the video, I cover the positives and negatives to using each type.

Thanks again to Roman for suggesting the Range module. It is a well built module that does the most important thing a module can do. It just works!

If you have any modules you want us to review make sure to use the contact link on the top of the site. Thanks.

Feb 27 2015
Feb 27

You ask and you shall receive. That is exactly what happened. Roman, the supporter of the Range Module, asked us to review his module. So that is what we did.

The Range module allows you to add a Drupal 7 field that holds two values or a range. Like similar Drupal fields there are a bunch of various configuration options available. Those include setting label text, minimums, maximums, etc. Also, the Range module provide three different types: integer, float and decimal. Depending on your need you can choose the best type for you. In the video, I cover the positives and negatives to using each type.

Thanks again to Roman for suggesting the Range module. It is a well built module that does the most important thing a module can do. It just works!

If you have any modules you want us to review make sure to use the contact link on the top of the site. Thanks.

Feb 27 2015
Feb 27

One of the key benefits of using Drupal as a content management system (CMS) is the flexibility and agility it allows for your content.

I've had the experience of using DrupalGap to take this to the next level, applying the same level of ease to creating mobile apps. 

DrupalGap is an open source application development kit for Drupal websites.

Essentially, it allows developers to create mobile apps which communicate with their Drupal websites.

An intuitive and clean system, it's also perfectly geared up for use with headless Drupal

Agile and seamless

One of the advantages of using DrupalGap was the speed and ease with which I could use it to create a mobile app using web tech.

This can be an unseemly process using some of the other tools on the market.

It may seem obvious, but another key advantage was the fact that it talked seamlessly to the Drupal CMS.

This means that content could be reused in population of the mobile app.

It also makes it simpler for content administrators to update content in one place and have it displayed on the website and mobile app.

A smaller learning curve

Some technologies provide a great output at the expense of usability. But with DrupalGap I particularly like the way that 'views' can be used to display content. 

There's also a relatively easy learning curve if you're familiar with Drupal and JavaScript. You can simply jump right in and get creating. 

After using some CSS3 techniques and the GreenSock animation library I was able to create a smooth, native looking application quickly.

Product optimisations

As with any open source project, there are constant improvements and optimisations taking place.

For me, the frustrating part of DrupalGap is that it's tied to the jQuery Mobile library which doesn’t allow much room for customisation.

I found myself having to overwrite jQuery mobile classes to make the app look exactly how I wanted. This could be an area for change and improvement as the product evolves. 

So if you're already using Drupal and are thinking about a mobile app, then DrupalGap's well worth considering. My colleague Simon wrote a blog post recently about when an app is a good idea, so that's worth a look too if you're not sure if an app is the right tool for you or not.

I'll be writing an introductory guide to using DrupalGap in the near future, so stay tuned for that as well.

It’s good to be kept informed

Provide your details below and we’ll send you our thinking and commentary once a month

Dave Allard

I'm an enthusiastic mobile and web programmer with a keen passion for graphics, responsive design and animation. I love the creativity of the web, and feel that anything is possible when it comes to digital.

Feb 27 2015
Feb 27

The open source content management framework Drupal is at the heart of our work here at Deeson. We use it every day, contribute code and enjoy participating in the global Drupal community.

With the new Drupal 8 release on the horizon and a few of our dedicated Drupalers participating in this weekend's DrupalCamp London, we thought it was a good time to look at the benefits of using Drupal 8 for both marketers and technologists

So as the ever so polite marketer that I am, we'll let the technologists go first. Read on further to find out more about Drupal 8 and marketing.

I'm an IT or technical specialist. Hit me with Drupal 8. 

How would you sell Drupal 8 to me in one sentence? 

"Use Drupal for the developer experience."

Drupal 8 is built using the Symfony framework which makes use of best practice object orientated paradigms.

This allows for easier code completion and better integration into development environments - put simply, programming is less stress and more fun.

What makes it different to the CMS I'm currently (and successfully) using? 

There are several major changes to Drupal 8 which address some of the shortcomings of previous versions of Drupal.

A clear winner here is the ability for developers to track changes in configuration using version control, The means there's a much more reliable process to update a production site cleanly.  

Drupal 8 drops some of the custom built libraries used in previous Drupal versions for best-of-breed industry standard alternatives from beyond the Drupal ecosystem.  

Drupal exposes its data in a RESTful manner using web services - making it much easier to create and maintain integrations with other systems.

The language translation systems have been completely rewritten making multi lingual websites a pleasure to build - compared to some of the pain that developers have experienced building multi-lingual sites on previous Drupal versions.

What benefits could I bring to my company from adopting Drupal 8? 

For the developers, Drupal 8 is better architected. This means it just makes more sense to developers and technologists.

There's less need for what is known as "tribal knowledge" - specialist knowledge about Drupal itself.

For the business this means less need to employ Drupal specialists. Employers can look to recruit and develop good computer programmers who will get up to speed with Drupal 8 faster than they would have done with Drupal 7.

Enough tech talk. I'm a Marketing Manager?. What's in it for me?

Why should I be bothered about Drupal 8?

In the past marketers have too often seen the choice of website content management system (CMS) as a technology decision that belongs in the IT department. 

But reaching the multichannel consumer needs multichannel marketing. And that means that the CMS needs to play an active role in delivering an effective marketing mix.

The right CMS can enable sophisticated personalisation and integration with wider digital marketing infrastructure.

The wrong CMS can lead to ineffective campaign workarounds, problems with handling customer data and unnecessary complexity.

Drupal 8 has been created with marketers in mind. It allows you to easily integrate your choice of CRM, email marketing and marketing automation systems with your Drupal 8 website. It enables marketing teams to easily deliver segmented campaigns by audience, language and device type.

How can I align Drupal 8 with the everyday demands of my job? Can it actually be part of campaign planning and strategy work? 

In modern digital marketing content doesn’t just sit on a website. It’s at the heart of effective marketing across every digital channel.

Drupal 8 is built to combine power with flexibility for marketers. This potential doesn’t come at the expense of user complexity though.

Common administrative features that marketers will use every day have been redesigned with easy of use in mind in Drupal 8.

Content can be edited in-situ, easily previewed so you can see what users will see and a new drag and drop image upload feature makes image management easy.

This power to effectively manage content combined with the integration of Drupal 8 with other parts of your marketing infrastructure means marketing teams can deliver better campaigns with Drupal 8 at the heart of their day-to-day marketing planning and execution. 

How do I sell the idea of using Drupal 8 to my boss? 

A good question. I think the answer is that selling Drupal 8 to your boss is the wrong move.

Understanding the limitations your current CMS places on your marketing is probably a good starting point. 

Once you’ve worked this out, you’ll find that many of them will probably be solved in Drupal 8.

Allowing you to deliver better and more effective campaigns is where the business benefit of a move to Drupal 8 comes from - and so that’s the basis on which you can build a business case.

Don’t forget that the benefits of Drupal 8 are wider than just marketing. So your business case needs to make sure it takes account of the technology and management benefits for your organisation too. 

Whille we've only covered a few of the many reasons to use Drupal as a CMS, it's important to understand how it can align with your goals as a marketer or an IT specialist within your business.

If you're attending DrupalCamp London and you'd like to have a coffee or simply spy on us as we investigate each talk, follow and tweet us @deesonlabs

It’s good to be kept informed

Provide your details below and we’ll send you our thinking and commentary once a month

Simon Wakeman

Simon leads our strategy, UX, creative, content and marketing teams. He has more than 15 years’ client and agency-side experience in digital and marketing roles. He's a Chartered Marketer and also holds professional qualifications in marketing, public relations and change management.

Feb 27 2015
Feb 27

This weekend sees the annual DrupalCamp London 2015 and Deeson team members will be there in force.

As a co-director of the event I've enjoyed seeing DrupalCamp London grow and thrive over the years.

Launched in 2013, the event is a place to gather with like-minded Drupal developers and those who'd like to find out more about the benefits of using an open source CMS.

This year promises to be extra interesting, with the impending release of Drupal 8.

We've already discussed why this is highly relevant to both tech specialists and marketers, but we think it's also important to note how valuable DrupalCamp is to the evolution of the technology. 

People over product

Not only is DrupalCamp exciting in the technology it showcases, but also in the 'process' it hosts - the focused collaboration of great minds in building an even better product.

With such a 'people based' approach to building the product, it's impossible to ignore the personal issues developers may face. 

That's why keynote speakers are focused both on the product itself and the art of bringing people together to solve complex issues and the questions arising for the people behind Drupal.

Saturday sees a huge range of topics covered, both from the perspective of a website user to the often-overlooked issue of the CMS user and how to make their experience better within the system. 

While the schedule focuses on the practical issues developer might face when using Drupal, it also provides guidance for developers who may be experiencing difficult working situations, including the wonderfully titled 'Team working for megalomaniacs' session.

The event's a unique opportunity to gather the people who contribute to and use Drupal on a daily basis. It's a sounding board to find out what makes them tick, steering the product development in a direction they're happy with. 

Two heads are better than one, hundreds are unbeatable 

Getting people in a room together to thrash out issues and debate usability over the same table is second to none in catalysing progress.

Some of the brightest, most unique brains in the land use the technology, each putting their own spin on things. 

Sitting these people down together creates new and amazing ways to drive Drupal forward in to its next phase. 

There's also the opportunity to socialise with like-minded Drupal enthusiasts at the pub. Where better to discuss Bootstrap, Panels and all things content management?

Open to all

Whether you're a hardened Drupal expert or a curious brand manager who has never experimented with the system, the event is inclusive, welcoming and enlightening.

One thing's certain, you'll leave with plenty of answers and a lot more questions than you came with. 

There's truly no better place to witness the excitement and pace of collaborative development. 

Why not come and join us?

It’s good to be kept informed

Provide your details below and we’ll send you our thinking and commentary once a month

Tim Deeson

I’m the managing director at Deeson, looking after our clients and making sure everything runs smoothly. I’m also the co-chair of DrupalCamp London, champion for open source and data and love cycling.

Feb 27 2015
Feb 27

Over the course of this series we have looked at how to add some pizazz, AKA added value, to your projects through the three prongs of technical knowhow, aesthetics and service delivery. Today we'll look at:

Creating Wow - Transforming the ordinary into something special

This is part 5 of a 5 part series. Read the rest of the series here.

To finish off talking about The Wow Factor, here are some ideas where you can go the extra mile to really create wow.

Information Listings

Clients often want to present tabular data, and the first thing they think of is a downloadable spreadsheet or PDF file. Imagine their delight if you took the spreadsheet, imported it using Feeds, and displayed it using Views, providing a searchable, sortable dynamic, categorized listing. Or you could go one step further and sprinkle on some tabular pixie dust with Table Trash.

Demo the effect of your productLet people see the benefits of the product, not just read about the features.


Product Descriptions - Show, don't tell.

A text description of a product is rather dry and pedestrian. Compare the user experience of reading boring product descriptions against a rich media representation of, e.g. multiple product images, a video tour of the product, or even a virtual demo room showing the product in action, which could allow a user to select their choice based upon desired effect, rather than product title. After all, people want an 8mm hole, not an 8mm drill bit.

Rich Media - Background Video

Video is very striking. Nothing attracts the eye like movement, and a good video will bring real impact to a page. Make your video large, or even full screen, to really wow visitors. Now, if you can make that into a background video, and place your call to action as an overlay on top of it, now you've got a really striking landing page

Rich Media - Full Screen

Try removing all the page chrome and other site furniture on special pages - such as landing pages - to create hugely impactful full screen media experiences. Slideshows, video, special landing pages - a full screen landing page will jump out at the user to really bring home your message.

Drupal has it all

In Drupal we already have all the tools we need to create wonder.

Views, fields, entities and fields allow us to create incredibly complex data structures and interfaces that look simple. View modes and image styles allow us to represent that data in flexible and multiple ways. Once Drupal 8 comes out we will have all these wonderful tools in core, coupled with powerful Javascript solutions, RESTful services, multilingual and more.

Are you ready to be wowed?

Yes! Bring some WOW into my life!

Feb 27 2015
Feb 27


There are thousands of situations in which you do not want to reinvent the wheel. It is a well known principle in Software Engineering, but not always well applied/known into the Drupal world.

Let’s say for example, that you have a url that you want to convert from relative to absolute. It is a typical scenario when you are working with Web (but not just Web) crawlers. Well, you could start building your own library to achieve the functionality you are looking for, packaging all in a Drupal module format. It is an interesting challenge indeed but, unless for training or learning purposes, why wasting your time when someone else has already done it instead of just focussing on the real problem? Especially if your main app purpose is not that secondary problem (the url converter).

What’s more, if you reuse libraries and Open Source code, you’ll probably find yourself in the situation in which you could need an small improvement in that nice library you are using. Contributing your changes back you are closing the circle of the Open Source, the reason why the Open Source is here to stay and conquer the world (diabolical laugh here).

That’s another one of the main reasons why lot’s of projects are moving to the Composer/Symfony binomium, stop working as isolated projects and start working as global projects that can share code and knowledge between many other projects. It’s a pattern followed by Drupal, to name but one, and also by projects like like phpBB, ezPublish, Laravel, Magento,Piwik, …

Composer and friends

Coming back to our crawler and the de-relativizer library that we are going to need, at this point we get to know Composer. Composer is a great tool for using third party libraries and, of course, for contributing back those of your own. In our web crawler example, net_url2 does a the job just beautifully.

Nice, but at this point you must be wondering… What does this have to do with Drupal, if any at all? Well, in fact, as everyone knows, Drupal 8 is being (re)built following this same principle (DRY or don’t repeat yourself) with an strong presence of the great Symfony 2 bundles in the core. Advantages? Lots of them, as we were pointing out, but that’s the purpose of another discussion

The point here is that you don’t need to wait for Drupal 8, and what’s more, you can start applying some of this principles in your Drupal 7 libraries, making your future transition to Drupal 8 even easier.

Let’s rock and roll

So, using a Symfony bundle in Drupal 7 is quite simple. Just:

  1. Install composer manager
  2. Create a composer.json file in your custom module folder
  3. Place the content (which by the way, you’ll find quite familiar if you’ve already worked with Symfony / composer yaml’s): "require": { "pear/net_url2": "2.0.x-dev" }
  4. enable the custom module

And that’s it basically. At this point we simply need to tell drupal to generate the main composer.json. That’s basically a composer file generated from the composer.json found in each one of the modules that include a composer themselves.

Lets generate that file:

drush composer-rebuild

At this point we have the main composer file, normally in a vendor folder (if will depend on the composer manager settings).

Now, let’s make some composer magic :

drush composer update

At this point, inside the vendors folder we should now have a classmap, containing amongst others our newly included library.

Hopefully all has gone well, and just like magic, the class net_url2 is there to be used in our modules. Something like :

$base = new Net_URL2($absoluteURL);

Just remember to add the library to your class. Something like:

use Net_URL2;

In the next post we’ll be doing some more exciting stuff. We will create some code that will live in a Symfony bundle, completely decoupled but at the same time fully integrated with Drupal. All using Composer magic to allow the integration.

Why? Again, many reasons like:

  1. Being ready for Drupal 8 (just lift libraries from D7 or D6 to D8),
  2. Decoupling things so we code things that are ready to use not just in Drupal, and
  3. Opening the door to other worlds to colaborate with our Drupal world, …
  4. Why not use Dependency Injection in Drupal (as it already happens in D8)? What about using the Symfony Service container? Or something more light like Pimple?
  5. Choose between many other reasons…

See you in my next article about Drupal, Composer and friends, on the meantime, be good :-).

Feb 26 2015
Feb 26

In yesterday's installment of this series we looked at adding some wow factor through the aesthetics of a project. Today's we'll look at:

Creating Wow - Service

This is part 3 of a 5 part series. Read the rest of the series here.

Wowing your clients is not solely about the end product. The delivery of that product and its ongoing service and maintenance are just as important for the ongoing happiness of the client and therefore the bottom line.


I work principally on providing support and ongoing agile development for existing sites. When you are asked to work on an issue, if you can turn that ticket around faster than expected, that will impress the client. Similarly, if there is an emergency, regardless of the cause/nature, if you can respond in a fast and effective manner, your client will be happy.

I find that quick, simple responses go a long way, even if you can't work on the issue right now. Simply tell your client when you will attend to it, and crucially, follow up on your promise and deliver. Nobody wants to hear "oh, sorry, I didn't get that done because I was doing work for someone else', but people do live in the real world. If you can manage expectations and make promises you can and do keep, then that will go a long way to wowing your client with solid, reliable service.

Security updates are an issue that causes many site owners alarm. People new to owning a website will be unaware of the need for updates, or the transient and continuously evolving nature of software, but it is a reality which must be embraced. You can turn this into a way to improve your service delivery by scheduling for security updates. Security advisory notices come out on a Wednesday evening, so they are easy to take in to account.

Similarly, API changes, typically in 3rd party applications and services is something to be aware of. You can be sure your client has not thought about Google Maps changing its API. They only know that their map has stopped working. If you, however, can warn them before the event and have a solution ready, you will be the hero of the hour.

Proactivity is king!

New Business

New business requires a slightly different approach. Obviously, with all the talk of wow, you can't ignore budgetary constraints, nor give away your shirt. Everyone has heard stories in the news of IT projects going wildly over budget and taking multiples of the expected timeframe. If you can deliver your project on time and on budget, that is wow factor right there. Couple that with consistent, solid, positive communication throughout the design and build process and you will have a client who wants to work with you again.

The next installment (to be published tomorrow) looks back at the various tactics for impressing your clients and offers some concrete ideas for transforming the ordinary into something special!

Feb 26 2015
Feb 26

This past Saturday was the second annual Drupal Drive-in event in Charlotte, North Carolina. Somewhere between a camp and a meetup, the Drive-in was conceived as an informal and ad-hoc gathering by its organizers, Thomas Lattimore and Mark Shropshire. Instead of an approved schedule of sessions, we spent thirty minutes after a general introduction nominating topics and speakers for inclusion, and then deciding which should be more formal sessions and which could be break-out talks in one of the smaller conference rooms.

Almost fifty people were in attendance, and the facilities at Classic Graphics were perfect for our size. Five main sessions were chosen for the large room:

  • Front End Development Best Practices
  • BOA - Dev Ops with Barracuda, Octopus and Aegir
  • Backdrop CMS - A demonstration
  • Shell Devel - Vim, Tmux, Tmuxinator
  • Migrating Sites to Drupal (Migrate module / Feeds module)

I stayed and attended all five of the main sessions, and though I learned something in each of them I personally found the Backdrop and Shell Devel sessions especially interesting. I had never installed and tried out Backdrop before, so I followed along with the session and got my first local build of the Drupal forked CMS up and running. While I fully agree with Shropshire, who presented the session, that this type of fork is healthy and important for our community, I’m still a little ambivalent about the value of project as a whole.

Upon installing it, for example, one of the first things I noticed was that there was no WYSIWYG in core. Drupal 8 ships with CKEditor, so it seemed odd that Backdrop, a fork which claimed as one of its primary ambitions the improvement of user experience, was lacking this feature. When I raised the issue the response was that it is in the pipeline, and will be included soon, so that may well be a very temporary issue.

To its credit, the Panels-like layout system looks great, providing a lot of flexibility while also improving the somewhat confusing-at-first interface of the Panels module. The larger question remains though – as Drupal 8 moves forward to embrace modern PHP best practices and facilitates wider involvement with non-Drupal PHP developers, what kind of developers will Backdrop attract long term? It’s impossible to know now where the project will lead, but Shropshire’s session certainly made me more curious about the potential it may have.

The session on Shell Devel had a lot of crossover with a recent blog post by our own Bob Kepford, Efficient Drupal Development with Tmux and Tmuxinator. I rely on a regular multi-tabbed terminal and PHPStorm for my day to day development, but getting to see in person the multi-pane setup and cross project configurations that are possible with Tmux and Tmuxinator has me considering the switch. Three different speakers briefly showed us their setups as part of this session, and between them it was very clear just how personalized every aspect of such a setup can be.

One of the things I try to do at any camp I attend is to mentor someone interested in becoming a contributor, and this camp ended up being no exception. I spent the latter half of the lunch break helping a project manager, who had never used git before, to submit his first documentation patch to core Drupal 8. With a little more guidance during another session, he had already pumped out a second patch by day’s end!

Drupal Drive-in Charlotte 2015

Image courtesy of @CharDUG

Overall the Charlotte Drupal Drive-in was an excellent camp with an innovative structure that other small camps may benefit from considering. I learned a few things, and hopefully helped someone else learn a few things, which is what it’s all about. Thanks again to the organizers for the hospitality!

Additional Resources

Efficient Drupal Development with Tmux and Tmuxinator | Mediacurrent Blog Post
Dropcast, Episode 0 | Mediacurrent Podcast

Feb 26 2015
Feb 26

It is well understood within the tech community that most of our executives started out as being highly technical; in the trenches writing code for 15 hours a day. Like many journeyman professions, the more successful you are at your skillset, the more likely you’ll be rewarded with larger, higher profile, projects. The master developers among us are often asked to lead within our organizations and eventually take on such diverse responsibilities as scrum leader, mentor, technical lead, and eventually, the role of technology executive. However, within this natural progression there are many shortfalls, of which the lack of the right education for the new executive is paramount.

Over time, they realize their coding skills are no longer directly relevant to their daily responsibilities. Gone are the zen like days of code writing and total control over their daily tasks. ROI, project profitability, development methodology, recruiting, and staff retention rule their days. Alas, where is our budding executive going to learn these new skills? Books? Friends? By making $20,000 mistakes?

There is a better way.

Attention all technology executives that have been forced to learn things the hard way! Please come share your divine knowledge and experience with the Drupal Community at DrupalCon Los Angeles! Sign up to deliver a session covering your own most important lessons learned.

Chris Stauffer
Business and Strategy Track Chair
DrupalCon Los Angeles

Feb 26 2015
Feb 26

If you need a simple Views display switcher to toggle e.g between a list and a grid display of a view, there are a couple of plug & play options already.

Display Suite and Quick Tabs are modules which provide this functionality but they seem to be quite an overkill for a simple display switcher. View modes on the other hand seems to be exactly what is needed, however there is no stable version and the development one did not work for me.

Our use case dictates that the filters and the page number have to stay intact while switching to a different views display. The page will be reloaded, no AJAX magic here.

So let's create our own views display switcher. In order to do that you will obviously be needing a view with at least two page displays showing content in different ways. You will also have to put some code into your custom module. If in doubt, refer to the countless other tutorials.

Set up your view

In the view named [view] set the path of [display_1] to e.g [page/grid], the path to [display_2] to e.g [page/list].

Create callback function

Create a simple callback function which will provide the switch in ready-to-be-displayed HTML.

* Gets HTML output of a switch which will switch between grid and list display of a view.
function [mymodule]_get_views_display_switch() { $switch = l(t('Grid'), '[page/grid]', array(
'query' => drupal_get_query_parameters(), // This ensures the view will keep filter settings when switching the display.
'attributes' => array(
'class' => array('page-grid-switch') // Adding a css class for this link.
$switch .= ' | ';
$switch .= l(t('List'), '[page/list]', array(
'query' => drupal_get_query_parameters(),
'attributes' => array(
'class' => array('page-list-switch')))); // Adding CSS class for whole switch.
$switch = "" . $switch . "";

Implement views hook

Implement hook_views_pre_view hook to add the switch to the view.

* Implements hook_views_pre_view().
function [mymodule]_views_pre_view(&$view, &$display_id, &$args) {
  if (
$view->name == '[view]' && $display_id == '[display1]' || $display_id == '[display_2]') { // Adds a display switcher to the header of a view.
    // 'footer' as second parameter will add the display switcher to the footer of the view instead.
$view->add_item($display_id, 'header', 'views', 'area', array('content' => [mymodule]_get_views_display_switch(), 'format' => 'full_html'));

This should do it. The l() function will make sure the link is marked active when it's active and drupal_get_query_parameters() makes sure the filters and current page stay intact while swichting.

Feb 26 2015
Feb 26

If you need a simple Views display switch to toggle e.g between a list and a grid display of a view, there are a couple of plug & play options already.

Display Suite and Quick Tabs are modules which provide this functionality but they seem to be quite an overkill for a simple display switch. View modes on the other hand seems to be exactly what is needed, however there is no stable version and the development one did not work for me.

How it needs to work

Our use case dictates that the filters and the page number have to stay intact while switching to a different views display. The page will be reloaded, no AJAX magic here.

So let's create our own views display switch. In order to do that you will obviously be needing a view with at least two page displays showing content in different ways. You will also have to put some code into your custom module. If in doubt, refer to the countless other tutorials.

Set up your view

In the view named [view] set the path of [display_1] to e.g [page/grid], the path to [display_2] to e.g [page/list].

Create callback function

Create a simple callback function which will provide the switch in ready-to-be-displayed HTML.

* Gets HTML output of a switch which will switch between grid and list display of a view.
function [mymodule]_get_views_display_switch() { $switch = l(t('Grid'), '[page/grid]', array(
'query' => drupal_get_query_parameters(), // This ensures the view will keep filter settings when switching the display.
'attributes' => array(
'class' => array('page-grid-switch') // Adding a css class for this link.
$switch .= ' | ';
$switch .= l(t('List'), '[page/list]', array(
'query' => drupal_get_query_parameters(),
'attributes' => array(
'class' => array('page-list-switch')))); // Adding CSS class for whole switch.
$switch = "" . $switch . "";

Implement views hook

Implement hook_views_pre_view hook to add the switch to the view.

* Implements hook_views_pre_view().
function [mymodule]_views_pre_view(&$view, &$display_id, &$args) {
  if (
$view->name == '[view]' && $display_id == '[display1]' || $display_id == '[display_2]') { // Adds a display switch to the header of a view.
    // 'footer' as second parameter will add the display switcher to the footer of the view instead.
$view->add_item($display_id, 'header', 'views', 'area', array('content' => [mymodule]_get_views_display_switch(), 'format' => 'full_html'));

This should do it. The l() function will make sure the link is marked active when it's active and drupal_get_query_parameters() makes sure the filters and current page stay intact while swichting.

Feb 26 2015
Feb 26

Moving content between different environments is a need for many big companies that have a Drupal site and content that should be created, reviewed, edited and published on different environments. Although Drupal 8 is not yet released, a content staging solution is already in the works. Dick Olsson (dixon_ on and I are working on this solution together and we aim to release an alpha version soon.

The content staging solution for Drupal 8 is based on a re-designed version of the Deploy module. This solution consists of some contrib modules and depends on three Drupal core modules. The core dependencies are Entity API, Serialization and Restful Web Services. The contributed module dependencies are Relaxed Web Services, Multiversion, Key-value Extensions and (soon) Deploy.

The Relaxed Web Services module provides a Restful/Relaxed JSON API and endpoints for entities, file attachments, administrative tasks like revisions comparison, starting/stopping replication, etc. It extends the core REST API with better support for handling UUID references, revisions, file attachments, etc. This module is borrowing the API interface from CouchDB and its Replication API. CouchDB is a NoSQL, document-oriented database.

The Multiversion module provides revision support for all content entities. It also tracks update sequences to make dependency management easier and tracks revision trees (similar to Git) in order to support conflict detection. With Multiversion, entities are never deleted, they are just flagged as deleted. This is needed in order to replicate deletions and for conflict handling.

Key-value Extensions provides an extension of the core key-value API with a backend for lists and sorted sets that you can do range queries on. This module is needed because of the way the Multiversion module stores its sequence indexes.

Deploy (will be implemented soon) - provides a simple user interface to manage replication and conflicts.


At the moment, we are using the CouchDB replicator to test content replication between different systems. The CouchDB Replication protocol is a protocol for synchronizing documents between 2 peers over HTTP. This protocol will be used to implement the Replication Web Service module for Drupal 8.

The Replication Web Service module will provide the possibility to replicate content between different systems and Drupal 8, it will also have a Drush plugin for running the replication. Furthermore, it will be possible to run live replications in order to synchronize applications.

Offline applications

By using a standardized HTTP replication protocol for Drupal, such as the one CouchDB is using, the same solution will be applicable to other very interesting use cases as well.

The Offline First principle is quite new in web development, but it has many benefits for users and their experience. A website designed after these principles will continue to work, even if there is no Internet connection available. Now it’s possiblel to create Offline First applications with Drupal 8! We can build offline applications using the same suite of modules that we introduced earlier. To do this we need a remote database - represented by a Drupal 8 site and a local browser-based database, for example PouchDB.

The content staging suite provides all necessary features, such as synchronization, revisioning and file attachments, to create an offline application. At the moment, it’s working with PouchDB version 3.2.1. I’ve created a video to demonstrate how synchronization between PouchDB and Drupal 8 works

Video of Test pull and push replication using Drupal 8 and PouchDB

To test this I use an application based on ToDoMVC and PouchDB 3.2.1.

Headless Drupal

In Drupal 8, we have integrated the Twig template framework, a very good thing, especially for front-end developers. However, sometimes we want to create an absolutely custom frontend using the power of libraries and frameworks like AngularJS and Hoodie, combined with Drupal 8 on the back-end.

The solution we implement provides a lot more possibilities than the Restful Web Services module from Drupal 8 core. This will make possible to create awesome applications using frameworks like AngularJS, a PouchDB database and Drupal 8.

Other Systems

The content staging suite will have many different use-cases, allow for replication between different systems and database, not just between Drupal sites.

Currently we have test suites for replication between Drupal 8 and CouchDB (using the CouchDB replicator, but later you will be able to use the Replication Web Services module). We also have test suites for replication between Drupal 8 and PouchDB.

In the future, this solution may be used to integrate Drupal 8 with other libraries and frameworks.

For more information, check out:

Feb 26 2015
Feb 26

Most developers know how to do these, but a lot of people follow the temptation and skip them in the rush to go live.

These simple steps reassure future developers and clients that you know what you are doing, subsequently increasing your value with just a few minutes of work.

All which means you can charge more and book more clients, both of which lead to the ability to do more of the things you love that are just for fun!

1. Customize the Favicon to replace the little Druplicon in the browser tab
-- Create a favicon, usually a high contrasting version of the logo with a transparent background. I've done them in skitch and Pages in a pinch.
-- Rename it 'favicon.ico' and place it in your docroot (usually the file you renamed from Drupal to YOURSITE), this makes it easier for some browsers to find it. Assuming it's a smaller image, I also like to put a copy titled 'logo_favicon.png' in the images folder. This way your futureself can find it if it gets deleted in a Drupal update.
-- Go to YOURSITE/admin/appearance/settings/YOURTHEME and upload your favicon.ico under the 'shortcut icon' setting at the bottom.
-- Clear the cache, and refresh and your favicon should appear. If you bookmarked the site, you may also need to dump the browser cache to get it to show up.

2. Remove the "powered by Drupal" from the footer
-- Go to YOURSITE/admin/structure/block
-- Select the "powered by Drupal" block and set the region to 'none'
-- Save your changes

3. Theme Screenshot
-- This is the preview of your theme that future developers and yourself will see.
-- When everything's about ready to go. Take a simple png screenshot.
-- Rename it 'screenshot.png' and place it in your theme's root folder.

For more tips on how to get the most bang for your buck designing for Drupal, get on the refresh list.

Tired of your Drupal theming choices being custom by hand or somebody else's base theme? The Transform Your Favorite Framework into a Drupal 7 Theme guide is HERE and ready for testing! It's less than 20 pages, concise and ready to walk you through the steps, of converting your framework to a D7 theme. No need to open 150 tabs and search stack exchange trying to figure out what order to put the JS files in.

Get 20% off my Transform Your Favorite Framework to a Drupal 7 Theme Guide in rough draft form for opening day. All future updates are free, and you can get refunded anytime.

Not ready to buy the book? By joining the list here you'll get updates on this book, future discounts, and all of the exciting theming things (Drupal 8!!) coming up! Thanks for reading! Questions? Ping me @sarah__p on Twitter.

Feb 26 2015
Feb 26

There are a boat-load of modules that send notifications.. since I've already got Rules and Views turned on, why not use the Views & Rules module to do custom notifications, a feature is provided...  briefly it works like thisview for rules notifications drupal

  1. Using profile2 add a taxonomy field to a profile
  2. Add the same taxonomy to a content type
  3. When new content is added a rule fires that runs a view - selecting all the users who have listed that taxonomy term in their profile
  4. The rule then fires out emails...   

I really like how simple this notification scheme is, and generally how it re-uses the modules and such that are in place...  so here's how to do it

After installing the modules mentioned above go ahead and create a view such as the one on the right...

set yourself up with a contextual filter.. you'll pick that up from the rule - 

contextual filter to get data from the rule

Since you're going to be adding a relationship off of a relationship with the taxonomy terms (from profile2 - > to term -> to content)  remember to select distinct or you may get a ton of duplicate content - I usually click the pure distinct too... not entirely certain what it does... but it all seems to work :)  

select distinct

The rule side of this is remarkably simple - take a look at the image... you just add the view loop - your almost done!

The fuel for the rule

all of your fields from the view are available once the view 

Rules for the view 

then you just add a "send e-mail" link and that's it...  this is how I'm handling notifications for folks, and also how I'm taking care of the 18f api notifications requirement :)

please ask any questions in the comments below

Feb 26 2015
Feb 26

The Revolution Will Not Be Televised Recently I found myself musing about two Drupal-related posts from back in 2007 that projected very different futures for the software project.

The first was by Jeff Robbins of Lullabot: “How Drupal Will Save the World.”

Robbins took as his reference case a community in Nigeria facing exploitation by a multinational oil company. Drupal, he suggested, could empower the community and “give a voice to those who might not otherwise be heard,” driving an internet that was “a powerful force for social change.” To achieve that vision, Robbins laid out technical challenges, centered on making the software easier to learn and use.[1]

A few months after Robbins’ post, Drupal contributor Fergus Geraghty initiated a discussion, “7 million reasons to consider democratising Drupal?” Drupal project lead Dries Buytaert had recently co-founded the company Acquia, and Buytaert’s start-up had just announced its first round of $7 million in venture capital financing. Geraghty expressed concern that the new commercial demands of Acquia could come to shape the overall direction of Drupal, pushing the project in the direction of profit maximization. Against this future, Geraghty proposed the creation of a co-operative to serve as the owner of the Drupal project.[2]

Seven years later, which of these futures are we living? Is Drupal empowering the marginalized and saving the world?

Or is it serving “the man”?

Software Freedom and Social Change

The idea that Drupal and free software could have a role in revolutionizing society might not be as off-the-wall as it sounds.

In Mutual Aid: A Factor of Evolution, the 19th century anarchist Peter Kropotkin countered the social Darwinist “survival of the fittest” thesis by arguing that cooperation was a driving force of evolution and a basis for free human societies.[3]

Late in his life, Karl Marx mused that the crises of modernity could be overcome only through co-operative production for use rather than profit or "the elimination of capitalist production and the return of modern societies to a higher form of the most archaic type - collective production and appropriation."[4]

Copyleft, “a general method for making a program (or other work) free, and requiring all modified and extended versions of the program to be free as well,”[5] has clear roots in radical political ideals and projects.

Against the dominant capitalist models, free software suggests an economy and society where collaboration rather than competition is the core paradigm and where use value trumps profit maximization. “From each according to ability, to each according to need,” the early utopian activists cried.[6] Free software seems to hold the promise of realizing their progressive vision in the heart of advanced capitalist society.

And Drupal is more than free software – it’s a platform built by and for participation and collaboration. Drupal originated as a student project connecting a group of friends at the University of Antwerp. From its first lines of code, Drupal has connected people and enabled peer-to-peer communication – essential elements of a participatory, democratic society. For many early Drupal adopters and contributors, blending progressive social ideals with free software development seemed a perfect fit.

CivicSpace Labs – one of the first Drupal shops – emerged from an explicitly political context and had empowering social change as its primary focus. Core Drupal systems like the installer and the update system owe their origins to CivicSpace. In a very practical sense, Drupal owes a lot to early adopters motivated by the ideals of free software and social activism.

Taking the Pulse

By many measures, the project of saving the world with Drupal is alive and well.

Participation continues to grow. The number of Drupal contributors has jumped significantly with each major version, a trend that continues with the upcoming Drupal 8 release. Well over a million websites benefit from the free software collaboration that powers Drupal core and its thousands of contributed add-ons.

Positive examples stand out of Drupal engagement on critical social fronts including gender and LGBT issues. Drupal contributor Angie Byron has been a prominent advocate for – and inspiration to – women in technology. In 2010, Byron proposed updating Drupal community practice on gender, enabling a more inclusive, non-binary gender designation on While the initiative met with significant resistance, ultimately the proposed change was adopted.[7]

Drupal is powering websites across the spectrum of social change organizations and movements. At Drupal shops like Koumbit and Palante Technology Cooperative, social justice is an explicit commitment reflected in democratic and co-operative organizational structures.

But for anyone dreaming of Drutopia, there’s no shortage of warning signs. One of the biggest came in late 2009 with the announcement that had relaunched on Drupal. The software that once ran tiny alternative sites now was powering the public face of the leading capitalist power. Progress?

Figure 1: Drupal and Joomla Usage by Site Size

One way to get a handle on who Drupal is serving is to look at usage statistics. The data provided by provide an incomplete but potentially useful benchmark.[8] Figure 1 shows July, 2014 usage data for four data categories based on the level of site traffic: the entire internet, the top one million sites, the top 100,000 sites, and the top 10,000 sites. The data represents percentages of all known sites. As well as Drupal data, the chart includes data for Joomla!, a free software CMS that perhaps most closely parallels Drupal. Like Drupal, Joomla! powers a significant percentage of the Internet, is written in PHP, has a global team of contributors, and is licensed under the General Public License (GPL).

The data for Drupal shows a clear trend: as site size increases, so does the level of Drupal usage, from 4.3% of the entire web to 15.2% of the top 10,000 sites. Notably, when going from the top million to the top 100,000 sites, Drupal usage numbers nearly double from 7.6% to 14.7%.

In contrast, Joomla! data have the opposite structure. While 17.1% of the entire web shows up as Joomla!, the number for the top 10,000 sites is only 1.6%.

In both absolute and comparative terms, Drupal appears to be highly focused in the highest-traffic, top-end sites.

And if Drupal already is oriented towards high-end users, signs are that this trend will only increase. Some commentators have observed that ­– even more than with previous versions – changes in the forthcoming Drupal 8 version stand to disproportionately benefit high-end, high-traffic sites, while potentially leaving smaller Drupal sites behind (see “Small Sites, Big Drupal”).

In a 2013 blog post, Drupal contributor Larry Garfield wrote that Drupal followed what he described as a normal project trajectory in which “larger and larger sites tend to be more and more profitable and more and more interesting. Small sites become a ‘solved problem,’ and moving up market is the natural movement.”[9]

But the contrasting data from Joomla! strongly suggest there’s more to the story.

Structured for Profit?

When Geraghty raised the possibility that Drupal could become increasingly enmeshed with corporate interests, he focused squarely on the centralized power structure of the project. Reaction was swift and sharp. One commenter described Gerathty’s post as “Slippery, innuendo-laden suggestions about what Dries, Acquia, and its investors might be doing or might do in the future.”[10] Within days, the post was locked down to prevent further comments.

But for purposes of our comparison of futures, it’s worth giving Gerathty’s points a second look. How is Drupal decision-making power invested?

Drupal is structured on a model often called, by its proponents, “benevolent dictatorship for life” (BDFL). Under this model, a single founder – in Drupal’s case, Dries Buytaert – exerts final control.

Today, several bodies, theoretically, exert influence or control over the Drupal project.

  • Core committers These are the individuals who have final say over which particular changes are made to Drupal core. There is a single permanent core committer, Buytaert. For each major version of Drupal, Buytaert appoints one or more “branch maintainers” who commit changes to that version of the software.[11]
  • Official Drupal 8 initiative leads Drupal 8 development was organized around a series of official initiatives, approved by Buytaert, who appointed an individual to lead each initiative.[12] Official initiatives shaped the core directions and solutions adopted in Drupal 8.
  • The Drupal Association The Drupal Association is a nonprofit that, according to its mission, “fosters and supports the Drupal software project, the community and its growth.”[13]
  • Drupal Working Groups Three Working Groups – Community, Documentation, and Technical – oversee key areas of the Drupal project. Individuals are appointed to these groups by Buytaert or his designate(s).[14]

Beyond formal decision-making roles, the individuals whose code contributions are accepted also exert a significant influence on the software and, by extension, the Drupal project.

Figure 2: Drupal decision makers and top contributors by company

Figure 2 draws on data to trace the relationship of Drupal project decision makers to the current companies they list on their profiles as of July, 2014. (Users of can identify a “Current company or organization” on their user profiles.) Top contributor data is from DrupalCores.[15] Particular individuals may fill multiple roles and therefore be counted more than once. Companies listed are those that fill two or more places. Members of these groups serve as individuals rather than formal representatives of their associated companies.

One clear trend in the data is that in all six groups, Acquia has a higher number of places than any other company. At fifteen total places, Acquia preponderates with five times the number of the next closest companies.

Of the eight companies listed, four have from twenty to fifty employees or contractors listed on, one has over one hundred, and one – Acquia – has over three hundred. It seems fair to say that the companies most represented in Drupal structures are medium- or large-sized Drupal companies.

Acquia has a partner program in which companies receive client referrals from Acquia and in return remit a percentage of revenues to Acquia. Of the seven non-Acquia companies listed in Figure 2, five are Acquia partners.

When it restructured in 2011, relocating from Belgium to the U.S., the Drupal Association produced guidelines for board composition, which should reflect “the various perspectives of the members of our community (volunteers, small shops, large shops, large integrators, in-house teams, designers, end-users, etc).”[16] Today, three board members are from Acquia partner companies, all companies in Acquia’s “Enterprise Select” category, and of the remaining Drupal-based regular board members, one is the CEO of a company listed on with usual project budgets up to €2 million; one is on staff at PayPal; and the two most recent board appointments, in May, 2014, were for senior staff at Pfizer and NBCUniversal.

In short, the board is increasingly enterprise-oriented.

None of this data indicates a conspiracy on Acquia’s or any one else’s part to stack Drupal decision making with their people. Any company amassing top Drupal talent by the dozens, through hiring and/or acquisitions, could be expected to end up with influential Drupal participants.

However, the data does suggest that a trend towards enterprise interests in the software is closely coupled with the power structure of the Drupal project, centred on Buytaert as founder of Drupal and Acquia. If this isn’t the future Geraghty was concerned about, it sure bears a striking resemblance.


In retrospect, for all its appealing idealism, Robbins’ 2007 post seems remarkably naive in its program. The basic premise – that software developers, mainly in the U.S. and Europe, will be the ones to empower African villagers – seems paternalistic. Critically, his recipe for saving the world is entirely technical. No attention is given to the social structures or power dynamics that would be involved in enabling marginalized or exploited classes effectively to challenge corporate or state power.

While on some fronts it continues (in Robbins’ words) to “give a voice to those who might not otherwise be heard,” Drupal increasingly is reinforcing the power of those who already have the loudest voices and the deepest pockets. Returning to his reference case of a Nigerian community facing down an oil multinational, it’s hard not to conclude that, of the two, it’s the oil company that’s more likely today to have Drupal in its corner.

The experience of Drupal raises important questions for both free software and politically progressive projects.

  • The cult of growth Self described “evangelists” of Drupal – and free software in general – often have uncritically promoted growth as a good in and of itself. Hence, for example, the growth-oriented mission of the Drupal Association quoted above. We could use a much more nuanced discussion about growth and its attendant risks – and differential benefits.
  • White guys to the rescue The idea that a group of predominantly male, predominantly European or Euro-American geeks is going to “save the world” through brain power might fit a Hollywood plot line, but calls for a healthy dose of scepticism when it appears off the screen.
  • Critical debate Critical perspectives, even (or especially) ones that challenge accepted truths and power structures, are essential to the health of any project. Rather than shutting down discussion, it’s important to recognize, support, and, where needed, fight for openings for debate and renewal.
  • Structure matters At the risk of stating the obvious, proponents of participatory, grassroots social change have reason to be doubtful of projects with a highly centralized, “dictatorship” model.

For all its challenges, the pursuit of progressive political ideals within and through the Drupal project remains alive and active. And the Backdrop fork of Drupal reminds us in the most direct way possible that, while software freedom is not in itself enough, it does make a difference.[17] Whoever may claim the trademark or exert founder’s rights, no one person or company “owns” Drupal. We all do, and our freedom includes the ability to take our collective work in our own direction.

In short, Drupal is perhaps not so different from other sites of social change activism. Emerging alternatives don’t exist on some abstract plane, removed from the dynamics of state power or advanced capitalism. Instead, alternatives are themselves deeply embedded in and shot through with the logics of market society. Yes, those trying to use and shape Drupal for radical social change are working at the margin. But, as feminist theorist bell hooks wrote (in a very different context), the margin can be “the site of radical possibility.”[18]

Personal narratives

Abstract questions of saving the world or working for capital accumulation of course translate into real-lived experience. For me personally, the tensions between free software and working for “the man” are ones I feel every day.

For the past four years, I’ve focused on building and maintaining a Drupal distribution, Open Outreach, aimed at meeting the needs of small community and activist groups. With my spouse, Rosemary Mann, we’ve built the distribution almost entirely as a volunteer project. Today, I’m happy to see Open Outreach powering websites for Cooperation Network for Renewable Energy in Malawi, South Central Indiana Jobs With Justice, and Women Occupy San Diego.

But volunteer development and gratification don’t pay the bills. I also contract part time for Tag1 Consulting, one of the high-end companies listed in Figure 2.

[Editor’s note: This magazine is published by Tag1 Publishing, a subsidiary of Tag1 Consulting.]

I actually love my work at Tag1 – I get to collaborate with and learn from a creative and super-smart team on varied and challenging projects. But it’s not exactly what I expected when, most of eleven years ago, I picked the tiny and at that time obscure Drupal project for the community sites I was building at a small NGO.

Image: "The Revolution Will Not Be Televised"> by **AB** is licensed under CC BY 2.0


[1] Jeff Robbins, “How Drupal Will Save the World,” June 20, 2007,
[2] Fergus Geraghty, “7 million reasons to consider democratising Drupal?” December 20, 2007, See also Nedjo Rogers, “Making Drupal fully ‘community-driven’: A Proposal for restructuring the Drupal project,” January 20, 2005,
[3] Peter Kropotkin, Mutual Aid: A Factor In Evolution, undated [1902]. Boston, Extending Horizons Books.
[4] “K. Marx: Drafts of a Reply”, in T. Shanin (ed.), Late Marx and the Russian Road, 1984. London, Routledge and Kegan, Paul, p. 114.
[5] “What is Copyleft?”,
[6] See
[7] “Expand Options in the Gender Profile Field”, March 24, 2010,
[8] BuiltWith top million site data come from Quantcast and are US-centric. For a detailed presentation on Acquia, Drupal, and the enterprise, see the webinar “Setting the Record Straight: Drupal as an Enterprise Web Content Management System,” by Dries Buytaert, May 19, 2014,
[9] Larry Garfield, “Dropping Forward,” Oct. 17, 2013,
[11] See “Core Developers,”
[12] “Drupal 8 Official Initiatives,”
[13] “About the Drupal Association,”
[14] “Governance,” and sub-pages.
[15] DrupalCores lists Drupal 8 contributors based on analysis of commit messages.
[16] “Recommendation for a New Governance Model,” downloadable at “Renewing the Organizational Structure of the Drupal Association,” July 11, 2011,
[17] See See also this discussion of decision making structure in Backdrop:
[18] bell hooks, “Choosing the Margin as a Space of Radical Openness,” Yearning: Race, Gender, and Cultural Politics, 1990, Boston, South End Press, p. 209.