Skip to Content


Stanford Web Services Blog: Overriding Open Framework Styles: Block styles, Sidebar Menus, and Regions

Planet Drupal - 7 April 2014 - 9:06am

In this post, I continue my series on how to override Open Framework's default styles to get a more custom look-and-feel on your site. Last time we looked at how to override our typography styles. Today, we'll look at a grab bag of other things, including block styles, sidebar menus, and region styles.

Categories: Drupal

Fred Parke | The Web Developer: Create your own tokens in Drupal 7

Planet Drupal - 7 April 2014 - 8:58am

Tokens are a pretty powerful weapon to have in your arsenal, and they actually come in useful a lot if you remember that they're there.

If you haven't used them before, tokens are essentially text placeholders - they can be static text, variables, field values, whatever you want really.

The Token API is now part of Drupal 7 core and as it turns out, using it to create your own tokens is super easy - you just need a couple of hooks.

The first hook, hook_token_info(), is used to declare any custom tokens.

Categories: Drupal

Appnovation Technologies: Accessibility in the Real World: Top 6 Automation Misses

Planet Drupal - 7 April 2014 - 8:25am
Making your work accessible shouldn’t be a optional deliverable; we have a duty of care to the real world of users to build this in as part of our work. No matter how good automated test tools are, they won't cover everything. Here are 6 points of consideration for accessibility. var switchTo5x = false;stLight.options({"publisher":"dr-75626d0b-d9b4-2fdb-6d29-1a20f61d683"});
Categories: Drupal

Bryan Braun: Making Targeted Drupal Cache Clears using Drush

Planet Drupal - 7 April 2014 - 7:21am

The standard Drush command for clearing Drupal's cache looks like this:

drush cache-clear all

(You can also use the shortened alias cc like this: drush cc all)

These commands give you the same result as when you click that cache clear button in the UI — it clears all of Drupal's internal caches.

But clearing all of Drupal's caches at once can be overkill. You usually don't need to clear everything, and doing so can put heavy load on your servers (especially if your site is large or gets a lot of traffic). Beneath the surface, Drupal's caching is actually pretty granular, and tools like Drush give us the ability to target and clear caches on the subsystem level.

Using Drush, you can see your caching options with:

# Using the shortened alias from this point on. drush cc

Which returns something like this:

[0] : cancel [1] : all [2] : drush [3] : theme registry [4] : menu [5] : css+js [6] : block [7] : module list [8] : theme list [9] : registry ...

Let's look at what each of these does (as a quick note, I'm specifically looking at Drush 6, which is the major version at this time):

drush cc all
Remember how I said that this does the same thing as the cache clear button in the UI? Well, that's technically false. Yes, drush cc all will clear all your Drupal caches (as long as it can bootstrap Drupal), but it will also clear its own internal Drush cache. That's why when Drush cannot bootstrap Drupal, you will still see a success command saying 'drush' cache was cleared.

drush cc drush
This only clears Drush's internal cache (the same one I just mentioned). You don't need a Drupal site available to clear this cache.

drush cc theme registry
This command simply calls drupal_theme_rebuild() to rebuild the theming system. This is needed whenever new ".tpl.php" files or theme hooks are added to the system. This specific cache clear only applies for Drupal 7 and up.

drush cc menu
This runs a menu rebuild, which refreshes the database tables used by various menu functions. For example, any new router items (like those defined in hook_menu) are added to the menu_links table, and stale ones are removed. This also clears the page and block caches, to prevent the display of stale menu links.

drush cc css+js
If you have CSS or JS aggregation enabled, this will rebuild the aggregated files. It also increments the query string on CSS & JS links, forcing clients that have cached an old copy to download a fresh one.

drush cc block
Block caching exists so Drupal doesn't have to look up the locations and visibility of blocks with each page load. This command refreshes that cache.

drush cc module list
This re-scans the module directories in your codebase and refreshes Drupal's internal list of which modules are available.

drush cc theme list
This re-scans the theme directories in your codebase and refreshes Drupal's internal list of which themes are available.

drush cc registry
Drupal maintains an internal registry of all functions or classes in the system, allowing it to lazy-load code files as needed (reducing the amount of code that must be parsed on each request). The list of these files is known as the "code registry" and it is stored in the system table in your Drupal database. This cache clear will look at this list of files and update the contents of any files that have been changed. Note: it will not rebuild the registry from scratch. For more information, see registry_update.

drush cc ?????
You may see other options in this list, because contributed modules (like views and advanced aggregation) can add their own kinds of cache clears. In each case, you'll see a file in the contrib module named something like that contains the code which defines what the cache clear does.


If you want to see what each of these options does on a code level, you can download Drush and inspect the file found at Drush/commands/core/

Categories: Drupal

