Planet Drupal

Subscribe to Planet Drupal feed - aggregated feeds in category Planet Drupal
Updated: 18 min 5 sec ago

Jackson River: Learning and Fun at DrupalCon Austin

Wed, 11/06/2014 - 06:37

DrupalCon Austin may have just rolled out of town but things certainly haven’t settled.  This was my third DrupalCon (Chicago, Denver and Austin) and, I have to say, it gets better every time!

Photo Credit: Michael Schmid

In just four short days, the Jackson River team packed in a lot of training, community building, knowledge sharing, socializing, and general Drupally hi-jinx that will impact our day-to-day work and the direction of our products and services for a long time to come. Here are a few highlights from the week:

  • I had the pleasure of attending the Advanced SASS and Compass for Responsive Web Design training session presented by Sam Richard, Chris Ruppel and Ian Carrico.  We took a deep dive into the workflow of building responsively and a suite of tools (Gulp, Singularity, Style Prototype, etc.) that can support and expand our responsive toolkit.  Responsive web design was a hot topic throughout the week!
  • Semantic Site Architecture presented by Jody Hamilton from Zivtech and Type, Responsively: Design For Readability & Meaning on Any Screen presented by Jason Pamental of H+W Design were my highlight sessions for Tuesday.  Semantic Site Architecture touched on the importance of planning and structure to the effectiveness and sustainability of a build with emphasis on great tools like the Build Spec. Type, Responsively explored the best practices for type scale across screen sizes, measurement units, the complexities of @font-face and the techniques you can use to provide a consistent experience.
  • Thanks to the Four Kitchens crew, Phillip and I got to try the world famous Franklin’s BBQ!  
  • The front-end and site building tracks kept rolling Wednesday. Viewception: Three Levels Deep, presented by Brandon Ratzloff, showcased his technique of creating nested views to display complex data. It never fails that I can always learn something new and wonderful to do with Views at DrupalCon! Managing Complex Projects with Design Components, presented by John Albin Wilkins, explored new techniques with web components, CSS layering, utilizing SMACSS and BEM to create more sustainable themes.
  • Hands down, the best party I attended all week was Patheon and New Relic’s shindig at Bangers Sausage House & Beer Garden. Drupalistas know how to have a good time and this party was no exception.
  • By the end of the conference, I know I wasn’t the only one feeling a little overwhelmed, so it was only fitting to wrap up with the My Brain is Full: Keeping Pace with Front-End & UX Innovations session presented by Brian Wald and David Hwang.  Brian and David facilitated a really great conversation about the pace of front-end innovation and how we, as a Drupal community, can make Drupal a more flexible platform for front-end.
  • The Jackson River crew met up one last time before heading out at Easy Tiger for a few beers and maybe the biggest (and best!) pretzels in town!  

DrupalCon was a fantastic learning experience, a great hub for community building, and an opportunity to show off my current favorite city to friends, colleagues and clients!

Tags: drupalcondrupalprofessional developmentCompanyConferences and SpeakingTechnologyDrupal Planet
Categories: Elsewhere

Drupal Commerce: Adding Paid Content to an Existing Drupal Blog

Wed, 11/06/2014 - 00:59

One of the most powerful things that you can do to a Drupal site is to add Drupal Commerce. With some modules and a bit of time, you can transform any Drupal 7 site into a revenue generation engine — no matter if you are selling physical products, file downloads, or just wanting to monetize digital content or access. The ability to simply enable commerce on an existing site is very powerful and can open up opportunities that you might not have considered.

One of those possibilities is paid content. This post will walk you through adding paid content to an existing blog site using two modules from our Digital Commerce Suite: Commerce License (CL) and Commerce License Billing (CLB). At DrupalCon 2014 in Austin, in the second half of Commerce by Example, we walked through the process of setting up a blog. The instructions and the demo site archive are here (link above) so you can walk through at your own pace.

Categories: Elsewhere

Acquia: 5 Erreurs à éviter sur votre Site Drupal - Numéro 3: La Performance

Tue, 10/06/2014 - 22:59

La performance est cruciale pour garantir une expérience optimale aux visiteurs de votre site. Si le site est lent, les fonctionnalités proposées, même intéressantes, ne suffiront pas à maintenir l’engagement des visiteurs.

Categories: Elsewhere

Commerce Guys: The Case for a Unified Customer Experience and Content-Driven Commerce

Tue, 10/06/2014 - 21:46

Commerce Guys has been promoting the value of content-driven commerce for many years, and we are thrilled to see more and more people talking about this shift occurring in eCommerce. One company that has recognized this important transformation is Forrester Research, who makes a strong and compelling case in their "Content And Commerce: The Odd Couple Or The Power Couple?". In particular, they point out that companies who differentiate themselves by providing a unified user experience to tell their story should consider a tightly integrated solution that provides both a rich Content Management System (CMS) and a flexible eCommerce transactional engine.

Today there is almost no barrier to selling online, making it increasingly difficult for companies to differentiate themselves, create a strong online presence, and attract customers. The solution for many will be to focus more on creating a unique user experience, supported by interesting content, that allows a user to execute transactions anywhere along the buying journey within the context of that information. The challenge today is that this experience requires CMS and eCommerce to work together seamlessly, yet most companies manage these two functions separately with separate systems. This method results in added complexity and a disjointed and inconsistent user experience that is confusing to users and damages their brand.

According to Forrester, "the convergence of content and commerce platforms is already well underway. [They] expect that these two solution categories to be foundational elements in digital customer experience management"1. They go on to say that "In an ideal world, commerce and content platforms would have fully converged into customer experience management platforms, with commerce services seamlessly exposed through best-in-class digital engagement tools and supported by social, testing, and content management services." - "But this ideal isn’t likely to exist in the near future"1.

Drupal + Drupal Commerce Provides Seamless Content & Commerce

The future is NOW - and the reality is that Drupal + Drupal Commerce is the only platform with commerce natively embedded in a CMS, offering a seamless digital experience management solution with a single code base, administration, and database.

