Subscribe to feed Planet Drupal - aggregated feeds in category Planet Drupal
Bijgewerkt: 12 uur 14 min geleden

Ryan Szrama: Why not combine shopping carts on user login?

za, 2015/01/31 - 8:06pm

When I first wrote Ubercart's Cart module, we knew we were going to support both anonymous and authenticated shopping carts and checkout. The decision came at a time when there wasn't consensus around the impact of forced login on conversions, but we knew we wanted it to be optional if at all possible. Additionally, for authenticated users, we wanted to preserve items in their shopping carts so they would see the same items when logging in from multiple devices or across multiple sessions.

This resulted in a small conflict that we had to figure out how to deal with: users could have items in their authenticated shopping carts but browse the site anonymously, create a new shopping cart, and then log in. What should happen to the items in their authenticated carts vs. the items in their anonymous carts?

There are three basic resolutions: combine the shopping carts together so the user still has a single shopping cart, remove the items from the previous session and leave it up to the customer to find them again if desired, or retain the old shopping cart but ignore it until the customer has completed checkout for the current cart. In Ubercart, I chose to combine the items, but in Drupal Commerce I changed course to retain the old cart but, from the customer's point of view, treat that anonymously created cart as the current cart after login.

We got some push back for this decision, but ultimately I didn't change the default functionality of Drupal Commerce. We just made sure there was an appropriate hook (hook_commerce_cart_order_convert()) so developers could alter this behavior on a site-by-site basis as need be.

From the merchant's standpoint, the thinking behind combining carts goes that you don't want customers to forget they intended to purchase those products in the past. However, from the customer's standpoint, suddenly having additional items in the cart after logging in during the checkout process is quite jarring.

In fact, I've been bitten by this behavior when shopping online at Barnes & Noble. Weeks prior to placing an order, I had put a Wheel of Time novel in my shopping cart but eventually bought the book in store. When I came back to the site to purchase a gift for my wife, I used a login button on the checkout form to quickly reuse my previous addresses and payment details. Unbeknownst to me, the website combined my old shopping cart with my current one such that my "quick checkout" experience made me accidentally order a book I already owned! I then had to spend 30 minutes with customer service canceling the order and placing it afresh just for the book I actually wanted.

That experience confirmed in my mind we made the correct decision not to combine carts automatically. As eCommerce framework developers, we have no clue where a developer might like to integrate login during the checkout process. Best to let them decide if it's safe to do something with those previous cart items instead of silently making the decision for them.

That said, I believe we can improve the experience. Right now, Drupal Commerce retains the old shopping cart order, and after the customer completes checkout they'll see the previous shopping cart as their current cart. This can be confusing as well! My ideal situation would likely be a user interface component on the shopping cart page where customers can see items they had added to their carts in previous sessions, giving them the option to add those products to their current carts. If they decide not to, I don't see any harm in then just deleting those historical carts and moving on.

There's always room for improvement.

Photo credit: alphageek


KatteKrab: How does Drupal use these different terms? Route, Path, URL, URI, Link, Menu item

za, 2015/01/31 - 2:29am
Saturday, January 31, 2015 - 12:29

Sometimes, diving in to try and help work on something in an open source project can leave you feeling stupid, lost and confused. Generally, you'll find you are not alone. Sharing the problem, and the solution when you find it, can be helpful to build your own understanding, but also might help others too. So, just in case I'm not the only one feeling lost and confused about why the path / route / link issue in Drupal is so complex, I thought I'd share some of my confusion and a little ray of light that might help unravel this tangle of related terminology.

In the Drupalverse, we use IRC to connect with each other.  So I popped into channel and asked:

Can someone describe how drupal uses these terms? route, path, url, uri, link, menu item - or point me to a reference?

Angela Byron generously responded with a rough outline of definitions, which I've fleshed out a bit below with some references.


"this URL goes to this PHP code, and can only be accessed by these kind of people."
As far as I can tell, this is a relatively new concept for Drupal with routing and controllers, replacing the hook-menu system we had previously. Here's a couple of references that might be helpful if you want to build a deeper understanding.


Uniform Resource Locator eg. "" It's generally the address we use to find content on the web.


Uniform Resource Identifier is often confused with URL because it's so similar. See the URI wikipedia page for more information. I'm not sure if or how Drupal distinguishes between the use of URIs, URLs and URNs (Uniform Resource Names), but let's save that yak to shave on another day.

The Build a module team made a video that describes the difference between a URL and a URI
What the difference is between a URI and a URL (a Drupal how-to)


The path is like a pathway to find content eg. admin/content but because it can be an alias, it may not actually represent the location of a file on disk, which helps lead to some of the complexity under the hood in Drupal, and the confusion about when to use, /blog/yakshaving, or node/5


<a href="/foo">foo</a> - This one seems pretty straightforward - it's the HTML markup used to point to a URI or path.

Menu item

A link in a menu - which could be pointing to a route, path or URI.

Hope that helps you, it certainly helps me to lay it all out like this. And, just in case you're wondering how I fell down this rabbit hole, this relates to a series of critical issues holding up the release of Drupal 8.  If you can help, please get involved  or buy a ticket in my chook raffle to help fund the Drupal 8 Accelerate initiative.


Drupal Association News: Help us welcome our four new staff members

vr, 2015/01/30 - 10:06pm

The Drupal Association is thrilled to announce the addition of four new staff members. As part of our goal to increase Drupal adoption and provide the community with strong support and advocacy, the organization has been growing at a rapid rate over the past year. Now, we’re welcoming four new staff members into the fold. Please help us say hello to Elise, Lucia, Rachel, and Tim!

