Makina Corpus: Howto: using Twig in Drupal 7

Planet Drupal - Thu, 2015/06/25 - 4:47pm
Using Twig in Drupal 7 is indeed possible: here's how to anticipate Drupal 8, and use right now the theme engine bundled in the next version of our favorite CMS.

Amazee Labs: Creating nested lists with panelizer and view panes

Planet Drupal - Thu, 2015/06/25 - 3:00pm
Creating nested lists with panelizer and view panes Marc Pfändler Thu, 06/25/2015 - 15:00

For one of our customer projects, we wanted to have a list with all past projects. There are two types of projects selected among applicants every year: a winner and there are several finalists or runner ups.

The idea was to show the winner of each year followed by the finalists/runner ups of the year. This should be done in a list where the actual year is the top one followed by the others.

The following is my approach for solving this request. A step by step guide:

1. Creating a view pane like the following:

In this view, the displays are created. We have two different ones. The selected one shows the finalists of the year, which is added via a contextual filter. The second one shows the winner.

The view will show winners or finalists for a given year based on the contextual filter configured. In order to use the view with panels, we created displays of type view pane. Note that in the pane settings, we specify the argument input to get the required context from panels. Thus the argument input is set up like this:

Later in step 3. When we add the displays to the panelizer, we will set the argument.

2. Panelize the taxonomy

In order to have these two views sorted by years, they will be attached to the “Year” taxonomy, to do this we need to panelize it.

The new view mode configured is displayed a bit wrong in panelizer for the taxonomy. So we have to go via Structure -> Taxonomy -> Year -> Panelizer -> list_winner_finalists.

3. Attach the winner and finalist view panes to the panelized taxonomy

After panelizing the taxonomy we can attach the before created view panes to it. As described, first winners and then the finalists. Use the top left gear icon, Add content and select view panes to choose from the defined view pane displays.

We have set the argument input in step 1 and now we need to select it here to provide the taxonomy terms as context to the view panes:

4. Creating a taxonomy view

Last step is to create a view which shows the taxonomy that uses the panelized viewmode and to sort this view by year.

5. Be very happy with the result:

We list all the years from most recent to earliest. And for every year we list the winner and multiple finalists.

The final result can be seen live here:



Commerce Guys: Cutting the Cord - Why choosing an open-source framework is analogous to ditching your cable provider

Planet Drupal - Thu, 2015/06/25 - 2:00pm
In today’s tech-driven culture, any business that’s looking to succeed must have an online presence. eCommerce, is rapidly becoming pervasive. There are plenty of high-cost, enterprise software solutions available as well as inexpensive SaaS options that provide turn-key ecommerce solutions.

Regardless of which solution you choose, both the enterprise solutions and the smaller SaaS solutions create liabilities and risk for your business. The reason is that they both lock your business into a cycle of license (or maintenance) fees and deep dependency on a single vendor to extend the feature set and remain relevant in the fast paced world of technology.

eCommerce software = Cable (or Satellite) TV. Think about it. How much of your TV lineup do you actually watch? Probably less than 10%. In fact, back in September of 2014, Nielson reported that most American Households watch only 17 of the 189 channels that the average TV service provider pipes into our homes. This wouldn’t feel so bad if the average cost for pay-TV service wasn’t climbing at an astronomical rate.

So it’s no surprise that many are deciding to ditch their cable company and get the specific entertainment options they actually use, without over-paying for services they don’t want and will never use. People ultimately want to choose their entertainment options and control what it costs. Do a Google Search for cord cutting and you’ll get countless articles detailing fed-up customers and fearful pay-TV executives. You’ll get even more links to how-to’s and YouTube videos with advice on how to get the content you want, often for free… or at the very least, less expensively via streaming services like Netflix, Hulu and others using devices like an Apple TV or Google ChromeCast (plus, more every day). It’s clearly a tipping point for home entertainment, and the big companies who provide the content are taking notice.

Something very similar is happening online.

Companies are also beginning to look at their eCommerce platform in the same light. Rather than a huge code base and feature set that makes vast assumptions about their requirements, many of which they will never use or simply won't fit their business model, they are looking for solutions that can exactly meet their current and future needs without costing a fortune.

As mentioned previously, any business today must be online. It’s not a nice to have anymore or a service reserved for companies with specific plans to sell online. Your customers will be shopping online. If not with you, then with your competitors. Companies today are increasingly choosing free open source solutions rather than proprietary solutions that lock them into contracts, license fees, and a single vendor. Those companies choose software that offers a flexible framework rather than rigid technology that can’t deliver on all their requirements. They are embarking on a strategy centered around a web publishing framework that allows them to build something that exactly matches their business needs and doesn’t come pre-packaged with anything that will compromise the experience the customer receives.