Wunderkraut blog: Drupal 8 and the slow death of IE8

Planet Drupal - 7 April 2014 - 5:02am

IE8 is resisting to die. Internet Explorer 8 world-wide usage is more popular than IE9 and even IE10

First, a small story.Once upon a time, in 2012, when Drupal 8 was going to support IE8, we added HTML5Shiv to Drupal core to support HTML5 elements in IE8 and old browsers. But during 2013 things happened. jQuery decided to split their library into: 
  • jQuery 1.x (IE8, IE7, IE6 support)
  • jQuery 2.x (IE9 support and newer)
Both branches have the same jQuery API. This situation, clearly pushed the Drupal core maintainers into a big decision: Should Drupal 8 core ship with jQuery 1.x or 2.x ?. Nat Catchpole ("catch") summarized this dilemma very well:  And the community and Dries, decided almost at the same time to embrace ECMAScript 5, jQuery 2 and drop IE8 support. The change record was modified (to include IE8 as not supported). And we all rejoiced, specially front-end developers. Yay! To end this small story, I will link it to the beginning: there is a task pending about removing HTML5Shiv from Drupal core. All the IE8 issues are spread in, so it's nice that nod_ created a meta issue: Drop IE8 support.Present. 2014Looking back, it looks like dropping IE8 support was a good decision. This allowed core developers to write more efficient CSS3 and ECMAScript 5 code. And we avoid to waste the valuable time of core developers supporting old browsers. We jumped on the bandwagon of modern JavaScript libraries.  As I said sometimes, the biggest change in Drupal core front-end is not Twig, it's Drupal core dropping IE8 support. The only big problem is that IE8 is dying very slowly. During the discussions in 2012-2013 we thought that IE8 usage will drop fast (we wanted to believe that). But the reality hurts, This is a chart from StatCounter (IE8 has a 4.71% usage. IE11 is not available in the chart, but it has a 6.29% usage in March 2014):  From, the trend is even worse. IE8 has still 21.14% of the browser share on March 2014. 
I hid other browsers in the charts to highlight the situation with Internet Explorer.But one thing is clear: IE8 seems to be more popular than IE9, IE10 and even IE11. This is mainly due of Windows XP users. Why the difference between StatCounter and Netmarketshare?They have different methodologies.  As I understand, netmarketshare manipulates their data to make them more realistic.They are adding a country level weighting, based on how many internet-users the country has, even if their data samples are tiny. So that could distort a bit their data. But the good thing in netmarketshare methodology, is that they count users not traffic. (the same user is only counted once per day, no matter how many page loads she makes). In the other hand StatCounter counts page visits, not users. For example, for StatCounter, an internet-savy teenager  loading hundreds of pages per day in Chrome, counts the same as 100 hundred "grandpas" that are loading once a day their local newspaper in IE8. There is no winner. Both charts are correct, since they represent different things. But the truth is that there is a lot of people outside there using IE8 today. The hopeEveryone hopes that IE8 dies faster, including Microsoft. Two positive notes:
  • Tomorrow, 8th of April, Microsoft is announcing the drop of Windows XP support. No more updates. 
  • IE8 doesn't exist in mobile phones. The trend is that mobile browsers are eating desktop browsers usage, around the world. 
Non official FAQ. Drupal & IE8What if you try to load a Drupal 8 website with IE8? IE8 won't support many CSS3 stuff and EcmaScript 5 code. So a broken layout and lost JavaScript funcionality will be the normal thing to see. Drupal will load jQuery 2.x (that uses addEventListener method), IE8 will complain about it, stop parsing jQuery, and all your jQuery code won't work because "SCRIPT5009: jQuery is undefined". What if a customer asks for IE8 support?Stick to Drupal 7. The other option is to use a Drupal 8 and the work-in-progress-contrib-module IE8 Drupal module, that should downgrade jQuery to 1.x branch and include lots of polyfills to support ECMAScript 5 in IE8. Personally, it sounds to me too "magical",  that it could fix all CSS and broken JS, specially if your site has many contrib modules. But for sure, it will help. Also notice that Drupal helps the situation a bit,  including "X-UA-Compatible" http header to force IE use the most recent IE engine. What if I'm maintainer of Drupal module or theme? Drupal's core decision is pushing "gently" all the contrib modules and themes to follow the same path. When porting your modules, JavaScript code, etc make sure it works well with jQuery 2.x API. If you’re upgrading your Drupal 7 jQuery code from a version older than 1.9, jQuery team recommends to read the jQuery 1.9 Upgrade Guide since there have been a lot of changes, and help yourself using the jQuery Migrate plugin. Once that is migrated to 1.9, it will be compatible with jQuery 2.x, because they should have same API. Corrections welcomePlease, comment in this article, correct me in case I did wrong assumptions and I will update the post with the most up-to-date information.
Categories: Drupal Drupal Dev Days Szeged - Initial Sprint for Search API Drupal 8