Elise Horvath, Operations Team, Operations Coordinator

Elise (EliseH1280) is joining the Operations team as an Operations Coordinator. She will manage key details of the Drupal 8 Accelerate program, will manage the Drupal Store, will assist Operations with any accounting needs, and will assist the board of directors by managing meetings and schedules and taking meeting minutes. Prior to joining the Association, Elise worked in logistics and operations for scrum training services. When not working, Elise enjoys spending time with her fiance, watching movies, cooking and baking, riding her bike, and going to Disney World whenever she has the chance!

Lucia Weinmeister, Revenue Team, Sponsor Fullfillment Coordinator

Lucia (lweinmeister) is the Association’s new Supporter Fulfillment Coordinator, and will be working with the revenue team to ensure that all our Supporting Partners, Hosting Supporters and Tech Supporters get the most out of their sponsorships. Lucia is one of three Austin, TX-based Association employees, and comes to the Association with a marketing and advertising background. Lucia was born and raised primarily in Mexico City, is fluent in Spanish, and enjoys reading, running, doing Crossfit, cooking, and chasing around her two sons, Bruce and Leon.

Rachel Rivera, Revenue Team, Junior Account Manager

Rachel (rayn1ta) grew up in the San Francisco area and spent four years living outside the US in Latin America, Asia, Africa and Europe. She has worked as a ski instructor, English teacher, and digital marketer. In addition to learning foreign languages, she enjoys yoga, hiking and scuba diving. As a Junior Account Manager with the Drupal Association's revenue team Rachel will focus on identifying and satisfying the needs of awesome Drupal Businesses.


Timothy Constien, Community Programs, DrupalCon Sponsor Fullfillment Coordinator

Tim (timconstien) is joining the Association’s Community Programs team as a DrupalCon Sponsor Fulfillment Coordinator. In this position, he will be ensuring that DrupalCon sponsors enjoy all their benefits and receive top-quality service before, during, and after the convention. Tim is a graduate of Oregon State University, and most recently worked to support the sales and marketing departments at a national radio group based in Portland. In his free time, Tim enjoys exploring: Whether he is finding new pubs to shoot pool at, finding the new best food joint, exploring new tree runs to snowboard through, or road tripping to the next music festival, he is always on the go.

Please help us give a warm welcome to our four new staff members. It’s great to have you on board!


Commerce Guys: Drupal Commerce Site Spotlight: Pam Kerr Designs

vr, 2015/01/30 - 2:32pm

We're always on the lookout for great sites built with Drupal Commerce, our truly flexible software that's changing the face of eCommerce one site at a time.

Pam Kerr is one of New Zealand's leading independent jewelry designers. Her company - Pam Kerr Designs - had a Shopify site that served retail customers well, but it didn't meet their growing B2B needs. With the help of Blue Fusion, a New Zealand based web design and development chose Drupal Commerce for its flexibility, power and customizable user interface.

For more information, check out the full write-up DrupalCommere Showcase


To see Drupal Commerce sites we've Spotlighted in previous weeks view the Other Spotlight Sites


Annertech: Welcome to 2015, the European Year for Development

vr, 2015/01/30 - 12:48pm
Welcome to 2015, the European Year for Development

Last Thursday - Jan 22nd - President Michael D. Higgins launched the European Year for Development at Dublin Castle, saying that "2015 is a seminal year for the future of human development".


Jonathan Brown: Using Bitcoin dust transactions to prevent website spam

vr, 2015/01/30 - 11:49am

Previously: Ensuring security of funds and preserving anonymity when using Bitcoin for e-commerce

I quite often use Mollom to prevent spam submissions on contact and comment forms. It works pretty well, but some spam still gets through.

An alternative anti-spam technique is to require a Bitcoin dust transaction before an unprivileged user can POST a form. The value of such a transaction would only be about $0.001 USD. For a non-spammer this cost is fine, but for a spammer this is enough to make it totally uneconomical as they need to send out millions of posts.

I created a Spam Filter sub-module in my Coin Tools project for Drupal. It can be used to require a Bitcoin payment on any form on a Drupal website.

Coin Tools already has a Bitcoin payments system. When viewing a form, a new payment is created for the minimum amount possible. In the latest Bitcoin reference implementation the smallest output is 546 satoshis. However, many wallets still use the old value of 5460 so that is what is used.

The form's submit button is hidden with CSS (it still needs to be in the DOM for the form to function correctly) and a clickable QR code for the payment is put in its place. Coin Tools payments are BIP 70 compatible so a payment can either be satisfied by a direct POST from the wallet to the Drupal website, or the wallet can broadcast the transaction through the Bitcoin network (slightly slower).

Once Coin Tools has determined that the payment has been completed it will POST the form via JavaScript. If there are any validation errors the form will reload in the normal Drupal way. In this case, the submit button is no longer replaced by a QR code as it is recorded in the form state that the payment has been made.

When the form is submitted it is also verified on the server that the payment has been completed.

Here is a video of it in action.

Of course, this technique requires that the user has a small amount of bitcoin. For a website not targeting the Bitcoin community it would not only prevent spammers it would actually prevent everyone from posting. As Bitcoin usage increases this technique will be able to become more commonplace.

Browser integration

It has been proposed before that web browsers should have Bitcoin SPV wallets built-in, e.g. for paywalls. If a payment is required an "HTTP 402 Payment Required" response would be generated. In that situation it would make sense for the browser to prompt the user before a payment is made. For the spam filter this could just happen automatically. The transaction could actually just be included as part of the POST to submit the form.