Only need a catalogue online? Get that without having to disable features that come with the enterprise software that’s costing X over the next Y years. Ready for eCommerce? Enable it. Need a new feature? Build it in-house, or pay a web developer to give you exactly what you want. The alternative is to submit a feature request and wait helplessly through the software vendors next (and next, and next) release cycle for the feature you need. An open-source framework allows you to build a modular web application with just the features you need... and none of the features you don’t.

That’s why Drupal is the perfect software for web publishing. And why over 1 million sites have been built with Drupal. Its modular architecture and community supported framework allows companies to get just the experience they are looking for without the bloat.

And thankfully for companies who have eCommerce requirements, Drupal Commerce provides the perfect extension of that framework. It brings the modular thinking to selling online, lets merchants pick only the features they need to sell their products online, and skips the licensing, the bloatware and the software release cycle. If you need to enable a specific third-party connection, or have a unique product to sell (like digital goods or subscriptions) there are modular components that let you do that. Enable them and you’re good to go. And if you’ve come up with a new idea and there isn’t a module that lets you just turn that on, well then, there are many services companies with developers ready to build it and huge community of developers to support it.

So if you’re planning on cutting the cord at home (or maybe you already have), why not do the same with your eCommerce solution??

Microserve: Drupal go-live checklist (revisited)

Planet Drupal - Thu, 2015/06/25 - 11:52am

A handy tool for every developers arsenal: a simple go-live checklist! When a site is finally ready to launch it can be easy to get excited and forget some of the important details, but having a checklist to hand can prevent any last minute slip ups. 

Here's my own personal checklist and below it a further description of each item with some hints and tips. Leave me a comment if you have any questions or think I've missed anything important!

Go-Live Checklist
  1. Check Status Report and Site Information page
  2. Disable Developer modules
  3. Disable any theme specific development settings
  4. Disable error message display
  5. Configure performance settings
  6. Check log messages and fix any apparent issues
  7. Check 404 and 403 reports
  8. Ensure custom 403 and 404 pages are in place
  9. Enable and configure Google Analytics module
  10. Ensure all Web Services are setup correctly
  11. Audit users accounts and ensure all admins use a secure password
  12. Ensure best practices are followed for SPAM prevention
  13. Configure basic SEO practices
  14. Test email

...and here's those points explained in detail:

1. Check Status Report and Site Information page

You should always start by checking the status report - /admin/reports/status. This page shows you all of the basic requirements for your Drupal site to run correctly.

Any issues will be highlighted in red and typically have a link to a configuration page or the documentation to help you resolve the problem.

The site information config page holds all of the most common site information, such as the website name and email address.

It's worth double checking that all of this information is correct. It could be quite embarrassing if your first newsletter arrives from

2. Disable Developer modules

Developer modules unnecessarily bloat your website so these should be disabled when going live. If they haven't been configured out the box then you can safely uninstall these too without worrying about losing any information.

It’s quite common to cram your website with contrib modules only to find out that numerous modules haven’t actually been used or were replaced by a similar module later in the development process, so these should be removed and uninstalled too.

There are also a number of Core modules we regularly uninstall such as Color, Comment, Dashboard, and Help as these Core modules are often unused on your average Drupal site. In our opinion Dashboard and Help simply add more links to the menu which unnecessarily confuse content editors.

3. Disable any theme specific development settings

This may be completely different for every theme but most themes have a number of development settings to help speed up development. which should be turned off when going live to remove any performance bottlenecks created by them.

This is also a good chance to disable (and remove) any themes which haven’t been used.

4. Disable error message display

Nice and simple; head to /admin/config/development/logging and set “Error messages to display” to “None”. This prevents any embarrassment and confusion created when your end users start seeing error messages on the page which to them will look like technical gibberish!

5. Configure performance settings

The site performance page - /admin/config/development/performance will allow you to configure a number of options to help optimise your Drupal site. This includes page caching and optimising CSS and JavaScript files.

See our series on High Performance in Drupal for some expert tips - High performance in Drupal Part 1: Give your site a boost and High performance in Drupal Part 2: Lightning fast code.

6. Check log messages and fix any apparent issues

Assuming you have the core database logging module (dblog) enabled you should have a list of log message which can be found at /admin/reports/dblog