Why is this not more widely known?

Like many open source projects, there are limited resources to promote and market the solution. Drupal Commerce has been around for about 3 years and has over 38k active sites. It consists of core and contributed modules that can be dropped into Drupal (which itself has been around for 10+ years and has over 1 million active sites) allowing transactions to occur anywhere. Relationships between content and products is extremely easy to create - something that is hard to do when you bolt together separate CMS and eCommerce platforms. A great example of the power of Drupal + Drupal Commerce is which helps Lush in the UK tell their story, engage their customers, and sell more product.

Who Benefits from a Content & Commerce Solution?

Potentially everyone, but in particular are brands who benefit from a differentiated user experience that enables them to tell their story through interesting content and community engagement and drives sales within the context of that experience. In addition, existing Drupal sites looking to add transactional capability is another obvious fit. With an existing investment in technology, skills and content, there is no better choice than to "drop in" commerce functionality, through Drupal Commerce modules, anywhere. Integrating with a separate eCommerce solution and bolting it onto Drupal is a common approach, but the result is added complexity, cost and valuable customer information that is spread out across multiple systems. Two systems makes it harder to create a level of contextualization and a unified experience that buyers are looking for. Given the increasing importance of targeting and personalizing content and offers, and knowing your customer, having customer information in one place will allow companies to merchandise more effectively.

What Should You Do?

Read the Forrester report. They get it right, and they are one of a growing number of analysts talking about the value of content-driven commerce.   Don't get stuck on features. Yes, they are important, but they will also change, and you need a solution that will adapt and allow you to take advantage of new ideas quickly. Instead, consider how your business will benefit by creating an experience that keeps your customers coming back and makes it easy for them to buy.   If you think your business would benefit from a more rich user experience, or if you just want to simplify your infrastructure with a single platform that can serve both your content and commerce needs, take a look at Drupal Commerce - you will be pleasantly surprised by what you see. -----
1. Stephen Powers, Peter Sheldon with Zia Daniell Wigder, David Aponovich, Rebecca Katz Content And Commerce: The Odd Couple Or The Power Couple? How To Choose Between Using A Web Content Management Solution, An eCommerce Platform, Or Both (Forrester, November 19, 2013) 11,14


Categories: Elsewhere

Chapter Three: Clean Code Helps Maintain a Clean Mind

Tue, 10/06/2014 - 20:53

What is clean code? At last night's SFDUG I gave a brief introduction to two complexity metrics—cyclomatic complexity and npath complexity—and how we can use these metrics to gain insight into the readability and maintainability of one's code.

PHPMD is a tool that analyzes and warns about overly complex code. The metrics alone are useful, but having a tool to crunch the numbers automatically is extremely handy. In addition to PHPMD, I recommended using a plugin for one's editor and/or IDE, such as Syntastic for Vim.

Categories: Elsewhere

DrupalCon Austin News: Thanks for the great time, y'all!

Tue, 10/06/2014 - 18:33

For those of you who made it out to DrupalCon Austin, thank you for helping us make this the best DrupalCon yet! For those who were unable to make it, we hope to see you at one of our upcoming DrupalCons— and, in the meantime, here’s some information to tide everyone over.

Categories: Elsewhere

Paul Johnson: D8Rules achieves 100% DrupalFund goal

Tue, 10/06/2014 - 17:45

There is something awe inspiring which happens when you rally an open source community into positive action. A momentum which you will rarely see elsewhere. There's an important lesson to be learned here, but I will save that for the end.

Over the past week something quite remarkable happened. Whilst at DrupalCon I met Cathy Theys, one of the leading forces in Drupal 8 development. She flagged concerns with me that the D8Rules DrupalFund, a first round of crowd funding development of Drupal 8 version of rules, had just 7 days remaining and that just $5000 of the target $15000 had been pledged. If they didn't hit $15K they would get nothing.

7 days and counting

As DrupalCon social media lead and with access to Drupal's Twitter account I broadcast the message to as wide an audience as possible. It's fair to say that there was an immediate uplift in pledges, but that wained. Drupalers love to prevaricate, leave things until the last moment. I've seen that so many times with DrupalCon session submissions.

Are you aware of the #Drupal8Rules crowdfunding campaign on @Drupalfundus? #Drupal8

— Drupal (@drupal) June 4, 2014

2 days left :: 3pm

Fast forward 5 days and I noticed something quite worrying, 2 days to go and over $6000 in pledges required. I decided take somewhat firmer action. "If #Drupal8Rules doesn't reach 100% by 2 days time they don't get $8605 they get NOTHING"

If #Drupal8Rules doesn't reach 100% by 2 days time they don't get $8605 they get NOTHING

— Paul Johnson (@pdjohnson) June 9, 2014

2 days left :: 9:42pm

The sense of urgency had started to hit the Drupal community. Amazingly just 6 short hours later D8Rules was within sight of reaching 100% funding.

Only $1100 left to reach $15k target #Drupal8Rules We might reach 100% funded today

— Paul Johnson (@pdjohnson) June 9, 2014

1 day left :: 7:59am

Excruciatingly close!

#D8Rules 97% funded. If 50 people give $10 we are done! Less than 2 days left. #Drupal8

— Drupal8 News (@Drupal8iscoming) June 10, 2014

1 day left :: 9:21am