Burning Coins

Because the transactions are for such a small amount it may not be economic to spend the received funds as large miner fees would be required. It might be simpler to just generate a random Bitcoin address for each payment. This means that you don't have to have a wallet on the server and could just use Chain to check if the payment has completed.


If a double-spend on a comment submission was detected after it had been accepted, the post could be deleted. For email submissions, they could be delayed a few seconds to be sure there is not a contradictory transaction floating around.

Even without implementing these protections, double-spending wouldn't make sense for a spammer.

Could a spammer double spend and avoid paying the dust amount? No - double spending is extremely expensive so it would be even worse value for money than just paying the dust amount.

Could a spammer simultaneously broadcast many transactions that spend the same outputs to many different forms and websites? In theory this might be possible and some of the forms would accept the POST before realising the transaction is a double spend. Spamming multiple forms on the same website simultaneously would be impossible because the website would be connected to just one Bitcoin node. If this did become an issue the fee required to POST could just be increased to make it uneconomic.

Greater amount?

Of course, it may be desirable to actually charge a larger fee for the purpose of generating revenue. The admin interface could be extended to allow a configurable amount.


Lullabot: Drush and Composer

vr, 2015/01/30 - 11:29am

In this week's episode Addison Berry hosts Greg Anderson, one of the Drush maintainers, and Juampy Novillo Requena to discuss Drush. We start off by explaining why Drush exists and some cool things about it. One of the big hangups people have with Drush is installation, so we talk a bit about that, and how it is easier now with Composer.


Code Enigma: My first year as a Sysadmin

vr, 2015/01/30 - 11:24am
My first year as a Sysadmin Language English My first year as a Sysadmin

This blog post is a short story of how I started working for a Drupal company, some of the things I've achieved during my first year in the industry and my impressions of working with a Drupal agency as a sysadmin.

30th January 2015By emlyn Introduction

Before I pelt you with details of my first year as a sysadmin, I think I should give you a little information about myself. I’m Emlyn, 23 years young and based in the UK...the West Midlands to be a little more precise.

I graduated from Coventry University with a 2:1 in Games Technology with the hope of becoming a games programmer. However, after graduating, I noticed my portfolio fell far short of other students on my course, and, I’ll be honest, that bummed me out.

That was when I was approached by my cousin, Jamie, who works as a Systems Manager for Code Enigma, with the prospect of training to become a Junior Sysadmin. I gave it some thought; I had always been interested in Linux systems and wanted to know more about them. In fact, one of my modules at University was Operating Systems Security and I thoroughly enjoyed the assignment we were given where we had to create a shell script that provided the ability to display working processes, navigate a directory, list online users, amongst a few other things. So, I accepted the offer of a three month internship, which started in October 2013, which then turned into a permanent position in January 2014, and I really haven’t looked back since!


As with every new job in a new field, training is required. For me, this was two weeks in Cardiff with Jamie, trying to learn as much as possible before working from home by myself. It was daunting, I’ll be honest. I knew there was so much to learn in a very short space of time. Perhaps I put too much pressure on myself; no one expected me to become an expert in just two weeks!

On the very first day of my internship, I was given the task of ‘building’ a new server which would serve as an internal server. So, my first lesson was in Puppet and how to use it to provision a new server semi-manually. This blew my mind! A few simple-ish (well, now I think they’re simple-ish) steps and Git pushes later and a new, usable server was up and running. Let me go back on myself, my first lesson was in Puppet and Git. One interlinked the other, and vice versa.

In a sense, I was thrown in at the deep end, given tickets to work on myself. Jamie pointed me in the right direction and gave me hints and tips that aided me in my work. In all honesty, his method of training me was brilliant, perfect. I’d try the work assigned to me first, and ask for help when I needed it.

Over the course of the two weeks, Jamie never showed any impatience or annoyance at what I was doing, even if I did something completely wrong or didn’t understand what had to be done. He taught me an important part of being a sysadmin: patience, especially patience towards clients. I had to understand that the client may not know as much as me, even though I’d only been in the industry for two weeks myself!

Over the course of my three month internship, and in fact the following nine months, my training never really stopped. I was learning new things every single day, all the while fine-tuning my newly acquired skills. Another important lesson I learnt during my first year as a system administrator was that I will never know everything there is to know in being a sysadmin, there will always be something new to learn.

Working from home

Being given the chance to pursue a totally new career and develop new skills was fantastic and an opportunity I couldn’t turn down, but what put the icing on the cake was that I’d be working from the comfort of my own home. However, I realised that I was going to have to be very disciplined, even more so than I normally would. It dawned on me that my fellow colleagues would be trusting me to work efficiently and I did not want to let them down by being slack just because I was working from home.

Working from home has its advantages, as you can imagine. No suit and tie and no long commute to work every morning. So there’s not a mad rush in the morning and I don’t have a busy office environment around me to distract me from my work. However, I am alone (as are my colleagues), which means not being able to walk up to them should I have a question or concern and not being able to go for a drink or food after work. But, these disadvantages, I feel, are out weighed by the advantages of working from home.

Running a distributed company can be quite challenging. My boss, Greg, is currently working on a series of blog posts in which he goes into detail about being Spread About. It's well worth a read.

What was I expecting?

I’ll be honest, I didn’t know what the job was going to be like! All I knew was that I was going to be learning a lot in a short space of time. From the email conversation I had with Jamie before starting, I had a feeling it was going to be all hands on deck. A lot of the time, I’ve been kept busy all day dealing with several different clients, all wanting different things done. Other days, it’s been a little less busy and I’ve been able to spend a bit more time on each task.