Most messages will simply be notices which can be ignored,  though often there may be certain errors which saturate and fill up the log. Each log message requires a db write so a large list of regular messages can have a large impact on site performance. One example of this could be an undefined variable which doesn’t appear to cause any issues, but creates an error message to be logged on every page view.

It is good practice to regularly check the error log and periodically fix any recurring errors which are being reported.

7. Check 404 and 403 reports

Not only should these be checked prior to going live, but they should be periodically checked to ensure end users aren’t suffering from recurring 404 or 403 errors. Simply check both reports - /admin/reports/access-denied and /admin/reports/page-not-found - and look out for entries which have an unusually high count. Once you’ve found these question why they are a problem and get them fixed. If you have the URL Redirect module enabled there should be a simple link you can use labelled “Fix 404 pages with URL redirects”.

You may find some odd entries like “wp-login.php”, though these will just be from spam bots so they can be ignored.

Another little tip: Some of your links may not  appear in this report as they work, but are still problematic as they’re actually links to your development or test sites. Enable Pathologic as an input filter to help find and remove any of these.

8. Ensure custom 403 and 404 pages are in place

This is a nice little touch which doesn’t have to take any longer than 5 minutes. Simply create two basic pages; one for your 404 page and one for your 403 page, then set them as up under /admin/config/system/site-information.

The aim of these pages is to funnel lost visitors to other areas of your site to help them find what they were looking for. Some people choose to make these as simple as possible whilst others put a bit more “flare” into them. For some inspiration check out 33 brilliantly designed 404 error pages.

If your site uses the Search module you could also try utilising the Search 404 module - this handy little module performs a search on the keywords in the URL of the page which can't be found.

9. Enable and configure Google Analytics module

The first thing you want to do when you launch is check out your visitor stats; though the last thing you want to see is that none of this data exists because you forgot to setup Google Analytics properly!

Simply enable the Google Analytics module and add your GA Property ID under /admin/config/system/googleanalytics .

For best results we recommend overriding the GA ID on dev and test sites, that way your analytics results won't be skewed by internal traffic from your development sites.

10. Ensure all Web Services are setup correctly

Many web services such as Mollom or Typekit require a domain name specific API key to use. If you use any of these services on your website, you should ensure that you've registered your real domain name with the service and you've updated Drupal with your new API key.

11. Audit users accounts and ensure all admins use a secure password

It’s easy when first developing a site to use a simple login such as “admin” with the password “pass” so ensure all admin users have set a secure password if they haven’t already. We recommend using a tool like LastPass to generate and remember strong passwords.

Before you go live double check there aren’t any users with the admin role that you don’t want to have full access to the site. Ideally this should be a developer only role and your content editors should use another role with reduced permissions.

12. Ensure best practices are followed for SPAM prevention

The pro’s and con’s of different Spam modules and techniques is a story for another day, but there’s a few basic steps you can take:

  • If your site doesn’t use comments then disable the comments module. If it does, ensure permissions are correctly setup and that comments are only enabled on the content types they are required on.
  • Check the “Who can register accounts?” setting - /admin/config/people/accounts. If your only users are administrators simply change this to “Administrators only” to avoid an influx of spam user accounts.
  • Use Honeypot or Mollom to help reduce spam on contact and comment forms.
13. Configure basic SEO practices

This will be covered in a later blog post in further detail, but there’s a few tips you can use to ensure your site gets a head start here:

  • Redirect traffic from the non-www version of the domain to the www version (or vice versa) to avoid the site being indexed twice.
  • Check your haven’t left anything like “Disallow: /” in your robots.txt file which would prevent Google crawling your site correctly.
  • Lock your dev and test environments to ensure these aren’t accessible by visitors or crawled by Google.
  • Ensure you have added, enabled and configured the Global Redirect, URL Redirect and Pathauto modules.
14. Test email

Ahh, good old we-nearly-forgot-about-it email. You’d be surprised how many sites have issues sending email, especially when you have smaller self-hosted sites where there is no key reason to check this.

Fire off a forgotten password email when the site is ready on the liver server and ensure it reaches you OK without being sent to spam.

Personally we prefer using Mandrill on any of our sites which rely on email. Mandrill is a free tool which helps prevent email being marked as spam and provides details of all outgoing mails in a clean, easy to use interface.

Rick Donohoe

Drupal core announcements: Update: Drupal 8 beta 12 rescheduled for June 29; get ready for hook_update_N() in core

Planet Drupal - Thu, 2015/06/25 - 12:35am

We've rescheduled Drupal 8 beta 12 for June 29, 2015 to provide a little more leeway time for Drupal 8 core issues that require an update function. Starting June 29, any Drupal 8 core issue that includes a data model change must include an update function and update path test. See the previously announced core policy on requiring hook_update_N() for more information.