Planet Drupal - 7 April 2014 - 3:02am

I’ll tell you in a small prelude a story of a small place in the world named Szeged and why it holds a special place in my heart for me (Nick_vh). When I was job-hunting about 5 years and a half ago I found many companies willing to offer me a job after graduating but the one company I chose was willing to take a huge bet on me and offered me a job + an instant trip to Szeged, Hungary. It seemed that that was the location of the gathering of the Drupal Community in 2008. They said it would be amazing and I never looked back since then and I am still connected to the same and growing Drupal Community.

Going back to Szeged promised to be a lot of nostalgia and a lot of fun also.

Looking back

For those that just tune in on this story of the Search API Drupal 8 port, there is some reading to do.

In short: “Contrib Search maintainers are committed to make Drupal 8 kick ass with Search API.”

This is also exactly what we wanted to prove on this wonderful trip to Hungary.

What our goals were

Thomas and I already agreed this week in Szeged would be the first of a series of sprints to get Search API to a decent state in Drupal 8. As you can read in the Search API for Drupal 8 sprint entry for the Drupal Dev Days  the goals were the following: “The primary focus will be to get the Search API to a usable state in D8 and then decide on and implement framework improvements”

We discussed and talked about what needed to happen but in true community style, not many words were needed to get the first port started and so it happened that, even before all of this, freblasty started a sandbox and already ported a good chunk of the Drupal 7 code to well factored Drupal 8 code.

There was a sign up sheet for the sprints and to our surprise a LOT of people signed up for the sprint. I’ve masked the last names to protect their privacy, so they can opt-in on the exposure of their full name. Drunkenmonkey also prepared a nice list of meta issues that mark the Drupal 8 state before the sprint.

Plan of attack

Some of us already arrived early Monday, the other half arrived Monday afternoon. The team was already hacking away on the code when we decided to use a Google Doc that would semi-coordinate the progress. Process was simple:

  1. Raise your hand and say your name and that you wanted to help out
  2. You were given commit access to the sandbox
  3. Choose a task from the “To Do” in the collaborative document
  4. Solve it and commit it
  5. Say “I committed, please pull!” and do a little Ski-Dance (ask Aspilicious for specifics)
  6. Go to 3 and repeat until Sunday afternoon.

We purposefully supported this simple plan of attack because adding more process would block people from making progress and we figured it was better to break all the things than to block people from helping out.

The attack itself

II’m not going to waste a lot of empty words here but let the hard work/visuals speak for itself.

  • During the whole week we’ve had 322 commits.
  • Heaviest hours were from 09:00 till 19:00 and then it went up again from 22:00 till 24:00. Thanks to freblasty we even had commits during the middle of the night, 9 of them at 04:00.
  • Wednesday was our most productive day with 75 commits. Saturday was our low point with only 36 commits, I guess that has something to do with the party on Friday evening…!
  • 20834 lines were added, 11996 were removed

In total we had 15 contributors!!!! We’ve listed them by # of commits but by no means this means that the ones with more commits worked harder.

  1. drunkenmonkey            55    (15.62%)
  2. mollux_                51    (14.49%)
  3. Nick_vh            46     (13.07%)
  4. aspilicious            43     (12.22%)
  5. Andrew_l            38     (10.80%)
  6. freblasty            34     (9.66%)
  7. ekes                23     (6.53%)
  8. m1r1k                18     (5.11%)
  9. dpovshed            17     (4.83%)
  10. Andre-B            12     (3.41%)
  11. baldwinlouie            7     (1.99%)    
  12. sdecabooter            3     (0.85%)
  13. penyaskito            3     (0.85%)
  14. tstoeckler            1     (0.28%)
  15. pcambra             1     (0.28%)
Drupal 8 Codebase versus Drupal 7 codebase

A quick preview ofthe differences in terms of files of Drupal 8 vs Drupal 7.


Future plans

For now, work continues in the sandbox until the basic functionality is working. Also, mollux is already working on a port of the Database Search backend, which will allow us to test the module with a real search backend.

Once the functionality is stable and we get into improvement/feature-adding mode, the project will be transferred back to the 8.x branch of the proper search_api project and work will continue in the normal style of patches and issues. (Issues for the individual tasks from the Google document have already been converted to issues in the sandbox’s issue queue as of last meeting).

Weekly Meetings on Hangout & IRC

We also set up a weekly meeting in the form of a Google hangout, every Tuesday at 18:00 UTC. Please contact us if you want to be invited, everyone who wants to help with this project is welcome!