Surprises! Of all kinds of variety

I’d be lying if I said I hadn’t been surprised by anything. I think what surprised me the most in my first year, and what still baffles my mind today, is the sheer number of tools and software available to a system administrator. For example, we use Percona as our database of choice, but we could use MongoDB, or MariaDB. Then there are multiple database caching systems to choose from, numerous HTTP accelerators, web servers and continuous integration tools! My point is there isn’t a short supply of tools available; in hindsight, I’m not sure why that surprised me, but it did.

Top five things I’ve learnt

A year ago, I knew very little to nothing about being a system administrator. I could be very lazy and just list the top five things I’ve learnt in my job, but I’ll try and be a bit more descriptive. In no particular order of importance:

  1. Patience is actually a virtue! I’ve learnt that when dealing with a task, be it for a client or a personal task, to be patient with it. Getting frustrated and angry (perhaps covertly when dealing with a client) will only make matters worse and lengthen the time it takes to solve the problem. Clients who are not as technically knowledgeable appreciate patience; as I described above, Jamie was incredibly patient with me during my training, which helped me to understand the problem at hand more easily.

  2. Security is important. Very important. I deal with client data on a daily basis, so being proactive in keeping my workstation and computer secure at all times is important. I’ve learnt to be vigilant when transferring data to a client or a colleague; rather than send them a sensitive document over plain text email, I’ll upload it to a server the recipient has access to so they can grab it from there themselves. I’d GPG encrypt an email to them, but ever since the people who make the GPGTools plugin for the OSX mail app have started charging for the service (shakes fist), I’ve opted to use other means. We at Code Enigma like FOSS! Over the last year, Code Enigma have become ISO 27001:2013 certified, which meant I had to learn and understand how to handle data and documents properly.

  3. Workflow is also important. I learnt about the simple, yet very effective, workflow used by Code Enigma in the first couple of weeks of joining the company. It’s as straightforward as this: master -> stage -> production. Push changes to the master branch first, then merge them through to stage after some initial testing. Once the client is happy and has signed off the changes, push them through to production for deployment to the live site. Simples! However, before I joined CE, I didn’t know or think like this. When I ran an online game with my brother (not in Drupal), I’d make changes to the code locally, with no local setup running, and FTP (ew) the updated files directly to the server, which affected the live site. Horrendous. Now, when I start work on a personal project, I have an exact workflow I want to follow.

  4. Drupal...well, a small amount. A very small amount. Primarily, I’m a sysadmin, so I do a lot regarding setting up Drupal sites and debugging server issues relating to Drupal. I did a small amount of Drupal development at the start of my employment, so learnt a little bit about it which has fared me in good stead when it comes to dealing with simpler Drupal issues.

  5. Linux. Well, obviously not all of it, but I have learnt a lot in my first year. Obviously there are some things I’ve learnt that I need to improve on, but that’s a given with most operating systems, especially Linux. I knew a little bit about Linux before joining CE, but only rudimentary stuff from using Ubuntu as my main OS for a little while. During my first year, I picked up some really useful tips and tricks, learnt of different command line tools and how to use them, such as Drush and learnt how to read system and access/error logs. That’s just to name a few Linuxy things I’ve learnt.
What I hope to do/learn in the next year

There’s so much out there to learn that appeals to me, I could probably write a separate blog post just about that! But what I really want to learn, that I think will benefit me as an individual and my role in Code Enigma, will both be time consuming and difficult: MySQL multi-master replication and DRBD, to assist our Australian sysadmin with server cluster issues, and Drupal 8. I’ve a head start (ish) on Drupal 8 in that I know a bit about PHP, but I’ve been made aware the PHP I know and have programmed in is archaic and old-fashioned. It’s time to delve into Object-oriented programming!

It would be great (for me at least) to get a text-based, role-playing game up and running in Drupal, be it 7 or 8. But seeing as I want to develop my D8 skills, it makes sense to develop the game using the latter of the two. As I previously mentioned, I used to run an online text-based game with my brother, which used a very poorly written engine now that I look back on it. I’ve not seen many, if any, games of the sort created using Drupal. Even if no one plays the game, it’ll still be an achievement in my eyes as I’ll have improved my Drupal knowledge.

MySQL multi-master replication will be an important concept to understand and know how to use because we have a handful of clients that have a high availability layout setup with us, which include two application servers and two database servers, at least. If there’s a blip in the network, replication between the servers can be affected, which requires manual intervention to put right. If this happens, our Australian sysadmin is woken up through the use of his batsignal, but if I could solve any replication issues and save him being woken up in the early hours of the morning, then it’s a win-win for both of us; I’ll have bolstered my knowledge and Mig won’t be woken up abruptly.

What are my impressions after my first year?

My impressions after my first year as a system administrator for a Drupal agency are very high; the other sysadmins in our team are incredibly knowledgeable and can adapt to every situation and issue thrown at them. This has given me inspiration to develop my skills and knowledge to reach their level and some day leave the same kind of impressions on a future junior sysadmin.

My impressions for working for a Drupal agency are just as high. My colleagues are all very clued up in their area of expertise, from Drupal magic to content strategy to finance management. Everyone does their part for the company, be it providing bespoke tools for a website (such as the ones used for this very site) or by providing top level training to new, or old, Drupal agencies. It's an honour to be part of such a fantastic team!

Main image by Wendy Seltzer, released under the Creative Commons Attribution 2.0 Generic license.