Identify your data model changes now!

If you have any core patches that are currently under development, please start identifying the data model changes in those patches now. Tag any issue that requires a data model change with D8 upgrade path and document the specific data model changes in the issue summary. Or, help triage major issues with specific attention to the data model changes.

It's actually also a good idea to start writing hook_update_N() implementations for your patches now! This will ensure in-progress issues can be committed as soon as possible following the next beta, and if your patch is ready before June 29, your update function will still help provide the corresponding update for the head2head project. Plus, if you uncover a critical limitation with Drupal 8 core's update functionality while working on your update function during the next week, the upcoming D8 Accelerate critical issues sprint will be an opportunity to get that critical issue fixed and unblock your patch.

Note for Drupal site owners and developers

Betas are good testing targets for developers and site builders who are comfortable reporting (and where possible, fixing) their own bugs. Betas are not supported releases of Drupal, and generally are not recommended for non-technical users, nor for production websites. The current beta release includes known critical bugs, including publicly disclosed security vulnerabilities. More information on beta releases.

The addition of update functions for Drupal 8.0.x issues should make it easier for developers to update their existing development sites between beta releases using update.php. However, these update functions may include bugs or even introduce data integrity issues, so developers should always back up the site and be prepared to rebuild it from scratch or manually update or migrate the data in case update.php fails to update it properly.


Tom Geller: Moving on from Drupal

Planet Drupal - Thu, 2015/06/25 - 12:12am

In the Esperanto language there was a great writer and activist known as "Kabe". After creating magnificent translations and reaching a position of authority, he suddenly left Esperanto life, never to participate again. So notorious was his disappearance, the language gained the verb "Kabei" -- to vanish suddenly from a position of great visibility.

I'd be flattering myself to compare my position in the Drupal world to Kabe's in Esperantio -- the Esperanto world. But my courses and other writings about Drupal made me fairly well-recognized in Drupal circles.

I've been absent from those circles for the last couple of years, and feel the need to give closure to -- and recognize -- those I got to know there.

I got started in Drupal because I wanted to build a dynamic website to promote a book I'd written. It was a period of great growth for Drupal, and accepted my proposal to create a seven-hour "Essentials" video course. (I think they agreed because their first CMS course -- on WordPress -- was selling pretty well.) That led to seven more, a book, a magazine column, various presentations, and a lot of corporate work.

Was I a "Drupalista"? That's tough to say. I've sincerely enjoyed working with it: Although I've come to recommend WordPress for inexperienced site builders with minimal needs, I'm still thrilled with how much I can accomplish with Drupal and a free afternoon. As I (like most people) have come to live more and more online, Drupal has given me more control over my environment. For example, I'm not afraid that I'll lose a major chunk of my history as LiveJournal slips down the tubes: Through Drupal I made a local copy, privately linking commenters to their real-wold contact information. Those tools, those gifts of the Drupal community, are still with me.

We grew apart. Drupal ceded the mom-and-pop market to other platforms, focusing instead on enterprise needs. That's a fine match... but it's not what interests me, personally. Coding -- a skill I don't have -- eclipsed site-building, evidenced by the increasing percentage of Planet Drupal posts on the subject. And Drupal 8's unexpectedly long development time caused a major writing project to stall after I'd put in a month of work.