Other than this, there is also the possibility of discussing and coordinating via IRC. We are using a special channel, #drupal-search-api on Freenode <irc://freenode/drupal-search-api>, where you can also just join in and ask around if you want to get involved.


Many many many thanks to all those involved in the sprint. We understand this takes a big personal commitment and passion to focus so hard on complex problems to drive the next generation of Drupal Search. Also many thanks to all companies that sponsored the time and funds for allowing those people to be there. I hope this blogpost can help your company to convince them to send you to these events. It's educational, helpful and will lift you and your company to a higher level.


Proof of the team in Szeged, hard at work

Categories: Drupal

Web Omelette: Adding Facebook Open Graph tags to your Drupal site

Planet Drupal - 7 April 2014 - 12:10am

In this article we are going to look at implementing the Facebook Open Graph (OG) tags on a Drupal site. It involves a bit of coding but nothing too major so bear with me. All the code we are going to write goes into the theme's template.php file so no need to to create a module for it. And if your theme does not yet have this file, go ahead and create it.

Why use Open Graph tags?

I'm sure by now you know that people share pages on Facebook and you want your site to be shared as much as possible. You also know that a little teaser information is made available on Facebook when you share these pages (title, image, short description).

But have you ever noticed that with some sites, when you share pages on Facebook, or like/recommend them, some random, unintented image gets used in this teaser. Or the description is not correct, or even the title is not right. Facebook is quite good at picking the right elements to show there but sometimes it doesn't manage by default. And you can't expect the random user who shares your page to make adjustments to the text or title. So what do you do? You use Open Graph meta tags.

What are the Open Graph meta tags?

These are simple <meta> tags that you put in the head of your site to specify which elements should be used by Facebook for various purposes. For instance, you specify a link to an image and then Facebook knows exactly which image to use when building the teasers. The same goes with the title, description and many others.

The tag is quite simply structured. It contains a property attribute in which you specify what this tag is for and a content attribute where you specify what should be used for this property. Let's see an example for the title:

<meta property="og:title" content="This is the article title" />

Simple. You'll also notice that the property attribute value is preceeded by og:. This stands for Open Graph and Facebook will recognize it as such. Here are some examples for other more common OG tags:

<meta property="og:url" content="" /> <meta property="og:site_name" content="Web Omelette" /> <meta property="og:type" content="blog" />

The first one is the canonical URL for the page, the second is the site title and the third is the type of site.

But how do we add them to Drupal?

I wrote a while back an article on this site in which I looked at how you can add your own custom tags into the <head> of the site. And there we learned that we use the drupal_add_html_head() function inside of a preprocess one to achieve this.

So let's say that our Article nodes don't show up properly in the Facebook teasers and we would like to specify OG tags for the title, image and description. We will do this in the theme's template.php file inside of the template_preprocess_node() function:

function theme_name_preprocess_node(&$vars) { }

Inside this function we get access to the node information being loaded and we can test to make sure we are adding our OG tags only to the pages that load these nodes:

// If the node is of type "article", add the OG tags if ($vars['type'] == 'article') { // Inside this conditional, we define and add our OG tags }

First, let's create the title tag, the simplest of them all. It will be represented by the node title:

$og_title = array( '#tag' => 'meta', '#attributes' => array( 'property' => 'og:title', 'content' => $vars['title'], ), ); drupal_add_html_head($og_title, 'og_title');

If you remember from the other article, this is how we create a new meta tag in the site header. We define a renderable array that describes the tag (type and attributes) and we use the drupal_add_html_head() function to set it. Simple. Now if you clear the cache and go to an article page you'll notice in its source a new tag:

<meta property="og:title" content="The title of the article" />

This was simple. Let's see how we can extract the image URL and specify it inside a new tag for the image Facebook will use:

$img = field_get_items('node', $vars['node'], 'field_image'); $img_url = file_create_url($img[0]['uri']); $og_image = array( '#tag' => 'meta', '#attributes' => array( 'property' => 'og:image', 'content' => $img_url, ), ); drupal_add_html_head($og_image, 'og_image');

So what happens here? First, we use the field_get_items() function to retrieve the field called field_image from the loaded node. This will return an array of one or more images (depending on how the field is set up and how many images are in it).

Next, we use the image file URI inside the file_create_url() function to turn it into an absolute URL. Then, just like above, we create the renderable array with the og:image property and the image URL as the content. The result will be:

<meta property="og:image" content="" />

Finally, let's see how we can get a small chunk of our body field and use that as a description for Facebook:

$body_field = field_view_field('node', $vars['node'], 'body', array('type' => 'text_plain')); $og_description = array( '#tag' => 'meta', '#attributes' => array( 'property' => 'og:description', 'content' => text_summary($body_field[0]['#markup']), ), ); drupal_add_html_head($og_description, 'og_description');