Very Slick Site MapsBlog New Toy: Asus EEE PC 901Blog Still doubting the reliability of Open Source solutions?Blog A Step Closer: Views In ParisBlog

Palantir: Explaining Panels: Why I use Panels

do, 2015/01/29 - 10:00pm

In my last blog post I explained what the Panels Suite is and does. I explained how Panels itself is a User Interface on top of hook_theme() and theme(). That technical explanation of Panels underlines what I think is its main conceptual virtue:

Panels encourages a mental model of pulling data into a specific design component

At Palantir we're working with Design Components that are created in static prototypes. Design Components are the reusable pieces of front-end code that compose a design system. Design Components should not know about Drupal's internal implementation details. We're not alone in this thinking. (Inside the Drupal community, and outside of it).

The task of "theming a node" is now "print this node so that it renders as this design component." Unfortunately Drupal core does not have <code>hook_design_component()</code>. It has <code>hook_theme()</code>. Some of the entries in <code>hook_theme()</code> from core are essentially design components.

Entries like <code>‘item_list'</code> and <code>'table'</code> are design components. They are conceptually based around their HTML rendering. They make sense independent of Drupal. To use them as a Drupal Developer you need to get your data organized before you call <code>theme()</code> (directly or otherwise).

On the other hand, much of the Drupal core usage of <code>hook_theme()</code> is not at all design component minded. <code>'node'</code>, <code>'user'</code>, <code>'comment'</code> all have entries in <code>hook_theme()<code>. In these elements you don't have to organize your data before calling <code>theme()</code>. You can give <code>theme()</code> a node object and after that <code>template_preprocesss_node()</code> has to do a ton of work before hitting the template.

It's no coincidence that the design component-ish <code>hook_theme()</code> entries have minimal preprocessing or no preprocessing whatsoever. The design component-ish entries like </code>‘item_list'<code> know what the HTML will look like but have no idea what your data is other than you were able to get it into a list. The non-design component entries like node know exactly what the Drupal-meaning of the data is but know very little about the markup they will produce on most production sites.

Panels unites the two mindsets. It knows what the incoming data is (A node context, a user context, etc) and it knows what design component it will print as (the layout plugins.) If you put a debug statement inside of </code>panels_theme()</code> you will see the names of layouts and style plugins. These </code>hook_theme()</code> entries are more of the design components-ish <code>hook_theme()</code> entries. They know what their markup will be. And the part of Panels most people pay attention to, the drag-and-drop interface, is where you control how the data of a node is going to prepare itself for the design component.

And here is where the admin UI of Panels might set up a confusing mental model.

How it looks in the Panels admin UI

But at execution time it is

Or the way I think of it

Drupal Data → transforming Drupal data into printable variables → design components for those variables to print in

The next time I get into a discussion about Panels at a meetup, DrupalCamp, or DrupalCon, think I'll first ask, "Does Panels let you think about building websites the way you want to think about building websites?" I like to think about passing variables into encapsulated configuration associated with a specific design component. I prefer that mental model to the "show and hide based on globals" mental model of Core's Blocks or the "just call theme() on a node and figure out the overrides later" mental model encouraged by node--[content-type].tpl.php. As the Drupal community asks itself again how it wants to do rendering, let's also ask "how do we want to think about rendering?"

The rise of design component thinking in the wider Wweb development world is not turning back. Web Components and modern front end MVC frameworks encapsulate design components. They do not care about every single implementation detail and layer of a node object. They care about getting variables ready for printing and updating. Panels module may fall out of the picture once Web Components fully mature. Until then, Panels allows for us to think in ways we will need to think for Web Components to work with Drupal.


Drupal Watchdog: Touring Drupal

do, 2015/01/29 - 6:51pm

Drupal 8 has been all about pushing the boundaries, so why should help content be any different?

With the release of Drupal 8, we will also ship with tools to complement hook_help() entries: if you, the developer, are providing a documentation page for your module, why not also provide an interactive step by step guide on how your module works as well?

The idea of Tour isn’t a new one; it has been maturing over the past two years. It all began after the release of Drupal 7 when we decided to move the help passage from the front page to the help page. This meant that users new to Drupal would not see this text, and would have to struggle through with no guidance.

In light of that issue, the below was suggested;

How about creating a “Welcome” message that pops up in an overlay with that same information that continues to appear until either the user checks a box on the overlay saying to dismiss it or the user creates a piece of content on the site?
- Vegantriathlete, August 10, 2011

With tour.module committed to Drupal 8 core, we now have context-sensitive guided tours for Drupal’s complex interfaces, and developers have a new way to communicate with the user. It doesn’t stop at core either: contrib modules can ship with tours to describe how users can take full advantage of their modules. Distributions can also ship with tours on how to get started. Imagine a tour in the Commerce distribution that took the user through setting up products: That would be amazing! It would enable users to discover the pages they are looking for and take the guesswork out of finding pages.


OpenLucius: Why the Bootstrap HTML framework in Drupal & OpenLucius

do, 2015/01/29 - 5:58pm

The Bootstrap HTML framework in Drupal, we love it. That's why we build the front-end of Drupal distribution OpenLucius with it. So we love it, but why is that?

There are alternatives to integrate in Drupal websites. Below we will give you a few reasons why we currently prefer the Bootstrap framework.

Why a HTML framework

First of all, why should you use a HTML framework? These possibilities also exist:


InternetDevels: Drupal tourists in Ternopil

do, 2015/01/29 - 11:31am

Nothing keeps Drupal tourists from spreading the word! We are passionate for Drupal and IT, so enjoy meeting like-minded people very much! Despite the cold winter weather, Ternopil welcomed us with warmth and friendliness. How was it? Our blog post will tell.