But oh! What a fine relationship we've had. I'm scared to list the people who have made my time in "Drupalio" so much fun -- I'm sure I'd miss many. But I want to recognize everybody who helped me on; those involved with Drupal companies I've worked with (Commerce Guys, Mediacurrent, Acquia, Phase2 Technology, DrupalEasy, Tag1 Publishing, TopNotchThemes); those who corresponded privately about Drupal matters; and those who continue to make Drupal great. I'd be very happy to hear from you directly, and will continue to check in on (where I'm tgeller) from time to time.

I've gone back to general technology journalism and communications. Lately I've been quite happy working in video, and have started a U.S.-based agency, Tom Geller Productions. Making a monthly video for The Association for Computing Machinery has put me in touch with people doing fundamental research. I intend to do for that community what I've tried to do for the Drupal community: to make their work clear and accessible to those without specialist knowledge.

Esperantio and "Drupalio" are quite different. But they're similar in an important way -- one that's shared by any international community of people gathered for a righteous cause. After a time, the cause changes and falls away, leaving intact relationships that linger. As Wavy Gravy said, "It's all done with people." Although I might kabei, look forward to seeing you people, wherever we meet.

Blog category: Drupal Planet
Categories: Why PhantomJS When You Can Chrome

Planet Drupal - Wed, 2015/06/24 - 11:00pm

Following our unfortunate bug in Shoov which caused login to stop working, we decided to write a Behat test that will continuously check the live site and make sure login with GitHub is working properly.

Writing the Behat test was pretty easy, however it had a major problem - it didn't work.

@javascript Scenario: Login to shoov Given I am an anonymous user When I visit the homepage And I login with my GitHub account Then I should wait for the text "My Account" to "appear"

When Behat sees the @javascript tag in the begining of the scenario, it launches it (with the help of Mink extension) in PhantomJS, Firefox or Chrome.
PhantomJS is usually the easiest to configure and hook into the CI workflow later on.

But the test we wrote just failed on all versions of PhantomJS we tried. Which made us switch to Firefox instead. Travis CI is kind enough to have a headless Firefox installed in their machine which we could use. Unfortunately, Firefox didn't like our test either, but for another reason - it couldn't parse the xpath we use to find our text elements.

So after spending some time trying to figure out a workaround, I suddenly stared at the browser I was using to find the answer - Chrome!

Behat test running on headless Chrome, seen via VNC

Continue reading…


Forum One: Programmatically Restricting Access to Drupal Content

Planet Drupal - Wed, 2015/06/24 - 7:01pm

Have a requirement like “I want users to not be able to add, update, delete or view content if some condition is true?” If so, hook_node_access might be all you need. This hook simply allows you to alter access to a node. Now let’s learn how to use it.

How this hook works

Anytime a user accesses a node (to add, update, delete or view it) this hook is called and can be used to alter that access decision. It receives three parameters.

  • $node – Contains information about the node being accessed (or base information, if it is being created)
  • $op – What type of access it is (create, update, delete, view)
  • $account – Information about the user accessing the node

It expects a return value to alter the access, which is; NODE_ACCESS_DENY, NODE_ACCESS_IGNORE or NODE_ACCESS_ALLOW. Best practice is to not use allow and use either deny or ignore (ignore is the default, if no return is given). You get far less permissions headaches this way.

I use this module often for customized workflow requirements. The most recent use case was “I want to deny update access to all users who try to update a node based on a user select field on the node selecting them or not.”

This is all done with one simple hook in a custom module (see below).

NOTE: There are some instances this hook is not called/skipped. Refer to the hook’s link for those cases.

/** * Implements hook_node_access(). * * Enforces our access rules for custom workflow target content to force updates * only if the user is targeted in the user select field */ function mymodule_node_access($node, $op, $account) { // If a node is being updated if ($op == 'update') { // If the user select field exists on this node if (isset($node->field_my_user_select)) { // If the user select field is not empty if (!empty($node->field_my_user_select)) { // If the user id in the user select field does not match the current user if ($node->field_my_user_select[LANGUAGE_NONE][0]['target_id'] != $account->uid) { // The users are not the same. Deny access to update in this case return NODE_ACCESS_DENY; } } } } // Else ignore altering access return NODE_ACCESS_IGNORE; }

Palantir: Twin Cities or Bust!

Planet Drupal - Wed, 2015/06/24 - 4:29pm

We love Drupal Camps for a lot of reasons, and the popular Camp in the Twin Cities is no different. We get to learn about new projects, see old friends, and discover interesting ideas and solutions to challenges in Web development, design, and strategy. In addition, not only does our Senior Web Designer Carl Martens live in the Twin Cities area, we’ve worked with a number of clients there, including the University of Minnesota and PRI, among others.

This year, we have six Palantiri in attendance, presenting sessions on a number of important topics like Drupal 8, testing, technical debt, design systems, and much more. The Camp also gives us a unique opportunity to talk shop with past, current, and potential clients to learn about their projects and understand the challenges our expertise can help solve for them. Heading to the Camp? Please do let us know via our contact form.

We give an overview of our sessions for Twin Cities, and propose why each is important for your project or those working on it. We’ll update this post once the recordings are online.

Rendering HTML With Drupal: Past, Present, and Future

by Steve Persch
Friday, June 26, 10:30am

What is it about?
This presentation will review the mental models used in Drupal theming and propose a workable path forward. For years, Drupal core has encouraged a mindset of altering and overriding its internal data structures. Developers in the Drupal 6 era created a philosophy called “sustainable theming” that relied heavily on CSS to work best with Core’s tendencies. The rapid acceleration in the wider Front-End community in recent years has brought new underlying assumptions and new ways of thinking. Expectations for how to construct Drupal sites have changed. The future holds clear decoupling with Javascript MVC frameworks, Web Components and some traditional HTML frameworks that encapsulate Front-End pieces that can work with multiple data providers. Can you make Drupal’s components be those components? Bonus: the phrase "Headless Drupal" will come up at least a dozen times.

Why is it important for your project?
Knowing the history of a system helps round out your overall knowledge of that system. As such, you'll learn how Drupal's theming system has been shaped by expectations of different eras, and how CSS usage has evolved, ultimately learning how to spot patterns that move toward the future of front-end development. In addition, you’ll learn the importance of discussing with theming choices with team members, and ways to future-proof their code and workflow.

Drupal 8: The Crash Course

by Larry “Crell” Garfield
Friday, June 26, 10:30am

What is it about?
One of the most widely-used and mature Content Management Systems on the planet, Drupal runs more than one in fifty websites in the world. However, it has always been something of an odd duck, with an architecture and design very different than anything else in PHP. Enter Drupal 8: almost a complete rewrite under the hood, Drupal 8 is a modern, PHP 5.4-boasting, REST-capable, object-oriented powerhouse. Now leveraging 3rd party components from no less than 9 different projects, Drupal 8 aims to be the premiere Content Management Platform for PHP.

Why is it important for your project?
A bit of Drupal 8 preparedness never hurt anyone. This session will provide a walkthrough of Drupal's key systems and APIs, intended to give developers a taste of what building with Drupal 8 will be like, and should be able to recognize common patterns in Drupal 8 development, and identify the Drupal 8 equivalents of common tasks from Drupal 7 at the end of it.

Design Systems and Drupal

by Larry “Crell” Garfield and Carl Martens
Saturday, June 27, 10:30am

What is it about?
Modern Web design demands visual systems that ensure content is delivered to our myriad devices, from smartphones to tablets to desktop displays and beyond, in usable ways. It requires thinking in terms of content that gets presented, often in a variety of different ways, rather than simply presentation. In this session, Larry and Carl will provide practical examples for how modern, modular design systems and practices can map directly to Drupal’s Views module, view modes, image styles, panels and other common site building tools.

Why is it important for your project?
You'll walk away with information that will help you leverage Drupal’s strengths through leading edge Web design, to both see and understand the basic concepts of design-system thinking, content strategy, and Drupal as a unified worldview that results in better, faster, and more consistent sites.

Technical Debt Insights from the Lorax

by Andrea Soper and Joe Purcell
Saturday, June 27, 1:00pm

What is it about?
Technical debt is a common analogy to describe the cost of code mess and poor architecture. However, how far can the monetary analogy go? In this session we will look at insights from the Lorax and “environmental debt”. Specifically, Andrea and Joe will build an argument for why the monetary comparison communicates the wrong idea about how technical debt is measured and how it impacts business. They will also include measures and practices to mitigate such technical debt.

Why is it important for your project?
If you deal with the challenge of communicating the business cost of technical debt, want a clearer understanding of what technical debt is and how to measure it, or want advice on how to mitigate against technical debt, this session will help. The goal is cleaner, more sustainable code and architecture for you, your team, your project, and the future.

On PhpSpec and Not the Drupal Way

by Michelle Krejci
Saturday, June 27, 2:15pm

What is it about?
This session gives you an introduction to the distinctions between unit, integration, and system testing, an introduction to behavior driven development (BDD), and, of course, using PhpSpec (a BDD tool) to isolate and spec out functionality in your Drupal codebase. PhpSpec is a toolset for building out testable pieces of functionality strictly designed to meet —and only meet—the project requirements that you have made explicit. Identify your inputs, test your expected outputs. That's it. The bigger question is: how do we as developers mature our skills and deliver testable, functional code while we continue to work on Drupal 7?

Why is it important for your project?
Proper testing breeds successful projects, plain and simple. You'll walk away with not only an understanding of the cost/benefit tradeoff of unit testing vs. system testing, you'll also learn the importance of building out custom functionality in Drupal using PhpSpec. The ultimate goal is helping you write better code and modernize your developer skills. Project Managers are welcome, too!

Heading to Twin Cities? Let us know in the comments, @ reply us on Twitter, or get in touch via email.

Categories: Test the staging version of on Drupal 7 NOW!

Planet Drupal - Wed, 2015/06/24 - 4:13pm

What, still runs on Drupal 6? Yeah. It is absolutely time to update to Drupal 7 so we can keep improving the site on an up to date platform, so we need your help to try the new staging version out. Sebastien Corbin and Gábor Hojtsy with the invaluable help of the Drupal Association prepared the staging site and hope it is near ready for the upcoming live update. But we need more testers to ensure it actually is. Here is how the test works:

  1. See all instructions for testing at, including how to report issues
  2. Everybody with existing accounts or new staging registrations is welcome (note that the site is not rebuilt, so if you don't already have a account, you need to create one on staging)
  3. This public testing runs until the 8th of July (for 2 weeks)

If you test now, we can fix issues ahead of the launch, so you would not need to complain after the update. Any questions? Post on the issue at

read more


Realityloop: Giving back to the community: Community Tools

Planet Drupal - Wed, 2015/06/24 - 11:37am
24 Jun Brian Gilbert

At DrupalCon Sydney where I was the Community track chair, for the first time at a DrupalCon both Stuart and I had offered to help as mentors at the post conference sprint. We felt in a relatively good position to do this as we’ve been running a mentoring event locally in Melbourne nearly every month since some time in 2010, which is another story in itself.

This naturally led on to us being mentors at DrupalCon Portland. During the mentor BOF’s while mostly listening, I was already thinking how can I make things better and the thing that stuck out to me were the common issues that often came up while getting a first time sprinters set up with a local development stack:

  • Bandwidth usage
  • Different stacks (MAMP, WAMP, XAMPP, etc)
  • Mentors having to support a stack they’re not familiar with
  • Time of setup (some users would take nearly an hour to setup)

Around the same time Stuart and I had been playing around with BitTorrent Sync (BTSync), which at that time was pretty new, but in my mind a promising potential solution to the bandwidth component of the problem.

I also thought that Acquia Dev Desktop (ADD) may be a better option for setting up a local stack than using any of the other *AMP stacks listed above. While also simplifying the support task for mentors that are essentially volunteering their time.

Eventually I started to talk to some of the more seasoned mentors about my ideas and there was some interest in my thoughts on BTSync, but a lot of kickback on using ADD due to previous sprints where various people had been burned trying to use ADD with Drupal 8 in the past.

As luck would have it one of the mentors that worked at Acquia, scor AKA Stéphane Corlosquet, was at these BOF’s also and we exchanged details. See the relevant issue at:

Attending what is now known as the First Time Sprinters workshop in Portland I was surprised when it was suggested that attendees all go and download MAMP/WAMP/XAMPP “now”.. It was no wonder the wifi had a history of dying during sprints, and it didn’t disappoint this time going down at exactly this point during the Portland sprints.

Needless to say this was enough motivation for me to implement and prove my thoughts, so I started building what eventually became the Community Tools Installation process.

What were the constraints?

There wasn’t that many, but these were the key things:

  • Installation is fast
  • Lean on the network
  • Doesn't break anything existing on a users machine.

It seems common for people to think that we are putting this forward as the ideal development stack, this is not at all the case, it is simply designed to be the fastest way to get someone up and running with a capable stack.

By using BTSync the majority of the network traffic for the tools is served from within the sprint room itself from the laptops of mentors that have pre-synced it.

BTSync has two levels of access to a shared folder, one that is read/write (only known to me) and one that is read only which is given to everyone else. This means we don’t run the risk of spreading malware that could arise through the use of USB keys shared with approximately 200 people.

BTSync also allows for last minute changes to be made that will sync out to all users, meaning we can respond to issues that arise quickly and not have to re-image a bunch of USB keys just before the workshop.

In the beginning there was a lot of pressure to include MAMP and other tools in the package, but I was eventually able to work with Acquia via scor to improve the ADD2 Beta such that it was the clear winner for this specific use case. Related issue:

ADD2 installs it’s webserver and database using ports for these services that are to my knowledge unique, meaning that it will not conflict with any existing web stack a user has set up.

ADD2’s supplied configurations (PHP/MySQL) also work out of the box with Drupal 8, something that often needed changing with other stacks.

Why this collection of tools?

The components were primarily chosen based on relevance to the typical activities performed by a first time sprinter during the sprint day, these are:

  • Use IRC (Limechat / Hexchat)
  • Edit code (SublimeText)
  • Use Git to apply and create patches (Git)
  • Run Drupal 8 (Acquia Dev Desktop 2)
  • Install Drupal 8 (Drupal Core — dev branch)

Initially the tools came with a PDF that walked you through each of the installation steps, pretty quickly I saw that people weren't reading this and making mistakes in the installation, so fairly promptly I started scripting as much of the installation as possible to reduce the chance of user error and also reduced the installation time. Related issue:

The OSX scripting was easy but It was fun having to learn how to code a .BAT file after not having used windows for several years.

At this stage the only manual step of the installation apart from selecting which parts you want to install is adding the site in ADD which has substantially reduced the size of the PDF that nobody reads ;)

The script prompts to see if you want to install an IRC client and a code editor, it then checks if you have git installed or not and prompts to install and configure git to d.o standards.

To save bandwidth Drupal 8 core is included in the tools package that is synced, extracted during the installation and then a git pull is executed to only grab recent changes saving again on bandwidth.

At this stage I’m very confident this is as lean as it can get without creating a customised install package specific to each operating system.

How has it performed?

After testing it at local events the concept was proven, the first real test at scale at DrupalCon Austin, about 50 people out of 200 had issues with it syncing but I considered it a success.. and the network stayed up!

We used it again in DrupalCon Amsterdam where I don’t think we had as many issues with people getting it synced but did still have to use USB drives for some people.

And I used it at DrupalSouth Melbourne earlier this year where it synced perhaps the fastest ever and we didn't have to use any USB thumb drives.

What could be improved?

It’s fairly clear that there are some limitations built into BTSync, and that the venue network setup can sometimes cause issues. I am constantly on the lookout for a better transport method (ideally looking for something open source instead of BTSync or for the Sync team to provide a free pro account so that we can share these secrets with unlimited users)

I think having a web server at the venue that could serve the tools would provide the most added benefit to the existing setup, while removing the weakest remaining link (BTSync) and also opening up the possibility of using tools that are larger in file size.

Linux doesn’t have ADD so the current experience is quite different for Linux users, and in my not consistent enough. To some degree we expect these users to already know how to set up a stack which isn’t the best assumption to make.


Tools download file sizes:

  • Linux         510MB
  • OS X         247.5MB
  • Windows  290.3MB

External Bandwidth usage during installation:

On OSX Git is installed via download of the command line tools.. ~120MB
For OSX and the rest the only the Git pull to update core ~20MB or less

Installation time:

  • Linux          ~5 minutes
  • OS X           ~4 to 7 minutes depending on if you already had git installed or not
  • Windows     ~5 minutes
Where to from here?

There are several community members that are pushing for vagrant to be for the stack part of this toolset, I think that it will go a long way to resolving the inconsistencies that we currently see with Linux setups, talking about it in the office we all think it needs a pretty control panel to make it easier for as wide a group of end users as possible. But there are some considerations that still need to be factored in. Related issues: and

This is a recount of events spanning several years, I've done my best to be as accurate as possible please forgive me if there may be some small factual errors in my recounting of things.

drupal planetdrupal 8

Blair Wadman: 19 simple methods to improve the page speed performance of a Drupal site

Planet Drupal - Wed, 2015/06/24 - 11:29am

Site speed is one of the most critical factors when running a site. If a site takes too long to load, visitors will hit the back button and go elsewhere. Google is well aware of this, so slower sites will not rank as well as fast sites (all other things being equal).

Drupal performance optimisation can be a complicated specialisation in its own right. Consultants and Drupal agencies can spend days or even weeks investigating performance issues and fixing them. But there are many quick fixes and simple methods that you can implement right away. You don’t have to implement absolutely everything on this list - you can implement some and monitor the difference it makes to the site speed....


Modules Unraveled: 140 Using the Math Field Module to Compute Values Without the PHP Filter with Caleb Thorne - Modules Unraveled Podcast

Planet Drupal - Wed, 2015/06/24 - 7:00am
Published: Wed, 06/24/15Download this episodeMath Field Module
  • What does the Math Field module do?
  • Why did you develop it? What hole does it fill?
  • You mentioned EntityForm...
  • How does it compare to the Computed Field and other modules?
  • What are the limitations? When wouldn’t you use it?
  • You mentioned before we started recording that you actually rewrote the entire module to use core’s AJAX framework instead of custom jQuery. Why was that? and how did it go?
Use Cases
  • What types of sites do you see this being of most use?
  • I might be using this on an upcoming project
  • What are your plans for D8?
  • What other general features are planned? I saw the note on the project page about issues with multiple parameters and multivalue fields.
Questions from Twitter
  • Rick Nashleanas
    Any performance implications using the Math Field module? (Yea, I know, this is a plant!)
  • David Csonka
    Is there a practical limit to how many Math Field fields you can have calculating in a piece of content? Performance?
  • Rick Nashleanas
    What's the most complicated implementation you've done with the Math Field module?
Episode Links: Caleb on drupal.orgCaleb on TwitterMath Field ModuleBlog Post about Math FieldTags: planet-drupal