Instead of using the same function as when we retrieved the image field earlier, we use field_view_field() in this case. The reason is that it already prepares the body for output and we can specify a text format to use. We want to use plain text to avoid printing all the HTML markup that is usually found in the body field.

Next, like above, we create our renderable array. Only this time, we also use the text_summary() function to trim the text down to a reasonable default of 600 words (the defaul teaser length on the site). If you want to specify a different length, you could pass it as the third argument, like so:

text_summary($body_field[0]['#markup'], NULL, 100),

This will trim it to 100 words. One thing I noticed about this function however is that it doesn't trim nicely. It will end the chunk in the middle of the sentence even if its API says it will try to find a sensible place. For this purpose it doesn't really matter because Facebook will trim it down anyway to a shorter version.


So there you have it. Now you can use the Open Graph meta tags on your Drupal site to let Facebook know about your content. It's a handy social helper that can greatly improve your social presence by making your site more appealing on Facebook.

In Theming | Drupal var switchTo5x = true;stLight.options({"publisher":"dr-8de6c3c4-3462-9715-caaf-ce2c161a50c"});
Categories: Drupal

Harry Slaughter: One revision control system to rule them all

Planet Drupal - 6 April 2014 - 7:18pm

The first revision control system I ever used was called RCS. It was the pre-cursor to CVS and stored all revision data locally. It was nifty but very limited and not suited for group development. CVS was the first shared revisioning system I used. It was rock solid, IMHO. But it had a few big problems, like the inability to rename or move files. Everything had to be deleted and re-added. 

Since those days, I've used several other revisioning systems: Perforce, Bitkeeper, Clearcase, Subversion and GIT.

read more

Categories: Drupal

High Rock Media: Drupal 8: Attaching Core Libraries and Other Scripts to Your Theme

Planet Drupal - 6 April 2014 - 4:54pm

For the past six months, I've been in the process of porting my contrib theme, Gratis, to Drupal 8. One of the challenges for contrib is Drupal 8 has been a constant moving target in terms of API changes. With every new Alpha of Drupal 8, I've had to adjust many bits of theme code to adhere to these new APIs.

One of the biggest challenges has been figuring out how to add jQuery and other core scripts into the theme. That's because off the shelf, Drupal 8 does not add these for anonymous users. This seems like an odd choice by core but my guess is that is was done for Drupal 8 to be more minimalistic and nimble on its feet.

At any rate, if you have a contrib theme, most likely the first thing you'll do is add all of these back in to bring it back to a point where Drupal 7 was. To add an additional layer of complexity to all this is the fact that the manner in which this is done has changed dramatically in recent weeks.

Exit nested arrays, enter YAML

At first one added core libraries using hook_library_info which was a mess of PHP nested arrays in your theme's .theme file. Now, in true Drupal 8 fashion, we do this with a .yml or "yaml" (rhymes with camel) file. YAML is an acronym for "Yet Another Markup Language" or "Ain't Markup Language" and has become a core method for streamlining code in Drupal 8.

Here is a basic example of how you can add jQuery to a theme and a few dependencies. You'd do this by creating a *libraries.yml file in the root of your theme. So in my case my theme name is foobar so the file name would be foobar.libraries.yml.

  version: VERSION
    js/scripts.js: {}
    - core/jquery
    - core/drupal.ajax
    - core/drupal
    - core/drupalSettings
    - core/jquery.once

With the above code, we'll be adding the core scripts jquery.js, drupal.js, ajax.js and jquery.once.js to our theme. This will make it available for anonymous users. With YAML, indentation spaces are relevant so you'll need to get that bit right. In addition, we are calling a theme relative script in the theme's js folder, scripts.js. The name -corescripts can be anything you want as long as it matches when you go to attach it in your .theme file as outlined below.

Attach the Library

The next step to actually attach the library we created with a theme preprocess function creating a variable in combination with the #attached method.

 * Override or insert variables into the page template.