We were getting ourselves ready for the ride for almost a month. Our brandy Drupal van wanted to make nice impression too, that’s why the journey hit off from the car wash :)

Read more

Code Karate: An introduction to Git (part 3): Adding and Committing

do, 2015/01/29 - 7:00am

In An Introduction to Git Part 1, you learned what Gi


Mediacurrent: SprintWeekend2015: A review of Mediacurrent&#039;s participation

do, 2015/01/29 - 12:24am

While we at Mediacurrent have been trying to bring internal focus and organization to our contributions, the rest of the Drupal community was planning a “Sprint Weekend” for January 17th and 18th.


Web Wash: How to Use Display Suite Field Templates in Drupal 7

wo, 2015/01/28 - 10:36pm

Display Suite is one of the essential modules which I use on every project. It allows you to change the look and feel of entity bundles, i.e., content types, vocabularies, users and much more. Building custom layouts and adding fields is a breeze, but there's another feature you may not be aware of and that's custom field templates. Display Suite allows you to change the markup which is used to render individual fields.

The functionality to change field templates is off by default. To turn it on, you'll need to enable the "Display Suite Extras" sub-module and check the "Field Templates" on the Extras page.

In this tutorial, you'll learn how to enable "Field Templates" and how to use them.


Phase2: Finding (and Retaining) the Best of the Best

wo, 2015/01/28 - 10:13pm

Yesterday, Phase2’s own Chris Bloom was featured on the Drupal Association’s podcast on how to hire great Drupal talent. It’s a pertinent conversation to have at the moment, when 92% of hiring managers surveyed by the Drupal Association reported that there is insufficient Drupal talent in the market to meet their needs.

Over the course of an hour, Chris, Randi King, and Mike Lamb shared many insights on not only attracting talent, but keeping it around. I highly recommend giving the podcast a listen once the recording is available on the Association’s website. In the meantime, as Phase2’s Talent Manager, I wanted to elaborate on some of our company’s methods for finding, hiring, and retaining the best of the best in Drupal and beyond.

Finding Talent: Emphasizing Relationships

Because we operate in an industry of web professionals, it may be a little surprising that the majority of Phase2’s recruiting happens organically, not digitally. True, online advertising plays a role, and we share open positions on our website, LinkedIn page, and Twitter. However, many of our new hires are discovered by employee referrals and face-to-face introductions at community events and job fairs. This is no coincidence: we respect our team members’ judgements and encourage them to bring new people into the fold – and we really like talking to new people!

The emphasis is really on building relationships, as opposed to checking off a list of desired skills. Organic connection is, therefore, an enormous help in determining whether a candidate will be a good fit at Phase2, whether the connection derives from an awesome conversation, internal introduction, or past collaboration with contractors. We initially look to have an open dialogue in order to gage attitude, passion, and motivations – it is these intangibles that really get us interested in a candidate. A recommendation from one of our employees speaks volumes in this respect.

The Interview Process: exploring skill & creativity

An interview is obviously an evaluation of a candidate, but it should be less a trial than an open discussion. As I mentioned earlier, it’s important to pay attention to the undefinable character traits that will help the candidate succeed at your company. At Phase2, this means being aligned with our six values: dedicated, collaborative, smart, adaptive, authentic, and fun. Even the best developer in the country might not be the right choice if he or she is not a cultural match.

To judge technical abilities, we take code contributions and technology tests into consideration, but another big portion is evaluating thought process and decision-making skills. We ask candidates to talk us through how they would go about tackling certain challenges, getting to the heart of their understanding of the technology and proper processes. This method also offers the advantage of revealing people’s true creativity. Most technologists have an inner flair for creating, and it is always exciting to figure out where their passion comes from, and the unique ways it plays out when solving technical problems.

offering flexibility

According to a Drupal Association survey, 44% of job seekers emphasize location as an important factor in accepting a new job, specifically not having to relocate. Accommodating these candidates means walking the fine line between attracting top talent and maintaining a healthy, engaged team. Requiring all employees to work from a physical office encourages bonding but may scare off truly talented people that consider working from home to be a deal-breaker. At the same time, managing a remote team presents a myriad of logistical challenges in day-to-day communications, in addition to the difficulties of fostering a close-knit team.

At Phase2, our strategy is to offer ultimate flexibility for our employees. Our four offices in DC, New York City, San Francisco, and Portland give our social butterflies the chance to bask in our rich office culture. At the same time, about 30% of our team work remotely across the country. Day-to-day collaboration is achieved through diligent digital communication, video meetings on Google Hangout, and a water-cooler-like chat system which allows us all to bond at a distance. Maintaining an inclusive organization requires a concerted effort (such as our annual all-company gathering at headquarters) but it is well worth it to offer our employees the flexibility to live and work where they prefer to.

Retaining Talent: Letting your People Blossom

Phase2 has been very successful in retaining talent, and a large part of that is offering employees the chance to work on interesting and important projects. In a poll conducted with the podcast’s attendees, 70% believed that the most important factor in keeping staff happy and engaged was interesting work – much higher than compensation (10%), or even culture (20%).

Beyond interesting work, we at Phase2 believe career development is crucial to letting our people blossom. Encouraging long-term growth is key to ensuring your team feels appreciated and valued – it is basically an indication that your company is invested in their future. We manage this by instituting weekly check-ins with managers to discuss progress and goals. In addition, we’ve established well-mapped career trajectories. We feel that it is important to provide concrete steps for individuals to move forward in their own careers, pursuing specialties they themselves have shown an interest in.