YOU DID IT! Less than 18 hours after an initial push, a few cheeky tweets, LinkedIN posts and Google+ messages (and I wasn't alone) - remarkably the D8Rules DrupalFund project had achieved full funding. To be clear, this is one of several funding stages.

Boom! #D8Rules fully funded The Drupal community is amazing.

— Paul Johnson (@pdjohnson) June 10, 2014

Lessons learned

With the enormous and passionate Drupal community behind you, it is possible to achieve amazing outcomes in a really short timeframe. However, no matter how compelling the story, you still need to work hard and promote your idea. As Dries recently blogged "Entrepreneurship is 80% sales and marketing". The same applies to Drupal funding initiatives.

Even more, if we all pull in the same direction we can make the impossible possible. If you hear of a worthy cause in Drupal, don't hesitate to reach out to me. Happy to help. The Drupal Social Media Request Form is a good place to start. You can also find other great places to promote your Drupal news here such as The Weekly Drop and several podcasts. As techies we aren't all natural marketers, but if you tried a little you might be surprised at the positive outcomes. Never lose sight of the fact that as a Drupalist you have many friends, try and encourage others to become advocates of your idea. If they tell their friends you can reach a LOT of people.

Meet the D8Rules funders

To close, I would like to point towards the #D8Rules funders page. Meet the people who are helping to make Drupal 8 Rules possible.

Further information: Blog by Josef Dabernig on funding D8RulesLearn all about D8Rules plans for Rules in Drupal 8
Categories: Elsewhere

Drupal Easy: DrupalEasy Podcast 132: DrupalCon Austin Day 2 and 3

Tue, 10/06/2014 - 17:11
DrupalEasy Podcast 132

DrupalCon Austin is over and Mike, Ted and Ryan are wrapping up their DrupalCon coverage with 3 interviews: Amy Cham of Blink Reaction talks about her site, Diane Meuller of Red Hat talks to us about Open Shift and a 9-year-old post, and finally Brandon Morrisson of Phase 2 talks about his live taping of his Visual Dimensions podcast, about data visualization.

read more

Categories: Elsewhere

Phase2: Because There’s No Better Way to Relive DrupalCon Austin than a Photo Montage

Tue, 10/06/2014 - 16:35
What a week!

On June 2, thirty-three Phase2 team members headed down to Texas for DrupalCon Austin. More than 3,300 sponsors, attendees, and speakers gathered at the Austin Convention Center for five days of Drupal. Phase2 was proud to renew its Platinum sponsorship of the event, and needless to say we had a great time!

Here are some of our favorite memories from DrupalCon Austin:

The Phase2 Booth…

With the help of a forklift and some dedicated team members, we constructed a 12 foot scaffolding structure to hang our DrupalCon banners. We also built a stage inside!

…in all its glory.

Banners representing our four offices (DC, New York City, San Francisco, and Portland) were lofted into the air to hang above our booth on day three.

Phase2 swag!

Visitors to booth 101 picked up posters, stickers, t-shirts, and Phase2 guitar picks!

Lead Architect Mike Potter gives a demo on Open Atrium 2.

Mike Potter drew a crowd demonstrating how to spin up an OA2 site in the time it takes to drink a coffee.

The Whalers entertain visitors at the Phase2 booth.

In tune with our music-themed booth, we welcomed two local Austin bands to the Phase2 stage at lunch on Wednesday and Thursday.

Phase2 and OpenShift take over the Container Bar!

If there’s one thing we know how to do, it’s throw a good party. Complete with karaoke.

Visual Dimensions, our video podcast, broadcasts a live show from DrupalCon!

Host Brandon Morrison was joined by a panel including Doug Marcey and Adam Shepherd.

Fredric Mitchell, one of Phase2′s awesome speakers, presents to a packed room.

Fredric presented on “30 Drupal 8 API Functions You Should Already Know.” Other Phase2 speakers included Jordan Hirsch, Felicia Haynes, Steven Merrill, and Mason Wendell.

The Phase2 family.

We left DrupalCon Austin exhausted but exhilarated after an amazing week with team members, partners, and other friends in the Drupal community. Time to start counting down the days to DrupalCon Los Angeles 2015! In the meantime, you can find more Phase2 pictures on our Flickr account. Enjoy!

Categories: Elsewhere

Acquia: Use Drush to Sync Your Drupal Installations Between Multiple Environments

Tue, 10/06/2014 - 15:48

Note: This is an updated version of a blog post originally published by Promet Source. Moshe Weitzman contributed to this post.

One of main draws to Drush is the library's ability to make developer's lives easier. There are two simple commands that work using Drush aliases that can help sync database and files between multiple Drupal instances. First, we'll go over setting up an alias file for Drush. After that, we'll document the usage of Drush's sql-sync and rsync commands.

Categories: Elsewhere Language lessons: Default language

Tue, 10/06/2014 - 14:00

When you are going to have multiple language set up on your Drupal site, it's important to set the default language appropriately before creating content. Once that is set, content will normally be set to be in that language, and any translations made on the site will be assumed to be from the default language as the source. So changing it is not a good idea, as there's no way to differentiate between translations made before and after the switch in Drupal 6 or 7! (This has been resolved in Drupal 8.)

So, once you've thought first about what is necessary for your multilingual site, the next step is to pick the right default language, ideally before setting up anything else, as everything is 'in' a language in some way. It's usually an obvious choice, but did you know that the Drupal software itself and associated modules (i.e. the codebase, referred to as the 'interface') is all written in U.S. English (as per the coding standards)?

Categories: Elsewhere

Blair Wadman: Revert and update a Drupal feature module

Tue, 10/06/2014 - 11:59

This is the third and final part of the series on Features. In the first part, we looked at how to create a feature module. In the second part, we looked at how to add a new component to a feature and recreate it. In this part, we are going to walk through how you can change a component that is already in a feature and then either update or revert the feature.

Tags: FeaturesDrupal Site buildingPlanet Drupal
Categories: Elsewhere

Web Omelette: 4 tools you should definitely use for Drupal development

Tue, 10/06/2014 - 09:05

Developing Drupal sites can be quite a challenge and adventure. And this comes from those who call themselves Drupal developers. Men and women of PHP who work with other frameworks and applications most likely find it even more cumbersome to understand. However, Drupal is fostered by a big community of enthusiastic people who love it, myself included. But in all honesty, the more you work with it, the more you develop this love/hate relationship with all the quirks of Drupal development.

But one thing is certain, and this is applicable to other areas of web development as well: the tools you use for the job can make a big difference in the experience you have. And Drupal makes no exception. I mean, remember when we were writing PHP in Notepad and that one missing semicolon added 2 hours of debugging that day?

In this article I would like to share with you 4 tools that I use for Drupal development. I heavily rely on them to minimise frustration, increase productivity and lower development time. And I can guarantee you that if you are serious about Drupal development and you are not using them, you are missing out. But if you are, kudos, do share some of your experiences that further demonstrate their power.

So here we are, I guess in order of complexity, the 4 tools in my belt when I run vagrant up to spin up a project on my local environment. I will say a few words about each, but I can't go into all of their features. That's for you to explore after I give you a taste of what they can offer.

Devel and Search Krumo modules

Devel is the most used Drupal development module built for aiding with debugging code, generating content and all sorts of other dev tasks. Search Krumo is yet another cool module that plugs into it in order to give us a hand with navigating through huge array structures. And if you know Drupal 7, it is all about big arrays.

These modules are probably the first solution for debugging variables in Drupal. Using Devel's dsm(), dpm(), and krumo() functions in your code you can print out arrays, objects and whatever you need for a great overview of what you have in scope at that moment of execution. And they are not the only ones...

Another great use for the Devel module is content generation. It has a series of submodules that can generate nodes, taxonomy terms, users and more. Sometimes you need 500 nodes on the site to test something out. Additionally, you can use it to execute PHP code in the Drupal environment, switch between users on the site and other awesome functionality. So it's a must have on any Drupal development environment.


Drush is an awesome command line tool for Drupal that speeds up many tasks. Some people call it the swiss army knife of Drupal and you can't really argue the opposite.

Drush allows you to perform a host of Drupal tasks from the command line. You can download and enable/disable/uninstall/update modules or Drupal core and all sorts of other helpful jobs. This great list of core commands can give you an overview of what you can do with Drush. And if you are looking for some help with setting Drush up on your server, you can read this article I wrote on the subject.

Another great thing about Drush is that aside from all the awesome core commands, you can declare your own. This way, you can expose some of your custom functionality to the command line. This goes behind development and can help with maintenance or even production jobs that need to run with cron. So it truly is versatile.

A good IDE like PHPStorm

I mentioned before the good ol' times (not really) when Notepad was the editor of choice for many developers. Luckily nowadays we don't have to suffer through that as we can use IDEs for coding. I myself use PHPStorm and is of great help.

An IDE can speed up your development time by preventing code mistakes, highlighting syntax for great readability, code hinting for classes and functions in your project and many others. And with Drupal, all of these are important. Since Drupal 7 is mostly procedural you need to be aware of many functions and parameters. The IDE great reduces the time you spend online researching these APIs. And not to mention the integrations you can create with these API documentation resources.

Another great use of IDEs (which for me is the most important) is debugging. Integrating PHPStorm with XDebug on my local server really changed things around. But more on that in the next point.


As great as the Devel module is for printing out variables to the screen, it does not come close to Xdebug when we talk about debugging. After setting it up, all you have to do is place a breakpoint in your code and load your site page. The execution stops at the breakpoint (that was hopefully supposed to be executed) and you have access to a wealth of contextual information. You get all the global and scope variables that you can navigate through, a great callstack of what functions/methods have been triggered so far and many others.

Another cool feature is that you can play forward the execution line by line and jump inside of to be called functions to see where the code is heading. This is great for debugging where your code fails, at which point does that exception get thrown, or why that variable is null. So I do recommend checking it out.


And there you have it: 4 tools you can start using today to make you Drupal development experience more efficient. Using Drush and the Devel module are really only specifically for Drupal, but the use of a good IDE and XDebug is applicable to all other PHP projects as well. And I can guarantee you they are all worth using.

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

Marek Sotak: Inline Manual 1.1 release - Rules support - onboard new users like a pro

Tue, 10/06/2014 - 08:15

The fastest way to teach your users how to use your web application got even faster. We have integrated the great Rules module, so you can easily define logic within your Drupal installation when to launch specific tutorials.

Imagine you have built a website for your client and now you need to train the editors how to work with content. You can use Inline Manual for this already, instead of doing workshops or screencasts, however, what if there are new employees/editors coming in afterwards? How would you get them quickly learn the system?

Categories: Elsewhere

Greater Los Angeles Drupal (GLAD): Los Angeles Announced as Host City for DrupalCon North America 2015

Mon, 09/06/2014 - 22:33

You are invited to DrupalCon Los Angeles!

We're excited to invite you to Los Angeles, home to Hollywood and Silicon Beach, where technology and creativity meet.

Some of the world's best and biggest museums, universities and entertainment giants are in Los Angeles — and they all use Drupal. A Drupal powerhouse, Los Angeles is one of the most active areas for Drupal in the world. The Drupal community in and around Los Angeles organizes hundreds of Drupal events each year, including GLADCamp, Drupal Design Camp LA and DrupalCamp LA.

While you're enjoying DrupalCon, your family can enjoy Disneyland, bike rides at the beach, and culture and science at the Getty, Museum of Modern Art and the California Science Center. The Downtown area has a thriving nightlife, walkable streets and contrary to popular belief, is the heart of the LA Metro and can be enjoyed car-free.

We welcome you to DrupalCon Los Angeles and look forward to sharing our love for all the things that make Los Angeles spectacular.

Many thanks to CloudNYNE for the splash image and to Exaltation of Larks for writing the announcement used on the DrupalCon Los Angeles website.

Tags: DrupalCon LAPlanet Drupal
Categories: Elsewhere

OhTheHugeManatee: Authenticated User Caching Concepts in Drupal 7

Mon, 09/06/2014 - 22:21

Drupal has a wide variety of highly effective solutions for caching anonymous user content. The typical setup is APC, Memcached or Redis, and Varnish in front, and this can easily serve thousands of concurrent anonymous users. There is excellent documentation out there discussing this kind of simple caching.

But what about authenticated users? You can cache elements of the page using a method like Render cache, Entity Cache, or Views Content Cache. But Drupal still has to assemble each page for your users, a relatively heavy operation! If you want to address hundreds or thousands of authenticated users, you’re simply SOL by these traditional approaches.

Enter the Auth Cache suite of modules. Though this project has been around for quite some time, it had a reputation of being finicky and hard to set up. It got a significant rewrite in the last year thanks to znerol, and is now a powerhouse of a module that brings authenticated user caching much closer to regular users.

I will say that this is still not for the squeamish. You have to really understand the building blocks of your site, and you will have to make a plan for each unique layout on your site. There are some page elements that are quite hard to build this way, but for the most part Authcache makes this easy.

The theory

The idea behind authenticated user caching is simple. We already have a great caching mechanism for pages that stay exactly the same for all users. So we simply identify the parts of the page that will change for each user, and use a placeholder for them instead. Think of it as a tag in HTML. This way the page caching mechanism can ignore the customized content, and focus on the stuff that IS the same across all requests.

There are three major ways of doing this placeholder: AJAX, ESI, and Cookies.

With AJAX, you just include a little JS that says “fill this DIV with the contents of”. The client’s web browser makes a second call to the server, which is configured to allow /user/customized/thing through the cache all the way to your website. Drupal (or whatever you’re running) fills in the HTML that belongs in that div and returns it to the browser. Congratulations! You just served an authenticated user a page which was 99% cached. You only had to generate the contents of one div.

ESI is short for Edge Side Includes, a small extension to HTML which effectively does the same thing as that Javascript, but on the “Edge server”. The Edge server is whatever service touches the HTTP request last before sending it to the client. Apache, NGINX, Varnish, pound… you want this to happen as far down the stack as you control. An ESI tag in your HTML looks like this:

1 <esi:include src="" onerror="continue"/>

It’s pretty clear, even to a human reader, what this tag means: “replace this tag with the contents of”. ESI actually supports some simple logic as well, but that’s not really relevant to what we’re doing here.

The only difference between ESI and AJAX is where the placeholder is filled. With ESI it happens on the edge service, and with AJAX it happens in the client browser. There is a subtle difference here: a page with ESI will not be delivered until all the ESI calls have returned something, while an AJAX page will return right away, even if the components don’t immediately appear. On the other hand, ESI is much better for degraded browsers. YMMV.

The last method is using Cookies. You can store arbitrary information on cookies, as long as you’re careful about security. That can be a very effective way to get certain limited information through a caching layer. Authcache actually comes with an example module for just such a use case. It passes the user’s name and account URL in a cookie, so you can display it in a block.

This is effective for very small amounts of information, but keep it limited. Cookie headers aren’t designed to hold large quantities of data, and reverse proxies can have a hard time if you put too much information in there. Still, it’s a neat trick that can cover you for that “Hello Username” block.

Authcache in Drupal

The Authcache suite of modules tries to automatically implement AJAX and/or ESI for you. It actually goes one step further, and implements a caching layer for those “fragments” which are to be returned via ESI/AJAX. The fragments can be stored in any caching system which implements DrupalCacheInterface, ie any caching module you’ve heard of. Memcache, APC, File Cache, Redis, MongoDB. The full page HTML with placeholders can be cached in Drupal’s normal page cache, in Boost, or in Varnish.

Once you have these caching mechanisms defined, it’s just a question of marking sections of your site which need a second callback. Authcache presents a large number of modules to do this. You can define any of the following as requiring a second call:

  • Blocks
  • Views
  • Panels Panes
  • Fields
  • Comments
  • Flags
  • Forms
  • Forums
  • Polls
  • Votes

… and that’s all without writing a single line of custom code! Each one of those elements gets a new “Authcache” setting, where you can define it as needing a second callback, and set the method for the callback as either AJAX or ESI. You can even fall back to another method if the first one fails!

A good example of how this works is the Forms integration. Authcache will modify any and all forms on your site, so that they have an ESI or AJAX placeholder for the form token. This means that the form itself can be stored in your page cache (Varnish, Boost, or whatever), and the form token will be filled in automatically! That’s a phenomenal speed improvement without any configuration beyond enabling the module.

Setting up Authcache is a little complicated, and I’ll cover that in depth in my next post. But once the basic AJAX or ESI support is set up and these modules are enabled, caching authenticated users becomes a question of visiting each unique layout on your site and making a plan for each element that involves user customization. Authcache makes this easy.

Next post: How to configure Authcache on Drupal 7.

Categories: Elsewhere Bug triage on Commons

Mon, 09/06/2014 - 20:39
Tags: planet drupaldrupal

I will try to help out in the Drupal Commons issue queue for the 7.x-3.x version on Thursday. Come and join me. The main objective of the bug triage is to narrow down the bug count and maybe fix some low-hanging fruit in the issue queue, so it will be easier for the main developers to get stuff done and focus on the most important stuff.


On Thursday from 10.30 CEST til around 14.30 CEST I will be working an online in #drupal-commons.

Want to join?

Everybody can join. We will just meet up in the IRC channel for #drupal-commons. You can join at any time during that period.

There is plenty to do for people at different skill levels.

Sign up for the online event here.

Updates for the efforts

Updates for our efforts will be posted on this page. 

Categories: Elsewhere

LightSky: 5 Must Have Modules for SEO in Drupal

Mon, 09/06/2014 - 20:25

I have been doing Drupal development for the last four years. During that time, one concern from potential clients has been that Drupal isn’t SEO friendly. While Drupal may not come ready for SEO out of the box, with a few additional modules and some proper configuration, Drupal can be a successful SEO platform. Below are what I consider must have modules for Drupal SEO.

1. Pathauto
Pathauto works by creating automatic URL aliases based upon tokens that you set in the configuration. By default, Drupal’s URL structure looks similar to “/node/75” where 75 is the node id of the page. With Pathauto, your urls will transform into keyword rich URLS such as “blog/five-must-have-modules-drupal-search-engine-optimization”. Each URL pattern can be configured on a per-content type basis, and you can add alias patterns for your taxonomies as well as your users.

2. Global Redirect
The Global Redirect module works by automatically redirecting visitors from the node/xx URL to the aliased version of the URL. This is important as it prevents duplicate content penalties within Drupal. This module also allows you to add a canonical tag to your pages as well.

3. MetaTag
The Metatag module allows you the option of configuring metatags for your site at both the individual and global level. As of the time of this writing, the Metatag module has support for the following tags:

4. XML SiteMap
The XML SiteMap module create sitemaps that you can use to submit to Google, Bing and Yahoo’s Webmaster tools. You can indicate which content types you’d like to see included and indicate the priority of those content type pages on your site. The benefit of submitting an XML Sitemap is so that the search engines know about all of the pages on your site. Without it, they will only know about the pages found during their normal crawling process which sometimes misses pages.

5. SEO Checklist
The SEO Checklist module doesn’t add any functionality to your site directly, but it does serve as a reminder for SEO related tasks that still need to be completed. It separates items by category and allows you to check off items as they are completed. SEO checklist also saves a timestamp of each completed action so that other site administrators will know when items are completed. This module is updated frequently with the latest SEO techniques and helps ensure that you are maximizing SEO for your site.


LightSky recommends Drupal as a solution to many of our clients who want easy to use and maintain websites that are also flexible and secure. One of the great features of Drupal is that it is so easy to customize. Adding the above modules for SEO is an example of how Drupal can easily be adapted for our clients’ needs. What are some of your favorite modules for SEO in Drupal?

Categories: Elsewhere

EchoDitto Tech Blog: OS X 10.9 Local Development Environment: Apache, PHP, and MySQL with Homebrew

Mon, 09/06/2014 - 15:55

code {display:inline;padding:0;margin:0;border:none;} There's nothing quite like setting up everything on your Mac for Drupal (or other PHP) development in a way that things just work and don't need constant fiddling. This guide will walk you through using Homebrew to install Apache, PHP, and MySQL for a "MAMP" development environment. We'll also use DNSMasq and Apache's VirtualDocumentRoot to set up "auto-VirtualHosts," and add a firewall rule to allow the default http port 80 to be used without running Apache as root.

At the conclusion of this guide, you'll be able to create a directory like ~/Sites/project and access it at without editing your /etc/hosts file or editing any Apache configuration. You'll also be able to use with auto-VirtualHosts for accessing your sites on other devices in your local network.

We also configure PHP and MySQL to allow for enough flexibility for complex operations generally only reserved for development and not production.

The OS X operating system comes with Apache and PHP pre-installed, and I've previously recommended utilizing them to some degree for getting a local PHP development environment on your Mac. Since then, the community around Homebrew has improved dramatically and I now recommend that our developers at EchoDitto use Homebrew exclusively for all components.

Homebrew Setup

If you've not already install Homebrew, you can follow the instructions at, or simply run the following command:

ruby -e "$(curl -fsSL" brew doctor brew update PATH Variable

Since OS X already comes with PHP and Apache, we'll want to make sure that our brew-installed versions appear in the shell path before the built-in ones. The following command adds logic to your ~/.bash_profile to ensure the Homebrew directory is in the beginning of $PATH.

echo "export PATH=\$(echo \$PATH | sed 's|/usr/local/bin||; s|/usr/local/sbin||; s|::|:|; s|^:||; s|\(.*\)|/usr/local/bin:/usr/local/sbin:\1|')" >> ~/.bash_profile && source ~/.bash_profile MySQL

The following commands will download and install the latest version of MySQL and do some basic configuration to allow for large imports and a couple other miscellaneous configuration changes.

brew install -v mysql   cp -v $(brew --prefix mysql)/support-files/my-default.cnf $(brew --prefix mysql)/my.cnf   cat >> $(brew --prefix mysql)/my.cnf <<'EOF' # EchoDitto changes max_allowed_packet = 2G innodb_file_per_table = 1 EOF   sed -i '' 's/^# \(innodb_buffer_pool_size\)/\1/' $(brew --prefix mysql)/my.cnf

Now we need to start MySQL using OS X's launchd, and we'll set it to start when you login.

[ ! -d ~/Library/LaunchAgents ] && mkdir -v ~/Library/LaunchAgents   [ -f $(brew --prefix mysql)/homebrew.mxcl.mysql.plist ] && ln -sfv $(brew --prefix mysql)/homebrew.mxcl.mysql.plist ~/Library/LaunchAgents/   [ -e ~/Library/LaunchAgents/homebrew.mxcl.mysql.plist ] && launchctl load -w ~/Library/LaunchAgents/homebrew.mxcl.mysql.plist

By default, MySQL's root user has an empty password from any connection. You are advised to run mysql_secure_installation and at least set a password for the root user.

$(brew --prefix mysql)/bin/mysql_secure_installation Apache

Start by stopping the built-in Apache, if it's running, and prevent it from starting on boot. This is one of very few times you'll need to use sudo.

sudo launchctl unload -w /System/Library/LaunchDaemons/org.apache.httpd.plist 2>/dev/null

Apache is not in the default repository of Homebrew formulas, nor are some dependencies, so we use the brew tap command to add other formula repositories.

brew tap homebrew/dupes brew tap homebrew/apache

We'll install Apache 2.2 with Apr and OpenSSL from Homebrew as well instead of utilizing the built-in versions of those tools.

brew install -v httpd22 --with-brewed-apr --with-brewed-openssl

We'll be using the file ~/Sites/httpd-vhosts.conf to configure our VirtualHosts, so we create necessary directories and then include the file in httpd.conf.

[ ! -d ~/Sites ] && mkdir -pv ~/Sites   touch ~/Sites/httpd-vhosts.conf   USERHOME=$(dscl . -read /Users/`whoami` NFSHomeDirectory | awk -F"\: " '{print $2}') cat >> $(brew --prefix)/etc/apache2/2.2/httpd.conf <<EOF # Include our VirtualHosts Include ${USERHOME}/Sites/httpd-vhosts.conf EOF

We'll create a folder for our logs in ~/Sites as well.

[ ! -d ~/Sites/logs ] && mkdir -pv ~/Sites/logs

Now to fill in the contents of ~/Sites/httpd-vhosts.conf that we included in httpd.conf earlier. Note that this is one command to copy and paste! Start with USERHOME through the second EOF has a single copy and paste block for the terminal.

USERHOME=$(dscl . -read /Users/`whoami` NFSHomeDirectory | awk -F"\: " '{print $2}') cat > ~/Sites/httpd-vhosts.conf <<EOF # # Use name-based virtual hosting. # NameVirtualHost *:80   # # Set up permissions for VirtualHosts in ~/Sites # <Directory "${USERHOME}/Sites"> Options Indexes FollowSymLinks MultiViews AllowOverride All Order allow,deny Allow from all </Directory>   # For http://localhost in the users' Sites folder <VirtualHost _default_:80> ServerName localhost DocumentRoot "${USERHOME}/Sites" </VirtualHost>   # # VirtualHosts #   ## Manual VirtualHost template #<VirtualHost *:80> # ServerName # CustomLog "${USERHOME}/Sites/logs/" combined # ErrorLog "${USERHOME}/Sites/logs/" # DocumentRoot "${USERHOME}/Sites/" #</VirtualHost>   # # Automatic VirtualHosts # A directory at ${USERHOME}/Sites/webroot can be accessed at # In Drupal, uncomment the line with: RewriteBase /   # This log format will display the per-virtual-host as the first field followed by a typical log line LogFormat "%V %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combinedmassvhost   # Auto-VirtualHosts with .dev <VirtualHost *:80> ServerName dev ServerAlias *.dev   CustomLog "${USERHOME}/Sites/logs/dev-access_log" combinedmassvhost ErrorLog "${USERHOME}/Sites/logs/dev-error_log"   VirtualDocumentRoot ${USERHOME}/Sites/%-2+ </VirtualHost>   # Auto-VirtualHosts with <VirtualHost *:80> ServerName xip ServerAlias *   CustomLog "${USERHOME}/Sites/logs/dev-access_log" combinedmassvhost ErrorLog "${USERHOME}/Sites/logs/dev-error_log"   VirtualDocumentRoot ${USERHOME}/Sites/%-7+ </VirtualHost> EOF Run with port 80

You may notice that httpd.conf is running Apache on port 8080, but the above are using port 80. The next two commands will create and load a firewall rule to forward 8080 requests to 80. The end result is that we can use port 80 in VirtualHosts without needing to run Apache as root.

The following single command will create the file /Library/LaunchAgents/com.echoditto.httpdfwd.plist as root, and owned by root, since it needs elevated privileges.

sudo bash -c 'export TAB=$'"'"'\t'"'"' cat > /Library/LaunchAgents/com.echoditto.httpdfwd.plist <<EOF <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" ""> <plist version="1.0"> <dict> ${TAB}<key>Label</key> ${TAB}<string>com.echoditto.httpdfwd</string> ${TAB}<key>ProgramArguments</key> ${TAB}<array> ${TAB}${TAB}<string>sh</string> ${TAB}${TAB}<string>-c</string> ${TAB}${TAB}<string>ipfw add fwd,8080 tcp from any to me dst-port 80 in &amp;&amp; sysctl -w net.inet.ip.forwarding=1</string> ${TAB}</array> ${TAB}<key>RunAtLoad</key> ${TAB}<true/> ${TAB}<key>UserName</key> ${TAB}<string>root</string> </dict> </plist> EOF'

This file will be loaded on login and set up the 80->8080 port forward, but we can load it manually now so we don't need to log out and back in.

sudo launchctl load -w /Library/LaunchAgents/com.echoditto.httpdfwd.plist PHP

The following is for the latest release of PHP, version 5.5. If you'd like to use 5.3, 5.4 or 5.6, simply change the "5.5" and "php55" values below appropriately. (Note: if you use 5.3, the OpCache extension instructions are different. They will be posted below after the instructions for newer versions.)

Start by adding the PHP tap for Homebrew. PHP 5.3 needs an additional tap, so skip the second command if you are using 5.4 or higher.

brew tap homebrew/php   # Skip this if using PHP 5.4 or higher brew tap homebrew/versions

Install PHP and mod_php. This command will also load the PHP module in the httpd.conf file for you.

brew install -v php55 --homebrew-apxs --with-apache

Add PHP configuration to Apache's httpd.conf file.

cat >> $(brew --prefix)/etc/apache2/2.2/httpd.conf <<EOF # Send PHP extensions to mod_php AddHandler php5-script .php AddType text/html .php DirectoryIndex index.php index.html EOF

Set timezone and change other PHP settings (this is a single command). sudo is needed here to get the current timezone on OS X (in previous versions of OS X it wasn't needed, I'm not sure why it is now).

sed -i '-default' "s|^;\(date\.timezone[[:space:]]*=\).*|\1 \"$(sudo systemsetup -gettimezone|awk -F"\: " '{print $2}')\"|; s|^\(memory_limit[[:space:]]*=\).*|\1 256M|; s|^\(post_max_size[[:space:]]*=\).*|\1 200M|; s|^\(upload_max_filesize[[:space:]]*=\).*|\1 100M|; s|^\(default_socket_timeout[[:space:]]*=\).*|\1 600|; s|^\(max_execution_time[[:space:]]*=\).*|\1 300|; s|^\(max_input_time[[:space:]]*=\).*|\1 600|;" $(brew --prefix)/etc/php/5.5/php.ini

Add a PHP error log; without this, you may get Internal Server Errors if PHP has errors to write and no logs to write to (this is a single command; be sure to copy and paste the lines containing USERHOME through the last EOF as a single command).

USERHOME=$(dscl . -read /Users/`whoami` NFSHomeDirectory | awk -F"\: " '{print $2}') cat >> $(brew --prefix)/etc/php/5.5/php.ini <<EOF ; PHP Error log error_log = ${USERHOME}/Sites/logs/php-error_log EOF

This weird little "hack" is needed to fix a permissions problem with using pear or pecl.

touch $(brew --prefix php55)/lib/php/.lock && chmod 0644 $(brew --prefix php55)/lib/php/.lock

The OpCache extension will speed up your PHP environment dramatically, and it's easy to install for 5.4 and higher. If you are looking to install PHP 5.3, skip this block.

brew install -v php55-opcache

Skip this block unless you are using PHP 5.3. Because there is no php53-opcache Homebrew formula, we can install it with pecl and replicate the same configuration file.

pecl install zendopcache-beta   sed -i '' "s|^\(zend_extension=\"\)\(opcache\.so\"\)|\1$(php -r 'print(ini_get("extension_dir")."/");')\2|" $(brew --prefix)/etc/php/5.3/php.ini   echo "[opcache]" > $(brew --prefix)/etc/php/5.3/conf.d/ext-opcache.ini   grep -E '^zend_extension.*opcache\.so' $(brew --prefix)/etc/php/5.3/php.ini >> $(brew --prefix)/etc/php/5.3/conf.d/ext-opcache.ini   sed -i '' '/^zend_extension.*opcache\.so/d' $(brew --prefix)/etc/php/5.3/php.ini   # "php54" is not a typo here- I'm using a sample config file from # another recipe for my config file in php53 grep -E '^[[:space:]]*opcache\.' \ $(brew --prefix)/Library/Taps/homebrew/homebrew-php/Formula/php54-opcache.rb \ | sed 's/^[[:space:]]*//g' >> $(brew --prefix)/etc/php/5.3/conf.d/ext-opcache.ini

And continue with steps for all PHP versions: give OpCache some more memory to keep more opcode caches.

sed -i '' "s|^\(opcache\.memory_consumption=\)[0-9]*|\1256|;" $(brew --prefix)/etc/php/5.5/conf.d/ext-opcache.ini Start Apache

Start Homebrew's Apache and set to start on boot.

ln -sfv $(brew --prefix httpd22)/homebrew.mxcl.httpd22.plist ~/Library/LaunchAgents   launchctl load -w ~/Library/LaunchAgents/homebrew.mxcl.httpd22.plist DNSMasq

I've covered this before, but we'll list the commands here again for completeness. This example will have any DNS request ending in .dev reply with the IP address

brew install -v dnsmasq   echo 'address=/.dev/' > $(brew --prefix)/etc/dnsmasq.conf   echo 'listen-address=' >> $(brew --prefix)/etc/dnsmasq.conf

Because DNS services run on a lower port, we need to have this run out of /Library/LaunchAgents, so we do need to use sudo for the initial setup.

sudo cp -v $(brew --prefix dnsmasq)/homebrew.mxcl.dnsmasq.plist /Library/LaunchAgents   sudo launchctl load -w /Library/LaunchAgents/homebrew.mxcl.dnsmasq.plist

With DNSMasq running, configure OS X to use your local host for DNS queries ending in .dev

sudo mkdir -v /etc/resolver   sudo bash -c 'echo "nameserver" > /etc/resolver/dev' Great! So, what did I do?

We set up Apache to run on boot on port 8080 with mod_php with auto-VirtualHosts for directories in the ~/Sites folder. The OS X firewall will forward all port 80 traffic to port 8080, so we don't have specify the port number when visiting web pages in web browsers. MySQL is installed and set to run on boot as well. DNSMasq and some OS X configuration is used to direct any hostname ending in .dev to the local system to work in conjunction with Apache's auto-VirtualHosts.

What do I do now?

You shouldn't need to edit the Apache configuration or edit /etc/hosts for new local development sites. Simply create a directory in ~/Sites and then reference that foldername + .dev in your browser to access it.

For example, use drush to download Drupal 7 to the directory ~/Sites/firstproject, and it can then be accessed at without any additional configuration. A caveat - you will need to uncomment the line in Drupal's .htaccess for RewriteBase / to work with the auto-VirtualHosts configuration.

What about this thing?

If your Mac's LAN IP address is, you can access sites from any other device on your local network using You can test a websites on your Mac with your phone/tablet/etc. Pretty great, right?

What if this "auto-VirtualHost" doesn't work for me?

If you need to create a manual VirtualHost in Apache because the auto-VirtualHost does not work for your configuration, you may need to declare it before the auto-VirtualHosts if you're also going to use .dev as the TLD. Otherwise the auto-VirtualHost block will be accessed first.

Photo by Florian Klien

Categories: Elsewhere

Drupal Watchdog: Get Started Fast with Online Drupal Platforms

Mon, 09/06/2014 - 15:11

Create a database ... copy files onto a web server ... set file permissions....

If you’re new to website development, the standard instructions for installing Drupal are likely to be a bit daunting. Even if you’re a seasoned pro, setting up a well-designed development environment — then tweaking it for optimal Drupal hosting — takes time and effort that you might prefer to spend on building sites.

Luckily, there’s a growing set of online platforms that take the muss and fuss out of Drupal site building. As well as easing development, online Drupal platforms offer a range of server-side optimizations for fast and secure site hosting. Here’s a quick rundown of some of the options, with both features and limitations of each.

Drupal Gardens

Want to spin up a quick Drupal 7 site? Drupal Gardens is your easiest option. Think of it as the Drupal equivalent of

Nedjo Rogers

Nedjo Rogers has been an active Drupal contributor since posting his first module, in 2003. He is the technical lead of the Open Outreach Drupal distribution for nonprofit organizations, and a partner at Chocolate Lily Web Projects.

Categories: Elsewhere