function foobar_preprocess_page(&$vars, $hook) {
  // Render the library we defined in foobar.libraries.yml
  $libraries['#attached']['library'][] = 'foobar/foobar-corescripts';

Attaching the library above implements provider-namespaced strings i.e. 'gratis/foobar-corescripts' where previously it had an array associated with it. This is new in Drupal 8 Alpha 10 and it through me off for a while until I found a core issue that documented this change. Finally, we use function drupal_render to render the new library.

What's Next?

In a future Drupal 8 related articles, I'll get in to setting custom configuration for your Drupal 8 theme, this comes in real handy and we'll be using YAML with the added addition of using Drupal 8's CMI layer. I'll also talk more about API changes as they relate to themers, it's probably safe to do that now as Drupal 8 is most likely heading toward a beta within the next few months and it seems like many of the major core API changes have been done.

  • Drupal
  • YAML
  • Drupal 8
  • Drupal Planet
  • Theming
Categories: Drupal

David Herron: Stopping server overload, cleaning up the site front page, disabling comments, and general goodness

Planet Drupal - 5 April 2014 - 11:09pm

The last few days the server hosting this site was overloaded, and I finally took a look at the access log, saw a continuous stream of requests that shouldn't be occurring, and realized the "links" row of teasers on the front page needed to go away. The default links row includes one reading "Log in to post comments" but this blog doesn't allow anybody else to register for an account, and in any case comments are handled by Disqus rather than Drupal's commenting system. The link didn't need to be there at all, and the more I looked at the links row the more useless it looked.

Categories: Drupal

Unimity Solutions Drupal Blog: Where do you find the Software working group?

Planet Drupal - 4 April 2014 - 11:33pm

Did you know that the Software working group appointed by the Drupal Association provides co

Categories: Drupal

David Herron: Do 3rd party commenting systems (Disqus et al) support my community, or theirs?

Planet Drupal - 4 April 2014 - 5:45pm

It used to be that Web 2.0 was the cool new thing, and a core feature was that the audience could leave comments on websites. It's common nowadays for websites to support comments, and comment areas have become (in some cases) a war zone full of partisan bickering. It was ground-breaking the 10ish or so years ago that websites began to support 3rd party comments. Really.

Topics: Online CommunityDrupal PlanetDisqustechsparx
Categories: Drupal

Drupal Association News: team week notes #23: Drupal Dev Days Szeged

Planet Drupal - 4 April 2014 - 1:05pm

This week’s notes will be all about something unique, which happened last week: a 7 day long sprint for

Personal blog tags: week notes
Categories: Drupal

Midwestern Mac, LLC: DrupalCon and DrupalCamp news + free DrupalCon ticket!

Planet Drupal - 4 April 2014 - 7:19am

This week, the DrupalCon Austin sessions have been posted, and I'm thrilled to have one of my session submissions (in the DevOps track) selected: DevOps for Humans: Ansible for Drupal Deployment Victory!.

The session will go over how Ansible can be used to realize faster, easier, and more successful Drupal deployments, as well as Ansible's ability to make sure that every environment is 'like production', so you don't ever have surprises when you deploy code to its final destination.

Categories: Drupal

Wunderkraut blog: Getting Acquia certified

Planet Drupal - 4 April 2014 - 4:42am

So I am an Acquia Certified Developer as of this week. Do I feel any different ? Not really, but i’m glad I did the test a couple of days ago, as it kinda gives you a personal status update on your global Drupal knowledge. Here’s the rundown of my experience.

Getting started

There are already a bunch of blog posts popping up sharing experiences about taking this test, even on our own Wunderkraut blog. But there are two posts I read before doing the test myself which are worth spending your time on: a post by webchick and an article by Tanay Sai. The latter has a nice overview of all the different fields of expertise, with some links to relevant documentation.

Setting up the test was actually quite a breeze. OK, you have to install the Sentinel software package, and you can’t use Chrome, but other than that I had no problems getting started using a Mac. To tell you the truth, I was expecting worse, and the fact that I managed to schedule the test only a few hours earlier was a nice suprise as well.

Doing the test

Well, as Angie recommended, I made sure I went to the bathroom and had plenty of liquids in arm’s reach.

Starting the test, you have 90 minutes for 60 questions, which are all multiple choice. Some questions were actually hard to grasp from the first read. Maybe it were the nerves, but I do remember a couple of questions where I only got the question after reading it for the second time. So do take your time, although you may be pressured by seeing the time ticking away on the exam screen.

The content of the test is quite broad. Being served frontend questions as a mainly backend developer is a good way of knowing what the state of your general knowledge is, outside what may be considered as your comfort zone. So if you never did any theming work, i’d recommend looking into the theming basics. 
And actually it’s the other way around as well. You’re a sitebuilder/themer? Check out some backend basics too.  

The questions can be tricky, giving multiple similar options which can make you doubt at times. Especially in these days of IDEs doing all the code completion work for you, you do need to have a clue about the inner works of Drupal.

Another thing is that the (code) formatting of the questions proved to be a issue in some cases, as it made it hard to distinguish all the different options.


I completed the test in about 60 minutes, even with reviewing some flagged questions. In hindsight, I should have taken more time, as I still had half an hour left and could've upped my score I guess. But it’s good to know that following my gut feeling, I went through the whole thing just fine. So now it's up to you.

Categories: Drupal

Acquia: Drupal 8 + Symfony - "This is what open source is all about"

Planet Drupal - 4 April 2014 - 4:11am

Part 1 of 2 - I spoke with Richard Miller and Tom Kitchin, software engineers at SensioLabs UK and its parent company Inviqa respectively, via a Google Hangout on Air recently. I wanted to learn more about PHP and Symfony from their perspective and how they think the Drupal 8 and Symfony2 are going to affect each other. In part 2, I learn the inside story on one of the first Drupal 8 sites online,, what their goals were and how they built it and have kept it running since May 2013, and how Drupal 8 will change the way they design applications for clients going forward.

Categories: Drupal

Wunderkraut blog: Grumpy Swedish developer gets tilted and need to change his name

Planet Drupal - 4 April 2014 - 3:42am

So we got an old windows computer setup to do the exam. Could install teh software needed, launched Sentiel to setup up my profile, and I was told to write my name to test my speed on the keyboard. So I entered my name, and “WRONG!”. Got a password error sign. Now I got confused, I was not told enter my password. But ok, so I entered my password. “WRONG”. I tried to write my name again. “WRONG”. Bullocks.

I tried to contact support from Sentiel application. A chat window opened, and I got a welcome message from the support, nice. So I started to write  my question about the password warning error thing. I did a typo in the question, hit backspace, and Abrakadabra, my screen got tilted, and were now laying on the side. WTF. I guess some software error and mismatch on the Windows computers soft- or hardware. I guess software, you know, it’s Windows.

Opened the control panel, got the screen on right side again, and started to write in the support chat again after starting a new session. And Abrakadabra. Tilted screen. Maybe its a feature….

So I started thinking instead. You got to have a US-keyboard to do the test, and maybe Sentiel just doesnt love my lastname, Schirén. I suspected é here. So I changed the spelling of my last name, with and “e” instead. And yeah. That worked.

Doing the certification text in 20 minutes, let’s see what happens.

EDIT: I passed. Now I am an Acquia Certified Developer. But still a little bit grumpy. I will come back on the issue next week.

Image: "Confused" by Slava

Categories: Drupal

alexpott: What next for me? Drupal 8 funding and more

Planet Drupal - 4 April 2014 - 1:26am

It's been a year since I quit my job to work on Drupal and play with Jack. Many amazingly special things have happened to me. I still remember falling off my seat when Dries asked me to be a committer and lying awake all night with excitement whilst I "slept on it".

Without the Drupal community's support I would have had to return to work much earlier. With everyone's donations through gittip, two companies' financial support and my own savings, I've been able to continue working full time on core. However my savings are diminished and the corporate sponsorship only lasts until 18th April. Fundraising month to month is more than a little stressful when a family is involved. Therefore I plan to take some form of employment. Hopefully I will be able to find some interesting work starting at the beginning of May.

Whatever type of job I take it is important to me that I have the ability to continue to contribute as much as possible to Drupal 8 and have time for my family. What will happen to my gittip? This depends on the type of job I take. If I take a contracting job where I work less than a full work week I will reset my target so that it'll amount to extra time I will work on core. If I take a full time job that allows me to work on core I plan to create a gittip team called "Drupal Core" to which I will transfer all my gittip earnings to this. Obviously, people are free to redirect their gittips as they see fit.

Fundraising and Drupal

There are companies using Drupal that are willing to contribute to core even though the immediate benefits are not tangible. One of the companies that has funded me since December is a Drupal user, but not at all focussed on Drupal development. The only condition for receiving the money is that I do not disclose their name. This is because it is not easy from an accounting perspective for a company to donate money to an individual.

We all know that core is more complex than ever and the interests in Drupal larger. Sustaining Drupal core development is a key challenge for the community. I think we need to seriously consider extending the Drupal Association's remit to be able to coordinate the collection and distribution of funds from major Drupal users for Drupal core development. If this is impossible then this does not mean we should not still try to solve the problem.


Feel free to contact me if you have an interesting job offer - especially if it involves Drupal 8.

Lastly, thank you to everyone for your wonderful support.

Categories: Drupal

Change(b)log: Commerce Marketplace: Installation and use cases

Planet Drupal - 4 April 2014 - 12:52am
This tutorial will guide you through all the steps required to replicate the Commerce Marketplace demo site on your own server, and then explain how its behaviour differs depending on various configuration settings.
Categories: Drupal

Darren Mothersele: Drupal Theme Generator Update

Planet Drupal - 3 April 2014 - 4:00pm

It's been a week now since I demoed my proof-of-concept for an automated theme generator at the Drupal show and tell event so I thought I'd collect together the feedback I've received so far and post an update.

Wrong Approach?

Almost unanimously positive feedback. In fact, it seems other people have been thinking along similar lines:

@mothersele dude! just saw This is something that @jenlampton, @mortendk, @Cottser and I have discussed for 8.x twig!

— Mark Carver (@mark_carver) March 29, 2014

The one opposing view I have encountered wasn't actually against any of the ideas in the theme generator, but suggested that taking over Drupal markup was wrong and that we should be working with what Drupal provides. I know there are arguments for this, and if you want to go this route then you will need some other mechanism for documenting the conversion of your design to Drupal theme. If you want to argue this case, I'd suggest first try having that discussion with Morten, as I'm going to assume that we're all OK with the concept of taking complete control of (completely rewriting) Drupal's markup output.


In an earlier prototype I had started working with annotations inside HTML comments but I found these increasing harder to parse as the extractions became more sophisticated. Someone in conversation brought up ideas from KSS and suggested looking at CSS comments as an alternative.

I'm still proposing this as a possible approach (see Docblock), but for now I'm going to continue to annotate the markup (not the CSS) with x- attributes, as no one has had an issue with this, and at this stage it's easier to work with QueryPath to create the extractions based on these attributes. It seems that annotating the markup with x- attributes will be acceptable as long as they are stripped from the markup during the build process.

@rootwork @illepic @micahgodbolt @EvanLovely @mothersele Interesting! Do the data attributes get stripped out during the build step?

— Brad Frost (@brad_frost) March 28, 2014

It was great to get feedback from Brad Frost as his work on Atomic Design has been influential in the development of this process.

In code, or config

In this first proof-of-concept, the generated theme is held in memory, well actually it is persisted as a Drupal variable containing a single object that holds the result of all the 'extractions' from the source. The original intention was that this would actually be a ctools exportable, so that it could be exported and managed as part of the configuration management process for the site.

This is how the Panels flexible layout builder works. It has one parent layout plugin that programmatically declares child layout plugins based on the layouts you define using the layout builder tool. These child layouts are stored as exportable objects, so they can be exported using Features. The current Hyde theme generator approach is similar, except that the parent plugins (for layout or styles) programmatically declare child layout and style plugins based on the result of each extraction from the HTML source design.

Storing the result of the build in configuration or database raised some concerns, mainly over capturing the results in version control. These tweets summarise the issue:

@mothersele interesting implementation. But I believe that should definitely generate theme in code, not just DB @mcjim @MattFielding

— Tom Bamford (@waako) March 28, 2014

@waako If a prototype is always in sync with a Drupal theme, the markup *is* all in code right? // @mothersele @mcjim

— Matt Fielding (@MattFielding) March 28, 2014

Matt picks up on my original intention, in that the design/theme would be captured in code and be version-able because the translation is automatic from the design's HTML/CSS/JS.

The difficulty is in managing any changes that happen to the generated code once it becomes a Drupal theme. This is exactly the problem that using the theme generator is trying to solve. That it provides a documented, repeatable conversion process, so that design can become part of the (agile) development workflow.

However, it is going to be unavoidable that some tweaking will be needed. This covers a couple more issues that were raised at the Drupal show-and-tell event:

  • How to manage logic in template files?
  • How to capture Drupal's pre-process functions?

The approach I am looking at to solve this, is one I've seen practised by other tools that involve code generation. For example, have you seen BDD using Behat? When define a test scenario in Behat it generates stub code for any unrecognised steps in your tests. For example, if you say "Given I am in a directory", you would get the generated stub code:

/** * @Given /^I am in a directory "([^"]*)"$/ */ public function iAmInADirectory($argument1) { throw new PendingException(); }

I think the theme generator could do something similar for elements marked as requiring pre-processing in the template file. This needs some further thought and perhaps a couple of experiements.


Still struggling with naming conventions. If this is going to be a more general tool then need generally understandable terms (like 'component'). But, need to avoid overloading terms even more, as it's already quite confusing having SMACSS modules, Drupal modules, panels, blocks, boxes, styles, layouts. urgh!

Next steps...

@mothersele @mark_carver I love it. Also love that it works w/ panels! Q: Are the layout plugins placed in the theme? @mortendk @Cottser

— Jen Lampton (@jenlampton) March 31, 2014

So, I'm going to revise the current proof-of-concept and produce a second prototype. This time as a Drush command that generates an actual Drupal theme. Rather than holding the extracted theme in configuration it will generate a theme folder, that will include all the usual Drupal theme files, plus any plugins for Panels layouts, styles, display suite etc, and the CSS/JS copied across from the source design.

This will allow Hyde to generate stub code for pre-processing or other programmatic tweaks that are needed to get Drupal's output to match the design markup. I also think people will be more accepting of this approach as it's probably more like how it is expected to work.

My worry is that people will then hack the generated theme, it will go out of sync with the source design markup, and that will break the whole process.

If you want to get involved, please drop me a line. I need input from designers, themers, and developers. In particular, I'd be interested to speak to anyone else already using Atomic Design and/or SMACSS on Drupal projects.

Categories: Drupal
Syndicate content

about seo