How does your team find, hire, and retain top talent? We’d love to hear your thoughts in the comments!


Drupal Easy: DrupalEasy Podcast 143: Scheming ( integration in D8 - Stéphane Corlosquet)

wo, 2015/01/28 - 9:16pm
Download Podcast 143

Stéphane Corlosquet, Sachni Herath, Kevin Oleary, and Kay VanValkenberg join Mike, Ted, and Ryan for a look into Drupal 8's impressive integration with The RDF UI module is really the star of the show, it promises to provide a super-easy way to create a content type based on an existing schema. We also talk about Dries' 2014 Drupal retrospective, Twig syntax vs. tokens, and Mike's bad internet connection causes hijinx. Picks of the week include a font for demos, a lightweight alternative to a popular Drupal module, and Views changes in D8.

read more


Drupal Association News: Drupal Association Board Meeting: 21 January 2015

wo, 2015/01/28 - 9:02pm

In the first board meeting of 2015, we hit the pause button and looked back on 2014. With all the numbers in and so many projects completed, we wanted to evaluate our success (and our misses) with the board and with you. We feel really good about what we accomplished with the rest of the community. To me, it's doubly impressive because the Association spent so much of last year growing like crazy. We started the year with just about 13 staff and ended the year with 27. We're still small, but doubling your staff is never an easy endeavor. So to go through that kind of change, and to also get some much other good stuff done seems pretty remarkable to me. As always, you can check out the notes, the materials, and the recording, or peruse my summary of the meeting here.

Operational update

I think I can safely say that the theme of 2014 was “Let’s see what we learn from this!” We started the year with a Leadership Plan that outlined some important goals and strategies. We also defined key metrics we would track to help us understand if we were making progress on those goals. This was the first time the organization had this kind of framework to not only get a lot of stuff done, but to understand if that stuff was fulfilling its purpose.

The plan helped us identify lots of things to experiment with, and throughout the year we learned a lot about our plan itself. Metrics didn’t always point to the outcomes we thought they did. Some goals that we set were impossible to meet because of outside influences. But having the plan - that was important. It forced us to think about our work before, during, and after every project. So where did all our experiments take us? A lot of places. Here is a short, incomplete, and grossly over-simplified list of what we accomplished in 2014:

  • We set the proper frame. We developed a vision statement, revamped the mission statement, and created a values statement for the Association.
  • We rebranded, developing new logos for the Association and our programs that reflect our maturity as an organization.
  • We diversified our revenue, by a lot. Introducing new programs and services we were able to make a dent in the ration of Con related revenue to non-Con revenue. This is important for the financial health of the Association, but also because if Cons are our primary source of revenue, we can’t innovate and evolve them with as much courage for fear of undermining our total revenue.
  • Speaking of DrupalCons, we held two really big ones. Lots of things went right - they are well run, with great speakers and great community. We also collected a lot of data about the Cons and identified lots of places to work on for 2015 and beyond. (We promise we heard you about the food in Amsterdam!)
  • The marketing team is creating lots of technical marketing and other branded content that is starting to get great traction in the field. Resources like “Managing Media in Drupal” allow us to showcase the best that Drupal has to offer, regardless of version.
  • The launch of Drupal Jobs was a big milestone for us. We had not launched a product before, and were thrilled to get something out there that the community has repeatedly asked for. It’s still new, and we’re still learning, but we are overall very excited about the steady growth that we have seen.
  • Testbots is an area I have heard about on a weekly basis since I started at the Association. In 2014 we were able to forge a great partnership with the testbed volunteers. The Association is now managing the ongoing operation of the existing testbed infrastructure while the volunteers get to work on the next generation. We’ve seen massive improvements in performance as a result - wait times have dropped from almost 120 minutes to about 20 minutes on average. During the recent Global Sprint Weekend, we went from our usual 4 AWS instances to 20!
  • profiles have also seen a tremendous change in 2014. Again, thanks to the work of some amazing volunteers, we were able to introduce small targeted changes frequently, beginning with profile pictures. The work is not done and there are more changes to come, but profiles are becoming better and better online resumes and community connectors for the community.
  • We managed to be our projected deficit spend for the year. This sets us up well for 2015

I would like to point out that I am extremely proud of the Association staff who endured a lot of growing pains while churning out really good, quality work. In addition to being awesome at what they do, they are hilarious and smart. I owe the a huge debt of gratitude. HOWEVER, all of the bullet points above represent a significant contribution from the volunteers in the community as well. We don’t do our work alone, and we are so grateful to the hundreds of you who have prototyped, tested, coded, documented, trained, mentored, and made puns. Your leadership in the community is noticed and appreciated. Our greatest hope is that we are making your Drupal life a little better.

Marketing Team 2015 Update

The marketing team built a very solid base in 2014 and is prepared to declare 2015 the year of content. Here are a few key initiatives that you can expect this year:

  • More branded content, better presentation. We’re going to turn into the best site out there to discover all you can do with Drupal. We’re currently developing a content strategy that will help us discover all the great content that already exists, but gets lost in the one million+ nodes on the site. Then we can combine that with the great technical content we are also crafting to create more resource centers covering everything from media to search in Drupal.
  • A blog. We are in the middle of a content strategy process led by staff with the Content Working Group and Forum One Communications. It’s clear that we need a better channel to expose the folks who want Drupal news, but who aren’t ready to drink from the firehose that is Drupal Planet. The blog will allow us to reach those folks, and we hope we can use it to highlight the best writing about Drupal that is already being produced.
  • Drupal newsletter. In 2008, we stopped sending a regular Drupal newsletter to the tens of thousands of subscribers on We’re bringing that back in 2015, with a model similar to that of the blog - the best community content. This newsletter will differ from the Association newsletter in that all the content will be focused on Drupal itself.
  • A challenge will be localization - translating content for our global audience. With the release of Drupal 8 nearing, and its emphasis on localization, we want to meet this need. We’ll be working on strategies to make translation happen on key content.

Of course, there is more to the update than this summary, so I encourage you to check out the presentation.

And then we ran out of time

We were also scheduled to vote on a slate of candidates for the newly formed Licensing Working Group. Unfortunately, we ran out of time. The Executive Committee of the board will be discussing next week to see if we can vote electronically on this topic.

Thanks for a great 2014. Here’s to an even better 2015

Again, thank you for the support, the work, the encouragement, the ideas, and even the complaints. All of it makes us better as an organization, and we hope that when we’re better, Drupal is better. 


Flickr Photo: DianaConnolly101


Shomeya: 7 Things for Troubleshooting Drupal 7 Theming

wo, 2015/01/28 - 8:05pm

When I worked in Reality TV Post Production I always had a troubleshooting guide. Most of the time I was working the night shift, and trust me no matter how many times you've done something sometimes your brain just breaks at 2am.

In case you haven't done this before a troubleshooting guide is basically just a list of the steps you take when things break, it helps you avoid that moment of exasperation 3 hours later when you realize how simple the solution really was.

Read more

CivicActions: Dockerizing Drupal for Project Development and Testing

wo, 2015/01/28 - 5:05pm

Docker has quickly become the favorite virtualization tool for many people including myself. A few months ago we were discussing various technical goals across our project and things started to come together pointing to a basic docker framework to facilitate our development processes. This basically sums up our wish list:

Our Goals
  • Faster developer sandbox set up to get started on projects sooner.
  • Consistent software stack across developers, testing infrastructure, and production.
  • Ideally, a basic tool set that would work for both our new projects as well as our maintenance sites.
  • Start using the cool new trendy docker.
Container configuration with fig

One challenge is to have portable configuration for the building, starting, and stopping of a project's containers. The fig project provides an elegant solution and the configuration is in YAML files, which we in the Drupal community should be getting used to now with Drupal 8. The fig.yml defines your containers, ports, mount point, and how they link together. Maintaining a fig.yml file in our project repositories allows us to do things like add an Apache Solr container with ease.

I was working on a collection of bash scripts and docker files and a fig.yml for one project and at some point it became stable enough to extract for general use. I brought these files together and made them available on github.

Introducing Bowline

Following the nautical and shipping metaphor, I chose the name bowline because it's a simple and basic knot with multiple uses. The idea is that Bowline ties it all together. Plus it reminds me of my sailing days when I could tie a bowline in less than 3 seconds, which is slightly faster than it takes to start the docker containers.

Code and instructions found at the git repo:

I have now had success with Bowline on both new project and on existing Drupal 6 and 7 projects. Just last week I also tried it out with Drupal 8 and I'm happy to report that it works just fine on Bowline as well.

Dockerfile flexibility

Out of the box, Bowline ships with two containers. One for mysql 5.5 which is simply the default image from Docker Hub. The second is the web container providing apache, php 5.4, and related software. The web container is defined within the .docker/web-5.4 directory and the Dockerfile with supporting config files are based on the awesome work of the new Drupal testbot project.

Automation, running tests

Imagine your developers getting their local sandboxes up and running in a matter of minutes. This is now possible, facilitated by a few simple bash scripts. Bowline provides a template document intended for instructing your team on how to get set up:

Basically, they run build sync-db to get a copy of the database, build sync-files to get the site's uploaded files, then build import which does all the work of building the docker containers and importing the database. There is also a backup script which will save a snapshot of your database named after your current git branch which is handy for switching to another task while preserving your work. The run command is intended for running your automated tests. It assumes behat but you can modify it to run whatever testing software you use. The nice thing is that our developers are all running local behat tests on the exact same software stack as each other and as the test server. We have a Jenkins server with docker and have jobs configured to execute the build and run commands just like we do on our own machines.

Slaying File Permission Dragons Anyone who has worked with a LAMP stack has bumped into file permission issues with uploaded files. Add a docker container to the mix which is mounting your project files and serving them up as the apache user withing the container and there is lots of ways to mess things up. This dragon gave us some grief early on when starting to use docker in this way. We won the day by setting the apapache user to run with the same uid as the docker host user. This way each developer will have ownership to their own file uploads on their system. Here's the simple bash code that makes it possible: # Set the apache user and group to match the host user. OWNER=$(stat -c '%u' /var/www) GROUP=$(stat -c '%g' /var/www) usermod -o -u $OWNER www-data groupmod -o -g $GROUP www-data (source) Room for improvement

One tricky thing we found using docker containers is using drush in a complete way, particularly using drush site aliases. For now we have "crush" which is a temporary work around but not too bad of a work around actually. Crush is a simple bash function that calls drush as a command on the docker web container. We use crush to clear cache manage features and such, and it is working well. However it's not ideal and I'd like to add ssh server to the stack to allow for proper drush site alias usage.

There's always room for improvement. I'd like to find an elegant way to incorporate more developer tools such as sass, compass and debugging tools. Every project is different but it would be nice for Bowline to have some basic Behat smoke tests build in. These things will hopefully be added to the Bowline project as we use it and add things to our drupal project. And yes, pull requests are welcome.