Nov 05 2015
Nov 05

With the official release of Drupal 8.0.0 on the horizon, "real world" Drupal 8 stories are becoming more valuable.

Now that the train is actually approaching the station, we all want to know what it will be like to get on. 

Mediacurrent, a leading Drupal design firm, got their Drupal 8 ticket punched early. They partnered with Acquia to launch a Drupal 8 site for Manhattan Associates, a supply chain management software provider, back in August, 2015, when Drupal 8 was in beta. The site has been on the Drupal 8 frontier ever since. 

So what has the experience been like? 

A "real world Drupal 8" series from Mediacurrent and Acquia has been telling some backstories. 

Part one of our blog series centered on Manhattan Associates’s experience as an early D8 adopter. We showed Drupal 8’s mobile-first approach, improved theming, and Twig template system in action. In part two, we saw how Manhattan leveraged Drupal 8’s improved configuration management, new Web services API, and easy internationalization to achieve their business goals.

In the third and final post in our series, James Rutherford of Mediacurrent recaps some of the hurdles they faced during this project and their takeaways.  

Among the high points: 

LESSON #1: CONTRIBUTED MODULES WERE NOT AS FAR ALONG AS EXPECTED.

Although Drupal 8’s core met 95% of Manhattan Associate’s requirements, some additional modules were necessary to complete the project. Mediacurrent found that in the pre-release stage, some Drupal 8 contributed modules were simply not as far along the project required.

One of the ways they dealt with this challenge was to anticipate that there would be trouble along the way. Mediacurrent targeted a conservative number of contributed modules (ten) that they wanted to use. They estimated and planned for development strength in the schedule to accommodate for major issues with those modules, and were able to develop around them. 

Bottom line: It is imperative for those who are evaluating Drupal 8 to gain a concrete understanding of what your business requirements are and how much of that is covered by Drupal 8 core.

LESSON #2: BE FLEXIBLE IN YOUR ARCHITECTURAL DESIGN AND BUILD PROCESS

This project has been successful because Manhattan was willing to be flexible in their architectural design and in Mediacurrent’s build processes. The requirements stayed very business-oriented and they tried to stay out of too much technical detail. In areas where there were technical details, they gave themselves room to adapt.

Bottom line: Flexibility is what allowed us to launch an amazing platform for Manhattan that delivers on all the power and promise of Drupal 8. We were able to avoid budget issues and time by being flexible and having great communication between both teams.

LESSON #3: GOOD PLANNING AND RISK MANAGEMENT ARE ESSENTIAL

Mediacurrent and Acquia took a good, hard look at Drupal 8, understanding the competitive advantages of using Drupal 8 and the potential pain points of being an early adopter.

We were able to illustrate these pain points in a way that Manhattan could understand -- and could plan and budget for. Most importantly, we were able to successfully mitigate these pain points during the launch.

Mediacurrent and Acquia did an exhaustive analysis of current Drupal 8 core issues and the timeline for completion on these issues. We repeated the process for the targeted contrib functionality. This allowed us to estimate the correct budget and timeline with lower risk, and helped the Manhattan Leadership to have the information they needed to make the correct decision.

Bottom line: The ability to launch this site on time and on budget came from a smart, up front investment of planning and risk management between Mediacurrent, Acquia, and Manhattan.

There's much more in James's post on the Mediacurrent blog, Leading the Way on Drupal 8: Lessons Learned from Manhattan Associates D8 Redesign.

Definitely worth checking out. 

Nov 04 2015
Nov 04

One of the most difficult parts of executing a successful round of usability testing can be recruiting participants. You may need to show your designs to people who fit a certain professional persona, or hear feedback from people with a particular technical skill set. Once you’re in touch with testers who fit the bill, you’ll have to navigate their busy schedules, and disparate locations, to organize their test sessions.

But consider this: There are dedicated conferences for almost every profession, technology, and interest under the sun. Attendees are gathered in a single place for a set time to devote their attention to whatever domain it is they all have in common. If that domain is relevant to what you’re building, it’s a user researcher’s paradise. You’re surrounded by your users, and potential users, at a moment when they’re focused on the very context you all have in common.

Acquia builds tools for Drupal developers, who throw some of the most dynamic and exciting open source tech events around. The Drupal community’s flagship conferences, DrupalCons, happen multiple times a year around the world.

I was lucky enough to attend DrupalCons in Los Angeles and Barcelona this year to run usability tests on a product redesign Acquia’s UX team is working on.

Having run the "Conference Usability Testing Gauntlet" twice now, I’ve come away with plenty of process knowledge, which I’ve collected here.

I hope these tips will help you make the most of a conference setting, resulting in ample, helpful, feedback from your target users.

Usability Test Basics

My basic kit consists of two laptops. Yep. That’s it. You can even get away with one if you’re just going to give it to your tester and observe over her shoulder. But two is nice if you want to use screen-sharing to give your tester some space and still get an up-close and personal view of her screen interactions.

a UX testing setup
My UX testing set up, on site at a DrupalCon.

At Acquia, we’ve also tested mobile prototypes at DrupalCons. We used an iPod Touch to mimic the screen size and OS of an iPhone. I used an extra-long USB cable to tether the iPod to my laptop, so users could hold the test “phone” closer, and I could still observe their interactions on my screen.

Take the time to think about the best setup for your test, but here’s what’s worked well for me:

  • A moderator laptop: Alongside the screen share window, where I can observe my tester’s interactions, I run Google Docs for note-taking. I start with a master test plan document, and make a copy for every test session I moderate, which helps keep my notes in line with the test tasks for each session.
  • A test laptop: I keep files, folders and other apps to a minimum to avoid distraction. I also put a shortcut to the prototype file right on the desktop, or bookmark a Web-based UI in the browser I’ll be testing in, so I’m not fumbling to reopen the prototype at the start of a test.

Two tips:

  1. Remember to turn off any apps that run in the background but might send distracting notifications during a test.
  2. Kill background apps that might drain your battery. Power is a premium at most conference centers, so you’ll want all the juice in your laptops to be dedicated to your testing.

And two suggestions for additional gear:

  1. Laptop leash or lock: If you have a place where it’s safe to lock up your test laptop (at DrupalCon, I locked mine at the Acquia booth a few times while I walked the floor recruiting) this is handy.
  2. Backpack: The most comfortable way to carry a usability test lab around with you for a few days.

Sign-ups, Sign-ups, Sign-ups

If you want to maximize the number of users you hear from, a recruitment plan will save you from wandering the exhibit hall floor trying to approach busy folks (this works too, of course!)

Find allies! If you have other colleagues attending the conference, tell them about your testing activities so they can connect you with people they meet.

In addition to your own business cards, small hand-outs outlining the usability test goals and process are nice to give out to potential testers.

Pro Tip: Create a virtual signup sheet. I use YouCanBook.Me, a great service that allows people to see your available times and snag an appointment. It has all kinds of handy built-ins for handling time zones, sharing the calendar, and letting you easily communicate with folks who register for a test. I printed my custom YouCanBook.me URL on the back of my business cards, so I can hand one over any time I met an interested potential tester. That way they can visit it at their leisure and find a time during the conference that works best for them.

Stationary versus Mobile Set Up

Let’s compare the value of setting up shop in one place versus wandering around and testing where your testers are.

Stationary: You can optimize your space. Find somewhere close to the main events but quiet enough so that you can have a conversation with your tester. Find a bench, table or other spot where you can easily maneuver to see what your user is doing. If you can score a power outlet, even better. Drawback: If you’re parked in one place, you’ll need to get your users to come to you / know where you are. Prepare for that.

Mobile: You can optimize your time. If you’re carrying your usability lab with you, you can recruit testers on the exhibit hall floor and test with them right there when you find someone with free time. Being visible like this can even help you get more folks aware of what you’re doing, and get them interested in testing. Drawbacks: It can be a little uncomfortable, and you might have a hard time finding a place to sit. Scope out areas ahead of time, like extra seating at the edge of the venue, or a quiet lobby area you can pop into. Keep audio quality in mind if you’re recording; it can be tough to record in a noisy conference hall.

Screen Sharing & Recording

I’ve used two main tools to record usability test sessions: WebEx and Camtasia.

Webex gives you browser-based screen sharing and screen recording. This is great, no arching your neck to peer over your tester’s shoulder. However, it’s Wi-Fi dependent. If you’re using a conference Wi-Fi signal, which may be taxed by hundreds of other attendees, this might not be the best option.

Camtasia provides a screen and audio record that’s local to your tester’s laptop. Hit “record” before they start testing, and you’re good to go.

If you’re using a browser-based screen recorder, don’t forget: your recordings are saved to the service and not your computer! Download those files if you want to watch ‘em on the plane home without Wi-Fi.

Respect the Event & the Community

I’ve saved this for last, but it should come first in your considerations of usability testing at a conference or any setting. Make sure you’re mindful of the fact that the conference itself comes first.

DrupalCon is an epic event meant to support Drupal users in learning, sharing, teaching, and coding Drupal -- all together in a shared space. As a UX researcher, I’m thrilled to talk to these folks, but I want to balance that with respecting their time and their work during the week. The same goes for the organizers of the event where you’re testing: they’re doing the work that brought you all together in the first place, so be sure that your testing activities aren’t a disruption.

Check in with conference organizers or volunteers before and during the event to make sure you’re good to go with your test plan. During the event, chat with volunteers working the floor. Ask where it’s okay to hang out if you want to chat with testers or potential testers, and make sure your setup isn’t in the way. And hey, don’t forget to give back: if you’re using a certain space, offer to help volunteers if they’re setting it up at the beginning of the day, or cleaning it up at the end. It’s just more fun that way.

Acquia’s UX Team ran full rounds of usability testing at DrupalCon North America and DrupalCon Europe this year. The focused feedback on our designs from so many Drupal developers let us iterate and improve in line with what our core users want. To UXers out there, I hope these little details will make your next big-event usability test session a success.

And to DrupalCon: thanks to all of the attendees who volunteered as testers.

See you next year!

Oct 29 2015
Oct 29

The landscape of Drupal theme development has drastically changed in recent years. Cutting-edge front-end development tools are now considered standard within Drupal enterprise builds.

Developers now can leverage engineering recipes into rapid development with powerful front-end automation tools like Gulp and Sass. But with these tools comes the responsibility to address performance and extensible methods within large teams. So a consistent and scalable method of development is needed. By following the techniques recommended in this blog, you will see an increase in theming velocity throughout the lifecycle of your project.

What is Component-driven Theme Development in Drupal?

When you step back and look holistically at your Drupal homepage, you'll see that it is essentially nothing more than a collection of several modular pieces. So the primary focus of this method in Sass – which is an extension of CSS that adds power and elegance to the basic language – revolves around developing your site as these modular pieces.

The construction of the varied isolated pieces are intended to exist as stand-alone components, but they are also designed to be combined and extended upon. This means steering away from the tendency to couple your styles to Drupal-rendered HTML markup. If you follow this same train of thought, this means that these elements should be coded in a manner so they maintain their stylistic integrity regardless of location on the page. Teams following this pattern are accelerating their development efforts by treating theming tasks as building blocks to be extended upon.

What Are the Benefits of Using Components in Drupal?

One of the primary driving factors behind component-driven development is the DRY (Don’t Repeat Yourself) principle. Reducing the compiled CSS will result in improved performance and less code to maintain. Your theme will also become more predictable by removing layout code that's specific to containers. Following the component methodology builds consistency by moving common styles to base HTML elements so they can be reused throughout components. This leads to a more consistent rate of development with each sprint life cycle since momentum will be accruing as your component count increases.

Why Are These Methods Now More Important Than Ever?

To appreciate the timing of this workflow consider these concepts in a linear timeline:

  • Progression of Drupal’s Theming Layer: CMS has drastically improved to offer developers substantial flexibility in rendering structural markup, classes, and IDs. Alongside these features is a wide range of preprocessing options to adjust granular components according to contextual scenarios. It is now easier than ever to proactively assign classes while dynamically adjusting context to match a component pattern by dictating structural rules.
  • Evolution of Front-end Development: The accelerated evolution of front-end development has yielded tools that previously didn’t exist. In addition to CSS compilation with Sass, common tasks or testing can now be automated with tools like Gulp or Grunt. These tools and languages are instrumental in rapid development, but can also adversely result in things like bloated CSS or overly-specific selectors.

In the following example, something as simple as nesting the second class “views-row” results in twice as much rendered CSS:

.block-custom, .views-row { 
width: 98.5%;
display: block;
border-radius: 5px;
span {
font-weight: bold;
font-weight: 500;
}
}

While we have extensive power with available front-end tools, it’s important to remember that our front-end methods still need to catch up with our front-end tools. Using advanced nested selectors in Sass is great, but the flip side may result in not allowing your code to be extensible or even easily maintainable.

Methods of Implementing Component-driven Engineering

A basis for thinking through scenarios with Drupal components requires a proactive approach to Drupal markup and its classes when writing Sass. This means dictating to both the classes and markup, not just reacting to it. So let’s extend this thinking a bit further by considering two opposing methods: reacting to classes versus defining classes.

If we look at this example of reacting to classes, you will see why this methods quickly fails. By essentially chasing down the markup, you're creating coupled code that is both un-extendable and counterintuitive.

aside form.login-form input.edit-name, 
div.view-views-articles.view-display-id-block .views-row,
div.panel-example-pane > .inside-content h2,
div.view-taxonomy-term .header .icon {
color: $greenish;
}

By proactively defining classes with a combination of preprocessing and Sass, you will establish a repeatable baseline to extend upon. This same technique can just as easily be applied with things like view modes, custom theme functions and other Drupal standards.

// hook_form_alter 
function MODULENAME_form_alter(&$form, &$form_state, $form_id) {
if($form_id == 'user_login') {
$form['name']['#attributes']['class'][] = 'green';
}
}
// theme_preprocess_views_view_unformatted
function THEMENAME_preprocess_views_view_unformatted(&$vars) {
$rows = $vars['rows'];
if ($vars['view']->name == 'articles') {
foreach ($rows as $id => $row) {
$vars['classes'][$id][] = 'green';
$vars['classes_array'][$id] = implode(' ', $vars['classes'][$id]);
};
}
}
// sass file
.green { color: $greenish; }

Architecting Your Sass as Object Oriented CSS

Nicole Sullivan introduced the guiding principles of Object-Oriented CSS (OOCSS) in 2008. The OOCSS methodology was introduced before Sass had even hit its full stride, so with all the modern-day tools it is even more relevant. Since its introduction, it has stood out as one of the most solid modular systems for building enterprise-grade sites.

The value of OOCSS can be nicely summed up by Sullivan herself: “The purpose of OOCSS is to encourage code reuse and, ultimately, faster and more efficient stylesheets that are easier to add to and maintain.”
The two primary principles of OOCSS are:

  • Separate Structure & Skin
  • Separate Container & Content

In this example, you would separate this code out into two different blocks. The first three lines would go in a class designated for structure, and the last three lines would be moved to a class for skin.

// Separate Structure & Skin
.sideblock {
padding: 10px;
min-height: 300px;
width: 100%;
border: solid 1px gold;
box-shadow: rgba(0, 0, 0, .5) 2px 2px 5px;
background: linear-gradient(#ccc, blue);
}

In the following code, the requirement is that a h2 needs to reside within the footer and not offering flexibility. A better way would be to use a .header-tag class that could live on any type of element regardless of DOM structure.

// Separate Container & Content
footer h2 {
font-family: Helvetica, sans-serif;
font-size: .8em;
color: purple;
text-shadow: rgba(0, 0, 0, .3) 3px 3px 6px;
line-height: 1;
}

Progressive Enhancement Using Re-Usable Patterns in OOCSS

When scoping out the theming of a large Drupal project, step back and look at the sequential steps of development. Whether you're dealing with individual components or entire pages, you can still break out things in re-usable patterns. The intent then is to build a collection on individual pieces to be combined as needed. This means scaling down your Sass into smaller segments to be used in multiple scenarios based on the purpose of the @extend or @include.

<div class="block-basic tree-background golden-block">
<div class="headliner">Welcome Folks</div>
<div class="body text-white">Muffin ice cream sweet macaroon jelly-o bear claw donut bonbon. Dessert caramels cupcake pie oat cake. Jelly-o cupcake caramels.
</div>
</div>

.text-white {
text-shadow: 0 0px 5px black;
color: $whiteish;
}

.tree-background {
@extend %tree-image-full;
}

.golden-block {
border: 2px solid gold;
}

Component-based Drupal takes a theoretical and practical look at advanced Drupal engineering techniques to speed up development time for enterprise projects. Hopefully these recommended steps will increase velocity and cut development time after each sprint life cycle.

Oct 29 2015
Oct 29

You've undoubtedly heard about some of the major new features in Drupal 8.

You've heard that Views is in core, that there is a new WYSIWYG editor, and that the codebase has been redesigned with Symfony.

At OSTraining we've written posts about many of these headline features, including one we posted here at Acquia called, 10 New Features in Drupal 8 Core.

Well, Drupal 8 has much more to offer. I'm going to show you three really useful new features in Drupal 8 that most people aren't talking about.

At first, you'll notice that the Drupal 8 Admin menu looks very similar to Drupal 7.

However, the Admin menu is much more flexible in Drupal 8. For example, there's an arrow in the top-right corner. Click this arrow and watch how the menu changes.

If you click the arrow above, the menu moves to the left. This is the same view that's enabled Drupal 8's Admin to be used on mobile phones.

Also in the top-right corner is an "Edit" link. Click this link and the whole screen will become editable.

After clicking the "Edit" link in the menu, you'll see small pencil icons next to all the page elements.

You'll be able to edit any element on the page, directly from the front of the site.

Comments were a fairly basic feature in Drupal 7.

No longer. In Drupal 8, comments have their own area. You can see a list of all "Published comments" and another list of all "Unapproved comments." You can perform bulk actions on the comments from here.

You can also create different types of comments in Drupal 8. For example, you can have one type of comments on public-facing blog posts and another type of comments for private feedback from admins.

When you add new comment types, you'll see that comments can now be applied to much more than just content. You can add comments to blocks, contact messages, content, taxonomy terms, users -- even to comments!

Each comment can have it's own set of fields.

In Drupal 7, if you wanted to create forms, you had to use a module such as Webform or Entityform. Now in Drupal 8, forms are in core.

By default, Drupal 8 provides two contact forms: "Personal contact form" and "Website feedback."

"Personal contact form" is the form that's added to each user's profile. "Website feedback" is a generic website contact form.

Drupal 8 forms can have normal fields, but they also have custom elements: such as "Sender email,""Recipient username," and "Send copy to sender." The one feature missing is the ability to store entries that are sent, but I suspect a module will soon be created to meet that need.

Oct 27 2015
Oct 27

Planning a website for a conference about information architecture is never easy. With every content and structural decision you make, you feel the core audience silently judging you. The team that built the 2015 IA Summit conference site knew that it would take a flexible architecture, and a fast and reliable platform, to meet audience expectations. That’s why we turned to Acquia and Drupal 8.

Built to last

Many conference websites are designed and built for a single event, then tossed away and built again the following year. This can be hugely wasteful, something a volunteer-run event like the IA Summit can ill afford. After 16 successful years, it’s clear the event is here to stay. So we wanted more than just a presence for 2015, we needed a platform that could support multiple events for years to come.

This takes some serious planning and foresight, including an understanding of the people involved, their roles and contributions, and how these might change over time. This year’s workshop assistant might be next year’s speaker, and one day may give a keynote address. A presentation given in 2015 may have thematic connections to one given in a past, or future, event.

Model views

Thanks to Drupal’s nodal structure, we were able to model the concepts of people, their roles, and the types of sessions given in an annual event. We wanted each person’s profile page to tell you about their involvement in every IA Summit event. If someone has spoken at one or more events, we wanted links to every session she's presented. Drupal’s flexible views are perfect for expressing these connections dynamically.

These views also power smart index pages, such as automatic curation of the popular sea-of-faces headshot matrix so common to conference websites. By building this page as a view, it updates automatically whenever a person is assigned as a “speaker” for a specific event. Handy when speakers drop out, or decide they’d prefer a more flattering photograph. Thanks to Drupal’s node and view structure, making such changes is a breeze - even from a smartphone.

What You See is What You Want

WYSIWYG editors are usually loathed by designers for allowing authors to unwittingly create terrible markup when pasting in formatted content. Drupal’s CKEditor produces (mostly) acceptable markup with no additional development. Editors were able to work on content in parallel to development work. Right up to showtime we made tiny tweaks to session details, and were grateful for D8’s new quick edit tools.

A Drupal 8 WYSIWYG editor in action

But really, that richly-linked web of nodes needs structured content. To be able to define fields for People (first name, last name, Twitter handle, email address etc.), Sessions (title, description, type, date, location, takeaways), and even the event Sponsors (along with the sessions they’ve sponsored this year, and elsewhere) is a dream for information architects. Here too, Drupal 8’s core admin functionalities got us up and running quickly, prototyping how we wanted this content to take shape.

An edit form for a session, showing many of the fields for structured data

Modeling content relationships at data-level gives us flexibility in interface design. We certainly needed a site that worked across desktop and mobile, and with a little experimentation were able to get a responsive theme to perform across platforms. (A word of warning: Twig, Drupal 8’s theming engine, is so different from previous versions that even experienced themers may find themselves lost. Getting comfortable with the new system should be factored into any project.)

We were dedicated to ensuring content was accessible, with sensible tab-ordering and Accessible Rich Internet Applications (ARIA) markers. Accessibility support comes as standard in Drupal 8, so once we marked up theme templates appropriately, we were confident that the rendered pages would remain accessible.

Keeping up pace

The conference lifecycle moves fast. From initial announcement, to the call for papers, to the publishing of the program, to the days of the event itself, the Web platform has to adapt to meet evolving needs and increasing demand.

We were grateful for Acquia’s solid hosting and development environment. We maintained staging and production environments, so that our volunteer teams were able to develop and QA each phase of the site prior to launch. Oh, and we had several compliments about how fast the site was compared to previous years.

We’ve only just begun

The strategy for the IA Summit’s Web presence was ambitious. In 2015 we started a structure that will adapt and grow with us. But there’s so much more to do, from integrating slide presentations and podcasts, to publishing machine-readable data for better SEO and public remixing.

Our intention is to build a rich repository of knowledge and to deliver on the IA Summit’s core purpose: to become the home of information architecture. In 2015 we met our goal: to provide a robust and flexible platform and structure, saving our volunteer successors time, energy, and hassle.

With the help of Drupal 8 and Acquia we’re making the IA Summit, and its digital presence, a future-friendly phenomenon.

Oct 23 2015
Oct 23

When managing a whole government platform, as we do in Australia with govCMS, there need to be layers of testing, staging, and assurance before you push code to production.

Automated testing allows us to delegate repeatable and menial tasks to a robot in a scripted fashion. These tests deliver a way of detecting basic syntax errors, breakages of coding standards, build failures, and regressions with a high degree of surety. We can also be assured that functionality persists through new builds, security requirements are met, and that upgrade paths work as expected.

This has the benefit of allowing developer time to be focussed on delivering new high quality features. It also ensures that the QA process is consistent across all proposed changes to the platform.

govCMS ships with a comprehensive and extensible automated testing suite to protect the platform against bugs and regressions. It also offers a managed procedure for running smoke tests over all sites prior to the production push. It’s worth noting however, that not everything is covered by platform tests and a continuous improvement approach is taken to improve coverage.

As the codebase itself is publicly available, we can observe both the automated tests and the results of them in the continuous integration (CI) system, Travis CI.

With every requested change to the govCMS codebase, created via a pull request, a significant number of tests are run. The aim is to protect both the platform and all sites on it against bugs, coding errors, and regressions in functionality. Once all tests have passed, code is deployed and everyone on the platform benefits from the new features and functionality.

As soon as a change is suggested, test runs are spawned for both PHP 5.5 and 5.6. As long as each of these completes without triggering an error, the pull request is considered successful and the govCMS maintainers are notified to provide a manual review.

What we’re using

In keeping with the open source ethos that drives both Drupal and govCMS, we’re using a suite of community contributed tools to build and test.

Amongst other things, the toolkit consists of:

The composer.json file acts as instructions for Composer to download all dependencies used by govCMS. Once these packages have been pulled down, Phing uses build.xml to download Drupal, install all modules using Drush, and run tests.

Functional testing against the govCMS platform uses Behat, a behaviour-driven development PHP-based test framework, with all tests written in the natural Gherkin language.

Using Behat empowers non-technical users to define acceptance criteria to the user stories that form the basis of the agile development methodology.

Testing locally

After building govCMS locally, navigate to the docroot directory. The following commands can be used to initiate the built in a PHP Web server and run all tests in the same manner Travis CI does.

$ php -S 127.0.0.1:8888 "../build/tests/drush/router.php" &amp;&gt; /dev/null &amp; $ phing -f build/phing/build.xml run-tests

Parameters in both Phing and Behat can be overridden if needed for different ports, URLs, database backends, etc. This can be done by altering the build.properties and behat.local.yml files.

Writing new tests

As recommended in the project’s CONTRIBUTING.md, any new features added to the platform should be accompanied by a test to ensure it is checked for regressions. New Behat tests can be written and added alongside others.

Features that require javascript support can be tagged with @javascript. This will ensure headless PhantomJS is used to test not only text output onto the page, but also JavaScript events.

Testing existing sites

The continuous evolution of the platform means that new code also needs to be tested against existing sites prior to production deployment. To test new releases, the Acquia CloudAPI is used to deploy all govCMS production sites into the stage environment, and run smoke tests using PhantomJS to detect changes.

Oct 22 2015
Oct 22

In our last post, we looked at why Manhattan Associates was happy with Drupal 8 from a front-end perspective. What sealed the deal for them, though, were the powerful ways they could extend and develop Drupal 8 with improved configuration management, a new Web services API, and easy internationalization.

Painless configuration management

Manhattan Associates’s internal development team was looking for best-in-class workflows and effective tools for collaboration with partner agencies such as Mediacurrent.

Drupal 8’s powerful config management reduces developer friction for testing and deploying new features, bringing the company cost savings while improving the development experience. With Drupal 8, it’s incredibly easy to set up and keep parity between your development, staging, and production environments so you know that if your application works in dev, it will work in prod. The new system can natively export your existing config and import it into a different environment — no need for reconfiguring elements or writing custom scripts to port settings. Configuration can even be stored in version control so you can easily roll back changes and share environments.

Importing is particularly painless with the built-in diff tool that displays incremental differences between the new and old configuration keys, improving clarity and minimizing the chance of misconfiguration.

Diff UI example from Alex Pott's "Principles of Configuration Management"

D8's configuration management also extends well using third-party modules. When a module is first loaded, its default values are inserted into your application’s “live configuration,” the whole configuration at that moment. If the module is updated and includes new default configuration, the new values will not automatically be imported into the live configuration, so that the module’s existing functionality will not be disrupted for your application. This behavior lets you keep modules up-to-date without worrying about breaking changes.

With Drupal 8 configuration management, Manhattan is able to reduce costs by improving efficiency both in-house and in collaborations. They no longer have to rely on partner agencies for complex config deployment, and when they do work with a partner, the simplified workflow and ease of pushing and testing config means they still see cost savings.

Integrating Web Services

Manhattan was also looking for ways to integrate Drupal with powerful third-party technologies, such as marketing and analytics tools, and they wanted a platform they could build on for years to come.

Drupal 8’s Web Services makes it easy to plug and play any application that wants to share data with Drupal. The package includes an authenticated RESTful API for data import and export that supports a variety of output formats, such as JSON and XML. Rather than having to store data in multiple places or across different services, data can be centralized in Drupal and retrieved through the API. Drupal can also be made a consumer of other services that can use the API to push data into Drupal. This functionality allows for greater interoperability between Drupal and technologies such as marketing, sales, and business intelligence tools.

With Drupal 8 Web Services, Manhattan Associates was able to integrate Eloqua, their preferred marketing platform, into Drupal seamlessly — and they’ll be able to integrate future services just as easily.

Batteries-included internationalization

Internationalization was key for Manhattan, a supply chain management software provider that offers services in more than 20 locations worldwide.

Multilingual capabilities are ubiquitous in Drupal 8, creating a simplified, more flexible, and more thorough platform for internationalization that meets Manhattan’s needs as a global company. Drupal 8 allows admins in global offices to work in their native language while collaborating with peers in other countries. An admin can choose from 94 languages for native install, and every interface, down to the config files, can be translated. For users around the globe, Drupal 8 websites are equally friendly. Every element of the site can be translated for the best experience in each language.

With Drupal 8’s fantastic support for translation, it’s a great solution for a global company like Manhattan Associates, or companies looking to grow an international presence.

Oct 20 2015
Oct 20

Not long ago, the only way content was delivered to you from the Web was via Web pages. You typed something into a browser and a server returned a page of information.

This singular method, however, has become outdated and no longer represents all the ways you and your applications are accessing content from the Web.

With the rise in smartphone usage came an increasing consumption of Web content via specialized purpose built apps. You are no longer sitting at a desktop asking browsers to fetch pages exclusively. Now you load apps inside of browsers, tablets, and phone desktops — and those apps are fetching structured data to present content to you in an easily consumable way.

Today the trend continues with the growth of wearables. You would have a hard time viewing a Web page on your watch. But your smartwatch is consuming and sending streams of structured data to Web servers.

Smart TVs do the same thing. And so do smart thermostats, and smart water meters. More and more of your devices -- many that don’t even have a screen -- will be consuming and sending structured data.

Is your content management system capable of delivering all of your content to all the platforms that you and your customers expect? How can you re-purpose all the content and metadata your company has stored in your CMS to power different applications?

At Myplanet we created the infographic, below, to capture this changing ecosystem.

The good news is that if you’re running Drupal you can easily create content that adapts to the demands of an ever-evolving Internet by decoupling the front and back end of your Drupal CMS. A decoupled Drupal platform will also allow you to post your content once and have it dynamically present content in the most effective format for each device you need to power.

Flexible content delivery will be crucial to effective content management going forward, and the next generation of sites running Drupal 8 will have highly adaptable options available from the start. Whether you want to return traditional Web pages and also deliver content as structured data via Web services, or you decide to disable Drupal’s "page" building capabilities entirely, Drupal 8 provides the flexibility content managers need going forward.

Oct 16 2015
Oct 16

Thinking about becoming an early adopter of Drupal 8?

Hesitate no longer. More than 400 sites are already running on it. Manhattan Associates is one of these Drupal 8 pioneers — here’s why they made that decision, and why they’re happy with it.

Manhattan Associates — a supply chain management software provider — wanted a modern, 100% mobile responsive, and flexible redesign. A leading Drupal development company, Mediacurrent, helped Manhattan determine that choosing Drupal 8 was the best approach to achieving those goals, and was well worth the early adopter risk.

Why? First, consider just a few of the many changes from Drupal 7 to Drupal 8, on the front-end side of things:

  • Fully HTML5 markup
  • 75% fewer CSS ids than in Drupal 7
  • Out of the box responsive and mobile ready
  • New and improved theme/template system: Twig

For Manhattan, Drupal 8’s mobile-first approach and improved theming -- thanks to Twig templates -- were key to their decision to go with Drupal 8. Let's take a closer look at why that worked for Manhattan Associates.

Responsive out of the box

A key requirement of Manhattan Associates was a modern, mobile-first approach that would allow them to serve great, relevant content to all devices. Drupal 8 helped them create an elegant and responsive mobile site with increased SEO, larger potential audience, and a stellar experience for their customers.

Drupal 8 was designed with a mobile first approach. Drupal 8’s default theme, Bartik, is fully responsive, so right away you can get a mobile responsive site up and running. Elements like menus and blocks will automatically reshape to fit well on any screen size; Drupal 8 also includes built-in support for responsive images, so images will shrink or grow to the appropriate size for desktop, tablet, smartphone. Going beyond the default themes, it’s also just easier to build a responsive site, since that was a core focus throughout Drupal 8’s development and design.

Mobile with Drupal 8 isn’t just better for customers, it’s better for developers. The new mobile-friendly administrative toolbar makes it easy for admins to hop around the site wherever, whenever.

Not only does Manhattan’s mobile site look beautiful, Drupal front-end performance improvements were built into the core. For example, jQuery was swapped out for native JavaScript where possible. Out-of-the-box Drupal 8 loads zero JavaScript files for anonymous visitors, and JavaScript-intensive features like the Overlay module were replaced with lightweight alternatives. While building a responsive site, Manhattan Associates ended up with a faster site as well, lowering bounce rate and retaining more traffic.

Elegant and powerful templating

For Manhattan, a fast-moving company that develops and maintains many new features in-house, having a clean and easy to maintain templating system was essential.

Drupal 8 uses Twig, a modern templating engine that generates performant PHP code. (It’s replacing PHPTemplate, so all the theme functions and PHPTemplate based *.tpl.php files have been replaced with *.html.twig files, which you’ll find in a new folder called templates).

It’s cleaner because there’s now a clear separation between the logic and the view — so there’s no more PHP code within template files. Debugging is easier, with Twig’s helpful messages including the problematic filename and line number for any syntax error (all you have to do to enable Twig Debugging is set the debug variable in the twig.config to "true").

Here's the node.tpl.php file from Drupal 7:

 <?php print render($title_prefix); ?>
<?php if (!$page): ?>
<h2<?php print $title_attributes; ?>>
<a href="https://dev.acquia.com/<?php print $node_url; ?>"><?php print $title; ?></a>
</h2>
<?php endif; ?>
<?php print render($title_suffix); ?>

And here's the node.html.twig file from Drupal 8:

{{ title_prefix }}
{% if not page %}
<h2{{ title_attributes }}>
<a href="https://dev.acquia.com/{{ node_url }}">{{ label }}</a>
</h2>
{% endif %}
{{ title_suffix }}

The new syntax is concise, easy to learn, and easy to read. That was a huge plus for Manhattan Associates, since their development team needs to design and adapt new features across platforms quickly. Twig’s power and simplicity allows them to iterate faster and increase their speed to market. Plus, increased security for the Drupal theme layer comes for free, because Twig uses a domain-specific language, which will automatically generate escaped, secure and correct HTML5, rather than embedding insecure, handwritten PHP and HTML directly. Additionally, Twig offers powerful sandboxing, which allows restricted execution of untrusted code for safe integration with 3rd party themes and components.

Read more about Twig and theming in Drupal 8 here: http://d8.sqndr.com/index.html

Oct 01 2015
Oct 01

The Problem

I have a theory.

My theory is that every single person / organization who is considering building a site on Drupal 8 has created some variation of the exact same spreadsheet. The spreadsheet tracks rows with information, such as which contributed projects the site needs, what URL those projects live at, who the maintainers are, what the project's current porting status is, etc.

To figure this out, you go to each of the respective project pages and look for an 8.x version. If that comes up empty, you attempt to search the issue queue for variations of "Drupal 8," "D8 port," etc. Worst-case, falling back to good ol' Google. Repeat every few weeks.

Man months have probably been spent on this duplication of effort so far.

To further build on that theory, I'm guessing that these spreadsheets do not always jive with current reality. Because you might have missed the update that contributor X gave on Twitter one time about her predicted module's release date. Or you might not have been sitting next to contributor Y at dinner during DrupalCon and found out that her module's actually being ported on GitHub or BitBucket, only being moved to Drupal.org when it's complete. Or you didn't get the chance to actually install the project yet to determine that even though this one has just a -dev release, it's actually quite stable, and even though that one has an beta release, it's changing APIs every 6 minutes. Or whatever.

The Solution

Enter the Drupal 8 Contrib Porting Tracker! This is a "meta" project that holds issues that represent the porting status of various projects, and allows us to work as a unified Drupal community to combine our collective observational super powers into one data set that can be used by anyone considering building on Drupal 8.

Screenshot of issue listing

How does it work?

Issues within the project move through an issue status workflow of:

(There are also a couple of special statuses that fall outside the general workflow.)

The goal is to get 100% of the projects in the list to "Fixed," as quickly as possible, to help enable widespread adoption of Drupal 8.

Each issue follows a standard template, which includes information such as who's porting the module, where to find the code, and what help is needed by the maintainers to expedite porting.

Project page for Drupal Commerce.

Why do we need this project?

Back when I first started at Acquia in May 2011, Drupal 7 had just recently come out and one of my first tasks was to facilitate a community-wide effort to get the big projects ported. This took the form of a standardized issue tag used in each of the projects' Drupal 7 tracking issues, and an external site to track status, which was more-or-less a public version of the Upgrade Status module with an opinionated list of projects.

However, this approach ran into a few problems:

  • Issue tags are easy to misspell/misplace, and require 'insider' knowledge to learn/remember the names.
  • Searching for the status of a module you cared about was difficult, because that status might be spread over multiple issues, or the module maintainer might not have gotten around to making a tracking issue yet.
  • Promoting an external, non-D.o site was difficult, as was performing those updates to the information that had to be done manually.

So I'm really excited about this project, since it eliminates all of these issues. It creates a single, canonical, searchable source for info, on Drupal.org in an "official" capacity, and with the ability to consistently track additional metadata such as estimated release timeline and how to help. I'm also excited that it enables people like project managers, folks at sprints without a lot of prior D8 experience, etc. to make meaningful contributions to Drupal 8.

Thanks!

The Drupal 8 Contrib Porting Tracker is a joint effort bootstrapped by many people before and during DrupalCon, including:

Kanban view of modules

So, bottom line, regardless if you're the module maintainer or not, "if you see something, say something" — please share whatever knowledge you have about various modules' porting status and/or places to help, so we can get all of these to green as quickly as possible, and Drupal 8 can achieve world domination! :D

Sep 15 2015
Sep 15

If you're reading this post in the Acquia Developer Center, I'm guessing that you may have used Drupal before.

You might be familiar with Drupal 6 or 7, and with some of the modules that shipped with those Drupal versions.

But, Drupal 8 is coming later this year -- a completely re-written version of the platform. This newest version will include lots of new features. At OSTraining we've been studying these features; we're already starting to work with them.

So here's an introduction to 10 new features that we think will be exciting when you use Drupal for the first time.

#1. New Fields

There are five completely new field types in the Drupal 8 core:

  • Date
  • Email
  • Link
  • Reference
  • Telephone

This screenshot shows the new interface for adding fields.

There have also been some smaller changes too:

  • The English used for field names is more straightforward. For example, "Integer" is now simply "Number".
  • Comments is now available as a field, rather than a setting.

#2. Fields are everywhere

Not only are there new fields, but you can now add fields in many more places.

You can add fields to nodes, blocks, comments, contact forms, taxonomy terms and users.

#3. CKEditor

Previous versions of Drupal did not provide a text editor.

Drupal 8 ships with CKEditor, one of the very best text editors on the market.

#4. Quick Edit

Thanks to the "Quick Edit" module, if you're logged into Drupal and looking at content, you'll be able to edit text directly from the front-end of your site.

#5. Responsive Images

Drupal 7 provided image styles in the core, which allowed you to automatically resize images.

Drupal 8 takes that a step further and allows you to choose different styles for individual images. The various styles will be used for different device sizes.

#6. Tour

Drupal's explanatory text was always hidden away under the "Help" link. Now, thanks to the Tour module, you can click the "Tour" link and see pop-ups that explain how Drupal works. The screenshot below shows a tour of the Views module:

#7. Views

Wait! Did I say "Views" in the last section?

Yes, I did. Views is now in the Drupal 8 core. Not only is it available by default, but most of the Drupal administration screens now use Views, which makes them easy to customize.

#8. Multilingual

Multi-lingual Drupal 7 sites required you to install numerous modules. The process is much smoother in Drupal 8, with 4 key modules in the core.

Once those modules are enabled, you can almost immediately start translating your site.

#9. Configuration Manager

The new Configuration Manager module in Drupal 8 makes it much easier to export and import the features that you build.

For example, if you create a new content type, you can export it from your test site and easily import it into a live site.

#10. Webservices

As with multi-lingual sites, it used to require several contributed modules to create a webservice in Drupal 7. Now, in Drupal 8, everything you need is in the core.

Enable the four Web Services modules, go to Views, and you'll immediately be able to create a REST export.

Sep 11 2015
Sep 11

Regardless of whether you’re developing a Drupal website or a Drupal module, you have to be aware of how visitors and users will interact with things. The primary way that you can control this access is through permissions.

Permissions (along with users) are a fundamental component of Drupal administration, and using them correctly can make the difference between having a secure, reliable website, and having a website that exposes information about its visitors -- which you may end up hearing about on the evening news.

So how do you do this? How can you learn more about managing users and permissions on your website, and what additional options you may have if you host your website on Acquia Cloud? As a module developer, where can you find the best practices regarding permissions, and what are the hooks you can use to access those permissions on a Drupal website?

A good start is our permissions best practices article on the Acquia Help Center.

And, once you’re done, for even more information that you can use with your Drupal website, feel free to browse any of the other articles and resources in the Acquia Help Center!

Sep 10 2015
Sep 10

This is the second and final installment in our series covering Acquia Global Support Team’s third-party API integration with Zendesk (part one covered Five Ways to Leverage Third-Party APIs: The Drupal-Zendesk Integration). 

Acquia’s Drupal-Zendesk integration allowed them to build an expert Help Center for their Global Support team. Using Zendesk’s documented API to build a Customer UX in Drupal, Acquia was able to seamlessly integrate all their existing systems into a shiny, new Acquia Help Center.

The new Drupal-Zendesk system generated huge results. SLA increased to 99%, and support teams reduced average time spent on ticket by 25%. Additionally, the new system allowed the team to handle a 60% volume increase of tickets with less than 10% increase of staff. These results prove that the Acquia Help Center is fast, efficient and keeps both customers and support teams happy.

However, developing such a dynamic integration isn’t without its challenges. Not all partnerships will be a match made in API integration heaven. Here are three best practices you can adopt when integrating with third-party APIs.

1. Know your requirements and be honest

Acquia has a lot of fantastic in-house engineering talent, and could have built a ticketing system to service their support team. However, Acquia’s core business is not to maintain a support request system. In addition to solving tickets, individuals on the support team write knowledge based articles, attend meetings and works to heighten the power of the Drupal and Acquia communities.

Jeannie Finks, Director of Global Support Systems and Programs at Acquia, says through a Drupal-Zendesk integration they were able to “develop a unified complementary system that allows us to focus on our core business.” Zendesk’s core competency is providing a customer service software and that takes a lot of work to maintain. By utilizing Zendesk’s expertise, Acquia was able to make their product stronger.

“A lot of companies definitely want to do it all,” Finks says, “but having a good understanding of your requirements allows you to invest resources with a vision.” That means being honest about what your team can fulfill and learning to leverage products like Zendesk. At Acquia, customers can continue to rely on the Help Center for 24/7 global support.

2. Build an environment that will evolve

Finding an API that provides flexibility is essential for a company that plans to grow with evolving technology. Keep systems and programs simple so teams can work towards continued improvement. Evolutionary success will stem from solutions that are not strictly out of the box. Allocate time and resources towards efforts that will enable you to customize products for the long term success of your team.

Acquia’s partnership with Zendesk provided them the flexibility needed to integrate existing systems like JIRA and Toggl. With an API like Zendesk, companies are able to extend framework capabilities through customized integrations. This mobility will allow Acquia’s team to quickly adapt and transform their systems to advancing technical environments.

3. Value "Minimum Loveable Product" over "Minimum Viable Product"

At Acquia, the Global Support team placed priority on the Minimum Loveable Product over the Minimum Viable Product methodology. The MVP may offer quick and easy solutions, but often compromises the product quality that ensures customer support and satisfaction.  

“A lot of people are very invested in the minimum viable product,” Finks explains. “But if your staff and customers aren’t enjoying or loving their experience, it doesn’t really matter how viable it is”.

At Acquia, the Support Team’s MLP reduced the number of steps required for support agents to get the job done. The ability to aggregate all systems under Zendesk’s API relieved staff pain points and streamlined workflow, making the Acquia Help Center a loveable platform for supporting customers. Companies can build an MLP with clear and driven decisions. Keeping products simple enables companies to execute them well.

Screen Shot 2015-08-12 at 4.37.37 PM.png

Acquia’s Global Support Team, along with Engineering, completed their Drupal-Zendesk integration at 11pm on February 13th 2014. With a looming New England blizzard and Valentine’s Day around the corner, the team was able to implement a new Acquia Help Center before the start of Acquia APJ’s work day.

“Ultimately it is about understanding where your business comes into play, and having a great team of people to help accomplish your goals,” Finks says.

Acquia seems to have both, as their Drupal-Zendesk integration serves as a model for companies looking to leverage third-party APIs.

Sep 03 2015
Sep 03

After working with both Chinese customers and global customers with a Chinese user base, we at Acquia have developed an understanding not only of the sometimes difficult requirements faced, but also the existing state of both sites and platforms.

From well-known challenges like the Great Firewall of China (GFW), to the lesser known problems of ICP licenses (for Internet Content Provider, a permit issued by the Chinese Ministry of Industry and Information Technology to permit China-based websites to operate in China), to hosting availability, the Acquia APJ (Asia, Pacific & Japan region) team has seen and dealt with most of these difficult requirements.

Currently the relevant Amazon Web Services region in Beijing (AWS cn-north-1), which I've circled below, contains just one availability zone (AZ), making the standard High Availability Architecture (HA) setup Acquia utilises in all other regions impossible.

This means the majority of Acquia customers requiring a Chinese presence manage their sites out of either Tokyo (ap-northeast-1) or Singapore (ap-southeast-1).

To ensure our customers’ sites remain online, the Acquia Cloud utilises a high availability (HA) architecture, removing single points of failure. To do this, we use multiple AZs within a hosting region and split web servers, database servers, load balancers and all other components between them. Using separate power and network grids in each AZ allows us to have confidence that even in the worst of circumstances, sites remain online.

Elsewhere in China, some of the largest companies in the world by revenue are moving into the hosting business. The two largest providers are Baidu Cloud (???), a hosting offering from online services company Baidu, and Ali Cloud (???), a cloud computing offshoot from giant Alibaba.

Baidu hosts its own services, provides online storage and a developer centric execution environment. Ali Cloud provides an elastic distributed environment and hosts both Taobao and Zhifubao, the Chinese equivalents of eBay and Paypal respectively. The final option, Tencent, the company behind the Chinese messenger service QQ, has started their own cloud endeavours although at a smaller scale.

Despite a flourishing cloud industry, hosting in China hasn’t yet stretched into the realms of fully managed platforms yet. Whether it’s a shared server, a dedicated box with access to the root user, or a cPanel enabled server without command line access; the result is just a box to put a site on without configuration, guarantees or support.

While hosting providers are moving towards Xen as a standard practice, much of the existing shared hosting in the country utilises Windows as both the hypervisor and operating system. The effect of this is that more modern web languages and frameworks, designed with Linux in mind, may not be fully supported.

(from http://www.cioage.com/)

The prevalence of Windows as the operating system is reflected by some of the choices in CMS used by Chinese organisations. A scan of websites hosted within the country shows that open source is by far prefered to proprietary but with a number of home grown solutions developed for IIS/PHP taking the largest share. Discuz, DedeCMS and Z-Blog are all used widely but for narrow scoped applications of forums and blogs rather than the wider variety of possible uses Drupal has the potential for.

 

Finally, with mobile users in China accounting for 85.8% of online users and a mobile-to-desktop online ratio of roughly 6:5 (from the China Internet Network Information Center), the idea of responsive design and a mobile first online strategy should be paramount. However, the move away from sites based around <table> tags is a slow and drawn-out process, with many popular sites continuing to exhibit a more traditional theme (http://www.sina.com.cn/ and http://www.sohu.com/).

The result of the above leads us into a situation where a large proportion of online activity in China is reliant on outdated second class hosting platforms unable to offer a best-in-class experience for site visitors.

A disruptive transformation brought about by increased adoption of Drupal and Acquia in China would lead to fully-supported sites with faster page loads, better UX, greater control for site editors, and an assurance that the sites remain online. This in turn would ultimately lead to more conversions and increased revenue, desirable for everyone.

Next: I’ll take a look behind China’s Great Firewall (GFW), and what it means for organizations that are operating outside, and inside, China.

Sep 03 2015
Sep 03

Reason #1: Drupal is Technology Ready

For the past 15 years Velir has been customizing and implementing top-tier content management systems. Given our focus on creating digital solutions, content management is at the core of almost every project we take on.

We’re veterans in the CMS space, but up until recently we exclusively worked with commercial CMS platforms. As the CTO of my agency, I wanted to explain why we’ve now decided to take the leap with Drupal.  

This post focuses on one reason we like Drupal: because it offers a solid technical foundation to build upon.  This foundation has been created by a large and passionate community, has shown an ability to evolve intelligently over time, and is being guided by strong leadership which is positioning the platform for the future.

The Strength of Open Source

Even a casual follower of the CMS space will have noticed how the “proprietary vs open source” conversation plays out regularly each year.  We have never bought into the FUD spread by both sides of this debate, as it’s usually a philosophical argument rather than a capability-based comparison of each platform.

But it is undisputable that open source software excels at providing tools and platforms for well understood problems.  As a result, over the past 20 years, there have been a number of problems that could be considered solved in the CMS space:  structured data, versioned content, workflow, accessible content APIs, and rich text editing (well, maybe not this one, yet). Drupal has a strong community with thousands of developers who have contributed to making sure these problems are solved well. Going forward we are excited to contribute to this community by supporting our team to contribute their own projects and solutions for Drupal.

Big Changes, Big Progress

As Drupal 8 has taken shape over the past few years, it has become clear that the project is evolving in intelligent ways.

The Drupal project was arguably growing too large to stay nimble - most everything had been built from the ground up. The continued growth of custom built sub-systems were demanding time and attention from the core team.  

In 2012, the collaboration between the Drupal and Symfony project teams signaled an important shift: a willingness to shed custom built pieces of the Drupal framework and partner with other proven projects for large pieces of functionality.  

This introduces a critical dependency on an outside project, but in exchange it provides a great deal of freedom for the Drupal community.  It allows them to apply more focus on solving the unique problems of web content management, rather than working on a series of problems that have been elegantly solved elsewhere.

Another key evolution we’re excited about is the embracing of an Object-Oriented Programming (OOP) approach in Drupal 8.  OOP offers a long history of promoting design patterns for solutions, which once learned, can easily be adopted to build well-architected systems.  Our experience tells us that these OOP principles and techniques will promote reuse, extensibility, testability -- and lead to solutions that are more efficiently maintained.  

Built with the Future in Mind

Accessible digital content is vital for modern organizations.  Content may be repurposed for display on the desktop or mobile web, pushed to native devices, or pulled into content aggregators like Flipboard or Prismatic.  

Dries Buytaert, founder of Drupal and co-founder of Acquia, has been cultivating a strong vision for how Drupal fits into the future of web content management. With core support for RESTful content APIs, schema.org support for boosting semantic tagging, and the rising buzz around Headless Drupal implementations, it’s clear that Drupal is being positioned to serve future content management needs.  

As an agency, Velir has remained focused on building deep expertise with the best platforms in the market.  We’ve been doing this long enough to know that no technology platform offers a panacea to a company’s digital needs.  

To sum up: We feel Drupal’s technical foundation is solid and we are reassured that the project is evolving intelligently to meet future needs.  In the next post, I’ll share some of the non-technical motivations behind why we have decided to invest in a Drupal practice.

Sep 02 2015
Sep 02

The biggest risk for any website is security. Research has shown that the average cost of a data breach is several million dollars. The last two years have seen a number of high-profile security breaches affecting millions of people, including:

  • 145 million eBay users
  • 70 million Target customers
  • over 20 million U.S. government job applicants.

That’s why it’s important to ask yourself: Does your company have the expertise and resources to manage your websites’ security?

Acquia Cloud engineering and operations teams are constantly responding to security threats and updating hundreds of mission-critical software packages behind the scenes. Do your engineers know how to manage the complexity of the hundreds of mission-critical software packages required to run modern websites? Do they have the processes in place to get notified of vulnerabilities and roll out changes before attackers can exploit them?

It can easily cost millions of dollars for the expertise and development required to manage your websites’ security in-house. If you’re managing your own security and not spending that money, you may be making trade-offs that put your business and your reputation at risk.

Many companies can’t afford that kind of investment in security expertise, and that’s why many of them choose Acquia Cloud. Acquia Cloud removes a number of risks and challenges of building and running websites, including security risks. We have invested those millions of dollars in expertise, processes, and hardened security architecture so that our customers stay safe without having to think about it. And we are evaluated annually by independent third party auditors to validate our practices and alignment with standards.

Our security practices extend beyond our platform and infrastructure. Our Remote Administration team can update user applications when Drupal core or contributed modules are out of date. Password strength and multi-factor authentication requirements can be enforced to log into the Cloud administration dashboard, and actions on that dashboard are managed via granular access controls (complete with an activity stream to audit changes). We also offer protection at the network level with Acquia Cloud Edge to deny malicious web requests and Acquia Cloud Shield for keeping especially sensitive information inaccessible from the public internet.

One other way we make sure our customers stay safe is to disable software that has reached its end-of-life and is no longer receiving security updates. For that reason, we recently disabled PHP 5.3 on our platform (the lowest version we now support is PHP 5.5). As we do whenever we deprecate functionality, we provided our customers an extended notice period and worked with them to make sure their applications work on newer, secure versions of PHP. If you’re using a vendor that continues to run insecure versions of such mission-critical software, you should think twice about their security practices. When you use Acquia Cloud, we stay on top of those risks so that you don’t have to.

One example of our commitment is our response to security events, like when we were the only Drupal platform-as-a-service company to protect all customer sites against the critical Drupalgeddon vulnerability without any loss of site functionality or availability. Similarly, when vulnerabilities like Heartbleed, POODLE, Shellshock, and others (from the past year alone) shook the foundations upon which websites rely, Acquia was able to rapidly update our entire fleet of affected servers while keeping our customers’ sites online.

If you’re unsure about your security situation or requirements, talk to us and we can help you figure out what you need. One option is our security workshop where we work with you to analyze your situation and offer recommendations.

It’s better to find out your requirements - especially legal ones like PCI compliance - as early as possible, before you commit to a vendor that puts the cost burden on you.

Aug 31 2015
Aug 31

Training Acquia employees how to use Drupal 8 had two purposes. First, there was the obvious need for our company – one that specializes in building and delivering a digital experience using Drupal – to get everyone up to speed on the new version.

But we also felt our training sessions had a larger purpose: to inform the larger Drupal community on the ins and outs, not to mention joys and pains, of the updated version. So as we embarked on our long training program of nearly 50 employees, we documented our progress.

We focused on module porting and module development for reasons my co-author Thomas Howell and I referenced earlier in this series about Drupal instruction. We also followed that path because we found that digging into how the modules were built showed how Drupal itself was built.

It’s a mirror of how those core modules are built. You can break them down conceptually and learn what a YAML file is, see what has changed with the info file, and review other concepts. Learning to do that in the module context helps you understand what it’s doing within Drupal overall, which makes it more possible to see what problems you’re encountering and how to troubleshoot them.

There is a lot of good documentation out there now about Drupal 8 that wasn’t there when we started. We like what we’ve created; it works for us. It definitely does not work for everyone, but picking a place to start and then trying to do it consistently at least allows you to understand what you can do and what you can’t.

You may feel as if your organization is too small and you won’t have the resources to handle training and regular work duties. If that’s inescapable, consider joining forces with another small organization. Small teams can work with other small teams, sharing lesson plans, documentation, and approaches. Also, you can consider using Drupal camps or monthly Drupal meet-ups in your area. Working together, you can build momentum and help each other reach a goal.

Speaking of working together: there was some resistance to our training method. There were lone wolves. There were people who wanted to just charge ahead and do it on their own. In those situations, we just found a way to work. We told them they could proceed at their own pace but were obligated to reach the same goals as the others. We wanted consistency and an idea of what to expect when training a large organization.

Again, we were not looking for everyone to become experts, but we were trying to dispel the fear, uncertainty, and doubt that comes along with massive change. By breaking things down, change was more comfortable. Employees were able to build things, troubleshoot, and talk. Suddenly, it wasn’t a daunting prospect.

Community is what Acquia is all about. It’s what we really hold dear. So when we need to learn something that is big and scary, being able to pass along that knowledge to others makes the challenge surmountable and is actually motivating. Even if you do something as simple as write a test for a module that somebody else is porting, it is still giving back and noticeable.

With that, we'll bring this series to a close. We hope you've enjoyed reading it, and that you've been able to take away some useful advice on how to approach learning and training others on this exciting new version of Drupal.

Aug 27 2015
Aug 27

Security is very hard to bolt on to any software or product after it has been built. Building it into the core of the code helps to avoid mistakes, and thus the upcoming release of Drupal 8 tries to build in more security by default, while still being usable for developers and site builders. This list of 10 security improvements is not exhaustive - some are just a line or two to handle an edge case, and there are others I may have overlooked. I've contributed to a number of these improvements, but they reflect overall the community consensus as well as reactions to problems that required security releases for Drupal core or contributed modules in the past. For each point I've tried to include a link or two, such as the Drupal core change record, a documentation page, or a presentation that provides more information. Some of these may also be possible to back-port to Drupal 7, to benefit you even sooner. A "7.x back-port" link indicates that.

For context on why these 10 improvements are important, I looked at past security advisories (SAs) as well as considering the kind of questions we get here at Acquia from companies considering adopting Drupal. In terms of past SAs, cross-site scripting (XSS) is the most commonly found vulnerability in Drupal core and contributed modules and themes.

  • Twig templates used for html generation

    This is probably first on the list of anyone you ask about Drupal 8 security. This is also one of the most popular features with themers.??

    One security gain from this is that it enforces much stricter separation of business logic and presentation – this makes it easier to validate 3rd party themes or delegate pure presentation work. You can't run SQL queries or access the Drupal API from Twig. ???

    ??In addition, Drupal 8 enables Twig auto-escaping, which means that any string that has not specifically flagged as safe will be escaped using the PHP function htmlspecialchars() (e.g. the same as Drupal 7 check_plain()). Auto-escaping of variables will prevent many XSS vulnerabilities that are accidentally introduced in custom site themes and custom and contributed modules. That fact is why I ranked this as number one. XSS is the most frequent security vulnerability found in Drupal code. We don't have a lot of hard data, but based on past site audits we generally assume that 90% of site-specific vulnerabilities are in the custom theme.?

    To see why themers love Twig, compare the Drupal 7 block.tpl.php code to the Drupal 8 Twig version.

    Drupal 7 block.tpl.php:

    Drupal 7 block.tpl.php

    Drupal 8 block.html.twig:

    Drupal 8 block.html.twig

  • Removed PHP input filter and the use of PHP as a configuration import format

    OK, maybe this should have been number one. Drupal 8 does not include the PHP input format in core. In addition to encouraging best practices (managing code in a revision control system like git), this means that Drupal no longer makes it trivial to escalate an administrator login to being able to execute arbitrary PHP code or shell commands on the server. ?

    For Drupal 7, importing something like a View required importing executable PHP code, and for certain custom block visibility settings, etc. you would need to enter a PHP snippet. These uses of evaluated PHP (exposing possible code execution vulnerabilities) are all gone – see the next point about configuration management.?

    Now that we have covered the top two, the rest of the 10 are in rather arbitrary order.

  • Site configuration exportable, manageable as code, and versionable

    The Configuration Management Initiative (CMI) transformed how Drupal 8 manages things that would have been represented in Drupal 7 as PHP code. Things like Drupal variables or ctools exportables (e.g. exported Views).??

    CMI uses YAML as the export and import format and the YAML files can be managed together with your code and checked into a revision control system (like git). ?

    Why is this a security enhancement? Well, in addition to removing the use of PHP code as an import format (and hence possible code execution vulnerability), tracking configuration in code makes it much easier to have an auditable history of configuration changes. This will make Drupal more appealing and suitable for enterprises that need strict controls on configuration changes in place. In addition, configuration can be fully tested in development and then exactly replicated to production at the same time as any corresponding code changes (avoiding mistakes during manual configuration).? Finally, it is possible to completely block configuration changes in production to force deployment of changes as code.?

  • User content entry and filtering improved

    While the integration of a WYSIWYG editor with Drupal core is a big usability improvement, extra care was taken that to mitigate poor practices that adding a WYSIWYG editor encouraged in past Drupal versions. In particular, users with access to the editor were often granted access to the full html text format, which effectively allowed them to execute XSS attacks on any other site user.??

    To encourage the best practice of only allowing the use of the filtered HTML format, the Drupal 8 WYSIWYG editor configuration is integrated with the corresponding text filter. When a button is added to the active configuration, the corresponding HTML tag is added to the allowed list for the text filter.?

    Drag a new button from the available to enabled section in the editor configuration:

    WYSIWYG editor configuration adding underline button

    The corresponding HTML tag (the U tag) is added to the allowed list:

    U tag is allowed in the filter

    An additional security improvement is that the core text filtering supports limiting users to using only images local to the site which helps prevent cross-site request forgery (CSRF) and other attacks or abuses using images.

  • Hardened user session and session ID handling

    There are three distinct improvements to session and session cookie handling.

    First, the security of session IDs has been greatly improved against exposure via database backups or SQL injection (7.x back-port ). Previously in Drupal, the session ID is stored and checked directly against the incoming session cookie from the browser. The risk from this is that the value from the database can be used to populate the cookie in the browser and thus assume the session and identity of any user who has a valid session in the database. In Drupal 8, the ID is hashed before storage, which prevents the database value from being used to assume a user's session, but the incoming value from the value is simply hashed in order to verify the value.?

    Next, mixed-mode SSL session support was added to core to support sites that, for example, used contributed modules to serve the login page over SSL while other pages unencrypted. You will have to replace the session handling service if you really need this. This encourages serving your entire site over SSL (which is also a search engine ranking boost).??

    The final change is that the leading “www.” is no longer stripped from the session cookie domain since that causes the session cookie to be sent to all subdomains (7.x back-port)

  • Automated CSRF token protection in route definitions

    Links (GET requests) that cause some destructive action or configuration change need to be protected from CSRF, usually with a user-specific token in the query string that is checked before carrying out the action.

    ??This change improves the developer experience and security by automating a process frequently forgotten or done incorrectly in contributed modules. In addition, centralizing the code makes it easier to audit and provide test coverage.

    Drupal 8 makes it easy. A developer merely needs to specify that a route (a system path in Drupal 7 terms) require a CSRF token. Here is an example of the YAML route definition for a protected link in Drupal 8 entity.

    entity.shortcut.link_delete_inline:
      path: '/admin/config/user-interface/shortcut/link/{shortcut}/delete-inline'
      defaults:
        _controller: 'Drupal\shortcut\Controller\ShortcutController::deleteShortcutLinkInline'
      requirements:
        _entity_access: 'shortcut.delete'
        _csrf_token: 'TRUE'
    

    Only the one line in the requirements: section needs to be added to protect shortcut deletion from CSRF.

    Shortcut inline delete link and corresponding URL with a token in the query string:

    Drupal page showing shortcut

  • Trusted host patterns enforced for requests

    Many Drupal sites will respond to a page request using an arbitrary host header sent to the correct IP address. This can lead to cache poisoning, bogus site emails, bogus password recovery links, and other problems with security implications.

    For earlier versions of Drupal, it can be a challenge to correctly configure the webserver for a single site that uses sites/default as its site directory to prevent these host header spoofing attacks. Drupal 8 ships with a simple facility to configure expected host patterns in settings.php and warns you in the site status report if it's not configured.

  • PDO MySQL limited to executing single statements

    If available, Drupal 8 will set a flag that limits PHP to sending only a single SQL statement at a time when using MySQL. This change would have reduced the severity of SA-CORE-2014-005 (a SQL injection vulnerability that was easily exploited by anonymous users) (7.x back-port)?. Getting this change into Drupal 8 meant I first had to contribute a small upstream change to the PHP language itself, and to the PDO MySQL library that is available in PHP versions 5.5.21 or 5.6.5 and greater.

    There is also a patch in progress to try to enforce this protection regardless of which specific database driver is being used.

  • Clickjacking protection enabled by default

    A small change, but Drupal 8 sends the X-Frame-Options: SAMEORIGIN header in all responses by default. This header is respected by most browsers and prevents the site from being served inside an iframe on another domain. This blocks so-called click-jacking attacks (e.g. forms or links on the site being presented in a disguised fashion on an attacker's site inside an iframe), as well as blocking the unauthorized re-use of site content via iframes. (7.x back-port).

  • Core JavaScript API Compatible with CSP

    Support for inline JavaScript was removed from the #attached property in the Drupal render API. In addition, the Drupal javascript settings variables are now added to the page as JSON data and loaded into a variable instead of being rendered as inline JavaScript. This was the last use of inline JavaScript by Drupal 8 core, and means that site builders can much more easily enable a strict content security policy (CSP) – a new web standard for communicating per-site restrictions to browsers and mitigating XSS and other vulnerabilities.

  • A final note of caution: The substantial code reorganization and refactoring in Drupal 8 as well as the dependence on third party PHP components does present a certain added risk. The code reorganization may have introduced bugs that were missed by the existing core tests. The third party components themselves may have security vulnerabilities that affect Drupal, and at the very least, we need to track and stay up to date with them and fix our integration for any corresponding API changes. In order to try to mitigate the risk, the Drupal Association has been conducting the first Drupal security bug bounty that has been run for any version of Drupal core. This has uncovered several security bugs and means they will be fixed before Drupal 8 is released.

    I am excited that we've added more “security by default” to Drupal 8, and I hope you download and try it out so you are ready to start using it for new projects as soon as it's released.

    Aug 27 2015
    Aug 27

    Securing your siteThese days, using SSL with your website isn’t just a good idea — it’s essentially a requirement. Encrypting the information that’s sent between visitors’ browsers and your website is the new price of doing business.

    Fortunately, Acquia has a lot of experience helping to secure websites, and we’ve collected several of these tips into a best practices article on the Acquia Help Center.

    Want to know about using Varnish with SSL (and you’re an Acquia Cloud user)?

    It’s in there.

    Want to ensure that all of your website’s assets are served to visitors using the HTTPS protocol?

    It’s in there.

    Want to set up your 301 redirects from your HTTP pages to HTTPS?

    Surprise! It’s in there.

    For more information on how best to use SSL with your website, visit the article and read for yourself.

    And for even more information that you can use with your Drupal website, feel free to browse the articles and resources on the Acquia Help Center.

    Aug 26 2015
    Aug 26

    We couldn’t have trained dozens of Acquia employees on Drupal 8 without using various applications to schedule, measure our progress, and follow communications about the massive undertaking.

    Let’s take some time in this, the fifth blog in a series about Drupal 8 instruction, to give a quick overview of the tools we used to train.

    We used the collaboration software Confluence because we could set it up quickly. Kent Gale, the co-author of this blog and my partner in the training project, and I would have preferred to have built a tool within Drupal. But we went with Confluence because we were able to deploy it quickly and edit content. It’s where we placed project documentation to enable in-place editing.

    Calendars kept in Google Docs spreadsheets accounted for every employee’s time. Every trainee had time blocked off each week for training. It was protected time, so to speak, agreed upon by employee and supervisor – time that was free of any other obligation. Each week, I’d also schedule 30 minutes with each employee – although meetings didn’t last that long – to talk about training. I wanted to see if they faced any barriers or had questions they were too embarrassed to ask in training sessions. We found this hands-on check-in – which was brief but frequent – kept everyone on track.

    We also used email and a chatroom to communicate. Initially, email was the preferred route, but as more people enrolled in training, the chatroom was better able to handle the flow of communications. The spontaneity of a chatroom allowed a lot of questions to be answered quickly. It built a resource as well as type of behavior.

    On our tracking sheet, we followed the time each employee spent on training and could see how much time was left. We also tracked the lessons they completed and could see if a team fell behind and could quickly address why.

    When you’re ready to train, find a tool and use it a lot before starting the program to ensure it will accomplish what you need. Then pick an end date and work backwards. That will tell you how much time you’ll have. From there, you’ll be able to determine if you should compress training to reach a deadline or if you can spread it out over time.

    As organized and motivated as we were, and despite starting early, it was still difficult to carve out time for nearly 50 people, and keep our end-date within reach. It was a commitment. So keep that in mind: Your managers and employees have to commit to protecting training time to make it all happen. Otherwise, it’s very easy to let the opportunity slip away.

    Aug 24 2015
    Aug 24

    Not every student learns the same way, so teachers consistently have to find a way to instruct a classroom while also reaching students individually.

    We were reminded of a teacher’s greatest challenge when we trained dozens of Acquia employees on Drupal 8. As my co-author Kent Gale and I detailed earlier in this series on Drupal 8 instruction, we separated employees into groups of two, with one person having some knowledge of the new platform and the other having no knowledge. Once their instruction ended, they split up and each teamed with two other employees – our version of chromosomal mitosis.

    Our approach to training was structured. We had goals to achieve. But we also had to stay flexible throughout. Because experience, knowledge, and skill set differed with each employee, we had to connect with them individually while maintaining the larger class structure.

    We had people with deep programming experience. We had middleware folks. We had site builders. We had front-enders. Because of that, the training program had to present a lot of material, but not so much that individuals wouldn’t learn. We trained with the expectation that not everyone would, or even needed to, become experts.

    Consider the training of our “explainers,” the employees who explain our products to the public. We had to figure out what they could easily learn in only one- to four-hours of training. They needed to know enough to promote and answer questions about Drupal 8, but didn’t need to know as much as a support person, who received anywhere from 40 to 80 hours of training. Figuring out what the explainers needed to learn took some effort, but there was ample material to help us determine which path to follow.

    Speaking of paths, your team doesn’t have to follow ours. Mitosis worked great for us, but it may pose a problem for your program if you have fewer employees, less time to train, or other considerations.

    You need to find out what works best and that, as we’ve mentioned, takes time and effort, success and failure. Some employees like to be lone wolves and learn everything on their own, for example, so our process may not work for them.

    Tools that track progress will help you ascertain what works and what doesn’t. Every company, no matter how large or small, faces time constraints, so these tools will guide you through the unknowns.

    We used training as a key performance indicator (KPI) for employees. Shared ownership in this big Drupal 8 training project made sense if we all had to make a big leap together in understanding the new platform. Sometimes employees will sweep training under the rug because they believe putting out other fires is a priority.

    We knew learning Drupal 8 would be a significant commitment; it’s a significant change, after all. But we couldn’t delay training. Drupal 8 was coming out and there was no time for delay. KPIs helped motivate and get everyone on the same page. There was a vested interest in making progress.

    Aug 21 2015
    Aug 21

    If you’re considering a switch to Drupal 8, why not become an early adopter? Becoming an early adopter has some risks — and Acquia will work with you to mitigate those risks — but it also has huge benefits.

    In this post, I want to talk to you about those benefits and also share with you my experience with Examiner and its early adoption of Drupal 7.

    If you’re not familiar with it, Examiner is a news company powered by thousands of self-contributing writers. Currently, it’s read by 22 million people a month. But back in 2009, the company was having problems with its ColdFusion CMS, and those problems were hampering its growth.

    Examiner decided to move away from the legacy homegrown platform to Drupal. So they acquired NowPublic, a citizen-journalism company I founded, for its Drupal expertise and leadership. That’s how I became the CTO of Examiner (I later joined Acquia in 2012).

    Moving ahead, the big question we faced at Examiner was: Do we go with Drupal 6, a stable but mature technology? Or do we take a bold leap and implement the yet-to-be-released Drupal 7? Ultimately, we chose to become early adopters, going with Drupal 7.  

    Here are the reasons that powered that decision:

    1) You stay in front of the technology wave

    While a good product at the time, there was no denying that Drupal 6 was closer to its end of lifecycle, while Drupal 7 was just taking off. We already understood the costs involved in supporting a legacy product. And we knew any extra investment early on would be offset by things like a longer lifecycle.

    As a side note, unlike previous versions of the platform, Drupal 8 releases will come out every six months. So if you plan to become an early adopter of Drupal 8, not only are you taking advantage of the latest and greatest today — but you will continually upgrade to the latest features over the lifecycle of the product.

    2) You differentiate yourself from the competitors

    At Examiner, we wanted to set ourselves apart from the competition and we knew D7 would give us that edge. AOL was starting to invest in Patch at that time. And we felt that if we wanted to grow our audience and draw the best journalism to our site, we needed best-in-breed tools.  

    3) You can attract the top talent

    Great developers want to be on the cutting edge. Who wouldn’t want to jump on an opportunity to work full-time on their passion and be able to contribute back to Drupal? When we brought in a great platform at Examiner, we attracted the best Drupal developers in the world. Very quickly, we hired 15 of the top 50 developers in the Drupal community.  

    4) You have the opportunity to shape your investment

    Getting in on Drupal 7 earlier put us in the driver’s seat with the technology. That was important. We weren’t looking to adopt just any set of tools. We wanted an opportunity to shape the next generation of a platform. And we knew Drupal was going to meet our needs better than anything else out there. Plus, it’s a lot less risky than building your own CMS, because you are not going it alone. You’re going in as part of a community.  

    5) It forces you to develop best practices

    Being an early adopter forces you to use best practices with respect to software development. At Examiner, we were able to participate in the community and contribute code to the platform. So for us, being an early adopter forced us to do things the right way — and that set a standard within the company moving forward.

    After a year of work, Examiner moved to a new platform built on Drupal 7. Thanks to Drupal 7, Examiner went from not being able to meet the needs of its users to exceeding them. We were able to deliver new features on a faster cadence. We had the best-in-breed platform, the easiest to use interfaces, and ultimately those features accelerated the growth of the company.

    Examiner launched on Drupal 7 six months before the official release of the platform. We started developing on it almost a year and a half before the release. So we were really early adopters. Examiner faced tremendous risks, because at that time, Drupal 7 was nowhere near as put together as Drupal 8 is today, but we still decided to do it — and it paid off.  Today, Examiner is a top 60 website.

    Being an early adopter is definitely an investment. It will cost more to be an early adopter of Drupal 8, but as Examiner has demonstrated, those costs are set off by several factors. And if you are concerned about the risks, keep this in mind: more than 400 sites are already running Drupal 8. And Acquia has already announced we are ready to support anyone with Drupal 8.

    What are your thoughts? Do you have any experiences on being an early adopter of Drupal 7? And how do you feel about the risks/benefits of being an early adopter for Drupal 8? We’d love to hear back from you and get the conversation going.

    Aug 21 2015
    Aug 21

    If you’re considering a switch to Drupal 8, why not become an early adopter? Becoming an early adopter has some risks — and Acquia will work with you to mitigate those risks — but it also has huge benefits.

    In this post, I want to talk to you about those benefits and also share with you my experience with Examiner and its early adoption of Drupal 7.

    If you’re not familiar with it, Examiner is a news company powered by thousands of self-contributing writers. Currently, it’s read by 22 million people a month. But back in 2009, the company was having problems with its ColdFusion CMS, and those problems were hampering its growth.

    Examiner decided to move away from the legacy homegrown platform to Drupal. So they acquired NowPublic, a citizen-journalism company I founded, for its Drupal expertise and leadership. That’s how I became the CTO of Examiner (I later joined Acquia in 2012).

    Moving ahead, the big question we faced at Examiner was: Do we go with Drupal 6, a stable but mature technology? Or do we take a bold leap and implement the yet-to-be-released Drupal 7? Ultimately, we chose to become early adopters, going with Drupal 7.  

    Here are the reasons that powered that decision:

    1) You stay in front of the technology wave

    While a good product at the time, there was no denying that Drupal 6 was closer to its end of lifecycle, while Drupal 7 was just taking off. We already understood the costs involved in supporting a legacy product. And we knew any extra investment early on would be offset by things like a longer lifecycle.

    As a side note, unlike previous versions of the platform, Drupal 8 releases will come out every six months. So if you plan to become an early adopter of Drupal 8, not only are you taking advantage of the latest and greatest today — but you will continually upgrade to the latest features over the lifecycle of the product.

    2) You differentiate yourself from the competitors

    At Examiner, we wanted to set ourselves apart from the competition and we knew D7 would give us that edge. AOL was starting to invest in Patch at that time. And we felt that if we wanted to grow our audience and draw the best journalism to our site, we needed best-in-breed tools.  

    3) You can attract the top talent

    Great developers want to be on the cutting edge. Who wouldn’t want to jump on an opportunity to work full-time on their passion and be able to contribute back to Drupal? When we brought in a great platform at Examiner, we attracted the best Drupal developers in the world. Very quickly, we hired 15 of the top 50 developers in the Drupal community.  

    4) You have the opportunity to shape your investment

    Getting in on Drupal 7 earlier put us in the driver’s seat with the technology. That was important. We weren’t looking to adopt just any set of tools. We wanted an opportunity to shape the next generation of a platform. And we knew Drupal was going to meet our needs better than anything else out there. Plus, it’s a lot less risky than building your own CMS, because you are not going it alone. You’re going in as part of a community.  

    5) It forces you to develop best practices

    Being an early adopter forces you to use best practices with respect to software development. At Examiner, we were able to participate in the community and contribute code to the platform. So for us, being an early adopter forced us to do things the right way — and that set a standard within the company moving forward.

    After a year of work, Examiner moved to a new platform built on Drupal 7. Thanks to Drupal 7, Examiner went from not being able to meet the needs of its users to exceeding them. We were able to deliver new features on a faster cadence. We had the best-in-breed platform, the easiest to use interfaces, and ultimately those features accelerated the growth of the company.

    Examiner launched on Drupal 7 six months before the official release of the platform. We started developing on it almost a year and a half before the release. So we were really early adopters. Examiner faced tremendous risks, because at that time, Drupal 7 was nowhere near as put together as Drupal 8 is today, but we still decided to do it — and it paid off.  Today, Examiner is a top 60 website.

    Being an early adopter is definitely an investment. It will cost more to be an early adopter of Drupal 8, but as Examiner has demonstrated, those costs are set off by several factors. And if you are concerned about the risks, keep this in mind: more than 400 sites are already running Drupal 8. And Acquia has already announced we are ready to support anyone with Drupal 8.

    What are your thoughts? Do you have any experiences on being an early adopter of Drupal 7? And how do you feel about the risks/benefits of being an early adopter for Drupal 8? We’d love to hear back from you and get the conversation going.

    Aug 20 2015
    Aug 20

    When Acquia’s Global Support Team outgrew their ticketing system in 2013, it was time to make a change. An outdated ticketing system was taxing their team and compromising their ability to support customers. In addition to lacking the core functionality required to meet increasing customer expectations, the third-party vendor lacked visibility and integration with existing systems like JIRA and Toggl, reporting was slow, and SLA was waning.

    The Global Support Team decided to look for a new, flexible API that would deliver tight integration with existing systems and generate responsive channels for quick, direct and clear communications. Reporting needed to be real-time and fast, and the customer and agent UX needed to be streamlined. Acquia needed a new system.

    In Walks Zendesk

    After systematic vendor vetting, Acquia’s Global Support Team quickly determined that Zendesk’s documented API provided the flexibility needed to do things the Acquian way. Zendesk is a customer service platform that provides the ideal framework for an enterprise environment. Zendesk offers an out-of-the-box solution, which provides a front-end customer interface and a back-end agent UX. Instead of just “drinking their own champagne,” Acquia decided to split a bottle with Zendesk’s REST API and develop the front-end of their Acquia Help Center in Drupal.

    Drupal-Zendesk Integration

    With a Drupal-Zendesk solution, Acquia built a powerful ticket request system that provides unparalleled support to their customers and internal teams. Here are five ways Acquia’s Support team leveraged a third-party API to build a new ticketing system.

    1. Using Zendesk’s API to create customer requests in Acquia’s Help Center on Drupal

    Acquia needed to migrate nearly 100k pre-existing tickets into Zendesk. This kind of overhaul required some reconciliation. Reorganization consisted of deleting completed tickets, cleaning up the open ticket queue, and configuring data into Zendesk.

    The new Acquia Help Center was built using Zendesk’s REST API in Drupal, providing a Customer UX that is easy to navigate. The Agent UX, utilized internally by the support team, is outfitted with all of Zendesk’s built-in functionality. Zendesk also offered Acquia’s Global Support Team the ability to customize their apps to guarantee top performance.

    customer UX create ticket .png

    2. Additional Info Block Application

    The flexibility of the Zendesk Apps Framework allows companies to extend the capabilities of the framework to leverage tickets, users and knowledgebases. Acquia customized their solution with an Additional Info Block Application, embedded in the Agent UX. The info block provides a global and integrated view of the customer.

    info block 2.png

    The info box displays information such as the product the customer is using, the number of application support tickets their subscription enables them to register, what networks they are connected to, special handling notes and their account management team.

    “This heightened customer visibility allows diverse members of Acquia’s Global Support Team to best support the customer’, says Jeannie Finks, Director of Global Support Systems and Programs at Acquia. “This supplementary ticket data is a necessity for our team to provide customers with the personalized assistance they need and now expect”.

    3. Time Tracking App

    By leveraging the flexibility of the Zendesk Apps Framework, Acquia was able to aggregate all of their systems in one place. Existing systems like JIRA and Toggl are essential to Acquia’s workflow, and needed to remain accessible in the Agent UX. Toggl is a time tracking app that allows you to sync your entries in real time. Toggl’s cloud based framework is Acquia’s default time tracking interface. Acquia’s custom Toggl-Zendesk app pushes ticket time to a central repo of daily agent activity:

    toggle time tracker.png

    Additionally, Zendesk’s partnership has enhanced the view of the customers through expert reporting. The Zendesk toolkit allowed Acquia to track tickets rolled in by account, customer backlog, and a root cause report. The introduction of expert reporting offers support teams a comprehensive overview of the customer. Real-time reporting provides Acquia’s Support Leadership with the resources needed to proactively identify critical issues and solve them quickly. This Info Block increases customer visibility, allowing Acquia to see what their customer needs, right when they need it.

    4. Custom SLA Monitoring and Notification within Zendesk

    The ticketing system also monitors the status of tickets based on a customer’s Service Level Agreement. Acquia continues to take advantage of Zendesk’s flexibility by configuring SLA data from a central customer data warehouse. This customization generates alerts that flow into all key communication channels, such as mail and chat. This custom monitoring system notifies teams when SLA expiration time is appended to a ticket, providing support teams with the visibility needed to best assist the customer.

    SLA .png
     

    5. JIRA and Zendesk Linked Tickets

    In addition to Toggl, JIRA is a ticketing system that Acquia’s Global Support Team utilized internally. It was a workflow necessity to have continued access to JIRA, and Zendesk’s robust API enabled Acquia to do so. Acquia further customized their API with a mini app that linked tickets filed in JIRA and Zendesk.

    The system scans Zendesk ticket comments, subject, and internal URL fields. After scanning, it will match any Acquia JIRA project keys. The system will then display the JIRA key, subject, status, time created, updated time, reporter and assignee. Comment links can also be added to any JIRA ticket.

    “The benefit of these customized applications is that all of Acquia’s support systems are connected in one place”, says Finks. “The convenience of having JIRA, Toggl and a customer info block in the Agent UX relieves the major pain points that were taxing our internal teams. Through our integration with Zendesk, Acquia’s Help Center is able to offer unparalleled global support to customers 24/7”.

    The next installment of our series will examine best practices when integrating with a third-party API.

    Aug 18 2015
    Aug 18

    No one likes fuzzy math. It’s especially problematic when you’re conducting a load test and can’t accurately gauge concurrency.

    In this last blog of a series on load testing, here are some tips on how to avoid the fuzzy math that can distort your expectations of how a website will perform.

    Shaky math can happen when using Apache JMeter, which is the most commonly used application to load test the performance of an open source site.

    JMeter breaks it down into three categories: the number of threads that are happening at once, the ramp-up period from zero requests at a time to the max number, and the number of iterations. This typically is the way to determine expected concurrency: the total number of requests divided by average response times over how long you test.

    There’s a problem with this method, though. When a site becomes overwhelmed, the response time actually increases, which means concurrency drops. So with such a test, you’re actually simulating the exact opposite of a normal site and not even close to seeing probable concurrency.

    But there is a proper way to solve this, a way to get a true glimpse of possible concurrency – it’s something called throughput shaping. You can find it on jmeter-plugins.org. With this tool, you only have to simply say, “I want a thousand requests at once,” and it’s not only accurate but will save time that’s ordinarily lost on JMeter as you first try to figure out things like how many requests will hit your site at once.

    Another speed bump to consider is how difficult it’s becoming to properly determine how many requests hit your site. That’s because not every every bot and not all of the “noise” on the Web crosses the path of Google Analytics and Omniture. Likewise, looking at the number of requests to your Web servers on Acquia Cloud, for example, doesn’t take into account if you’re using a CDM. (But if you are using a CDM, that’s the most likely source where you’ll have an accurate number.)

    So here’s the last lesson of this series: Don’t extrapolate results. If you’re testing with 150 connections, don’t assume 300 will be exactly twice the number of resources required. Your test will tell you what 150 did. Load testing should be conducted in an environment that’s exactly the same size as what your production environment will be. Sure, it will cost a bit, but it will tell you how things will actually behave.

    If your site faces contention – when many visitors simultaneously compete for your application’s attention – it will perform the exact same way if you have 150, 300 or even 600 connections. But the point is, you don’t actually know that; extrapolating results won’t provide an accurate number. Most often people look at the numbers, testing exactly to the numbers they have today. They’re missing more than just surges.

    Consider must-visit websites for special events like sporting events and live award shows. They have one or two huge days of traffic a year, but the rest of the year, they’ll have a totally different number of visitors. So, when load testing, it’s not just a matter of looking at numbers. It’s understanding what those numbers actually mean and recognizing your end goal.

    I recommend that once you have numbers, always test about 50% above that. Not necessarily because you’ll see that kind of traffic at launch, but if the site’s successful and growing over time, it’s rare that you’ll take the time to go back and run more load tests. By initially testing well above what you’re expecting, you’ll have a buffer and won’t have to worry about how the site is going to behave six months from now.

    Hopefully this series has prompted you to think carefully about the nuances of load testing and will help as you prepare to launch a site. Load testing done right can help achieve optimal site performance. And, as I mentioned earlier in the series, your users define where load testing should take place, so you can’t go wrong. If you have any questions or suggestions, please drop a note in the comment box. Thanks for reading.

    Aug 17 2015
    Aug 17

    You probably learned about mitosis in high school science class and have since forgotten all about it. Mitosis is the scientific term for when chromosomes in a cell nucleus separate into two identical sets of chromosomes, each in its own nucleus.

    We performed our own type of mitosis when preparing the staff at Acquia for the release of Drupal 8. We divided, conquered and divided all over again – accelerating the pace of training that otherwise would have plodded along and drained internal resources.

    This is the third installment in a series on Drupal 8 instruction and it seems appropriate at this point to look at how our spin on mitosis not only helped us stay focused on the ordinary flow of business – employees needed anywhere from 10 to 80 hours of training, depending on their job duties – but also had people benefitting from the power of collaboration.

    As we started the training program, we had already read a lot of documents to prepare fro Drupal 8. But as helpful as they were, we knew nothing would beat the advantages gained from hands-on training. It also made sense to train in bite-sized fashion so no one would feel overwhelmed by learning the more than 200 new capabilities of Drupal 8 while also trying to stay on top of regular work.

    So we first paired four people into two groups and gave them – and me and my co-author Kent Gale – two months to port a module from to Drupal 7 to Drupal 8. Unfortunately, we didn’t have a thorough, consistent stream of documentation to lean on, so our pairs immediately went off in different directions. At that point, we changed tracks and reorganized groups: teaming one person who knew even a little bit about Drupal 8 with another who knew nothing about it. Right away, there was a constructive back and forth with each pair. Trainees did spend time reading materials on their own, but they clearly benefitted by working together. Between sharing a computer and spending a lot of time together, it became a lot easier for them – and us – to ask the right questions and solve problems.

    When that round ended, both members of each team understood Drupal 8, and each then paired with employees who needed instruction, again performing our version of mitosis. Four became eight; eight became 12. We eventually dropped the original four trainees and kept moving along, with a steady rate of 12 trainees. Twelve was the ideal rate of training we could support.

    Once we gained steam, we recognized each training session had to last three months rather than two so we could provide 40 hours of instruction to our higher level people, the “code makers” and “fixers.” Three months enabled us to handle vacations and sick days, and gave us a firm idea of the speed we needed to maintain when training.

    It goes without saying that when your outfit starts planning training, it’s crucial to determine how quickly you can do it. Only when managers and teams collaborate will you be able to truly learn what can be done.

    Aug 17 2015
    Aug 17

    If you’re already working with Drupal 8 (no excuse, now that it's supported on the Acquia Platform), you're probably still exploring what it can do. There are more than 200 new features, so it may take a while. 

    But since this is a series about load testing, let's narrow our focus to what Drupal 8 does during load tests. 

    You probably know that Drupal can be used as a back-end framework for managing content such text, media, and geospatial data, while AngularJS and ReactJS can be used as the front-end from a JavaScript perspective. Drupal 7 can do this, but it’s a lot easier with Drupal 8.

    When load testing, the biggest difference between the versions is that with Drupal 7, you’re expecting pages that come back to HTML as something a Web browser can understand. In Drupal 8, what comes back will be something like JSON or XML, something that a Web browser doesn’t care about as much. Now, this won’t change the performance aspect of a load test, but it will be interesting to see how people adapt to these different patterns as they write tests.

    Enhanced caching is another big advancement of Drupal 8. From its first iteration to the seventh version, Drupal was geared out of the box for developers, so nothing was cached. When you were developing a new site or module, everything you did was shown immediately. With Drupal 8, out-of-the-box performance is a lot better, and page caching is great example of that improvement. In Drupal 7, page caching was disabled by default; in Drupal 8, it’s enabled by default. It’s one less thing you have to do by hand. That also means it should catch things that maybe you’ve forgotten about during development. It should catch things that Drupal 7 wouldn’t have caught.

    One other key difference is how Drupal 8 integrates with Symphony, and uses what are called service containers. This is the idea that, for example, on a multilingual website, Drupal 8’s service containers handle translation. These service containers can be changed at any time. If you change the language or various menu structures, these get rewritten to disc every time. So when this needs to be rebuilt, it’s one of those locking operations that may have an impact on how the site’s running. Now, it shouldn’t affect performance, but it’s one of the many things our support team has studied and will keep watching as part of Acquia’s review of all the changes in Drupal 8.

    Just like a huge and complex puzzle that we got for Christmas and have been assembling for some time now, we know almost everything Drupal 8 can do but we’re still learning little things here and there about how it differs from Drupal 7. The best we can do is continue to understand what these differences are, and know what to look for going ahead.

    Aug 14 2015
    Aug 14

    You might think that hiding the content management system (CMS) your site is running will make it difficult for attackers to identify your site as a target when new security vulnerabilities come to light. But it turns out that hiding Drupal doesn’t actually give you a leg up in the security game.  

    One reason: most attacks are executed by bots, which generally do not even check what CMS your site is running before attempting known security vulnerabilities.

    “Security through obscurity” won’t even deter human hackers looking to execute targeted attacks against your website. Anyone making the effort should be assumed to have the time and resources to find what you’ve hidden - or at least to bruteforce your site if that fails. Obscuring the vulnerabilities your site might have does nothing to address the vulnerabilities that are there.

    What if I want to hide it anyway – are there any downsides?

    Hiding that your site runs Drupal can actually make it harder to maintain real security. The changes you’d need to make to completely conceal Drupal are so extensive that they will break core. Security updates and patches will no longer be readily compatible with your altered version of Drupal, requiring time and extensive effort before they can be applied. The longer your website is without the latest security update, the longer known vulnerabilities exist in your code – ready to be exploited by bots searching for late adopters.

    I still want to hide Drupal. How can I do so?

    The Acquia Help Center provides detailed instructions for Hiding the fact that your site runs Drupal - with the caveat that the outlined steps take a significant amount of effort to implement and maintain, and probably aren’t worth your effort.

    Aug 14 2015
    Aug 14

    Timing is everything, as they say, and that’s especially true when trying to optimize website performance.

    Last time out in this series on load testing, I offered ways to prepare for site visitors of all stripes. This time, let’s flip to the other side: back-end operations. Surely, how you maintain and upgrade your site will have just as much sway on site performance as visitors will.

    Consider the saving of content. Does it affect performance? It does for many sites. For example, you’ll have sites for which load tests were run completely from the user’s perspective, but the first time these sites slide, the administrators will try to save a piece of content and hit a contention point. The cache is clear, but something strange has happened that wasn’t anticipated.

    At Acquia, we’ve also seen a revision of saved content behave differently than brand new content that was saved. So just remember to test all possible kinds of actions, and do so early in the game, before a site slides.

    Deployment can affect traffic, so you need to figure out the best time to schedule updates, changes and the like. Some of our large customers deploy only at night. Some customers deploy a dozen times a day. It depends on the job. Say you’re unveiling a brand new theme; then you’ll need to clear out all caches and should consider doing the job at a low traffic time. But if you’re only fixing a bug, then maybe you can send out a small code change and not worry about it affecting traffic. You just need to carefully consider ahead of time what could happen.

    If you schedule load tests for an hour or two, have a developer run a deployment, make some changes, save some content, see what happens, and perform the last background operations, basically anything that’s scheduled.

    We have a lot of customers who every hour, on the hour, will see glitches in performance. The biggest cause is all the background jobs they have running to sync content or connect to some external Web service. But because many of them setup monitoring early while running load tests, they’re able to see these spikes early.

    Keep that in mind next time you perform a load test: a service that tracks performance will help. New Relic is one I recommend. During a load test, it allows you to see not just how requests perform from the customer’s perspective, but also how the application is performing.

    Again, don’t wait. Take these steps before a launch so you can catch any problems.

    In the next blog post, we’ll look at how Drupal 8 makes page caching easier and other things you can expect from the new platform when load testing.

    Aug 04 2015
    Aug 04

    You wouldn’t believe how many load tests fail to look beyond the home page. Seriously, many load tests focus on the home page and a few popular landing pages, neglecting to check most, or if not all, of the pages.

    No, it’s not enough to replicate the visits of several thousand users in an hour for just one page and consider it a successful load test. With this blog – the fourth in a series about load testing – we’ll review the other user paths you should be considering before launching a website.

    The most common mistake made in load testing is focusing mostly on the homepage. The thought is, “That’s the page where all visitors start.” And during development, that’s often where everyone is looking during a load test. Make no mistake about it: the homepage is the one that will rarely have a problem.

    But you need to also look at all the other ways visitors enter a site. That’s where you see the tricks a site can play if not properly tested. For example, I once saw a retail site crashing on Black Friday, just about the worst time a customer-driven site can go down. The retailer had done a thorough load test of individual pages but hadn’t tested someone going to the public site and then jumping over to the store site. The home page was tested and pages were simply added on top of it. So you not only want to make sure you’re checking all the important pieces, but also that you understand how users are getting to your site and how they’re navigating around it.

    Your first step should be identifying what all the user paths are through a site. For example, it’s easy to follow the clicks of an average e-commerce visitor and thus test accordingly: user logs in, visits a product page, adds a product to a shopping cart, reviews cart contents and completes transaction. But consider testing something atypical: logged in as a new user, search for something out of the ordinary and then navigate to a random result.

    Logging in as a new user and creating a unique shopping cart is much more likely to catch problems than testing something more common. Try it next time you test. Randomize what’s actually in the load test. Granted, with certain tools that can be a bit difficult, but you need to make sure you’re not hitting the same product page, the same homepage, the same shopping cart – because that’s not what your actual users are going to do.

    Oh, and don’t forget to conduct the same searches if you’re using a system separate from your website. For instance, an Acquia search will work at a different pace than a Durpal site will. You want to make sure that anything your site depends on will behave the same way on the separate system. At Acquia, we sell dedicated search instances to ensure that heavy use of search on your site will scale. You can rest easy knowing all the components of your site are behaving as you’d expect.

    Next week, we’ll take a closer look at Web traffic. Until then, don’t forget to test as many pages in as many ways possible – and as different users. You’ll be grateful you did.

    Jul 29 2015
    Jul 29

    You’d hate to have your business struggle for critical resources such as skilled employees, Internet bandwidth, or even capital. The same is undoubtedly true for website performance.
     
    For developers, “contention” refers to when many website visitors are simultaneously competing for your application’s attention. In this blog – the third in a series about load testing – we’ll look at how you can try to catch a contention issue before it becomes a really big issue.
     
    The idea of contention is that there’s a single resource that every request depends on. No matter how many servers you add to your application, there will always be a point where it has to pause, complete some work, and then free up all of the requests.
     
    Contention is the hardest thing to catch in a load test, and probably the hardest thing to catch in Drupal, but it’s not impossible. With some diligence, you can stay on top of requests and not see your website’s performance suffer.
     
    Consider when your caches need to be rebuilt internally. Surely, it’s best to not have a thousand people simultaneously visit your site and all of those cache entries have to be rebuilt all at once. Drupal will rebuild the cache of the first request, while having all the other requests pause. If that operation takes a hundred milliseconds, every single visitor’s request will pause for that exact same amount of time. To counter that, you can add more servers and resources, but it won’t make much of a difference. In fact, you’ll see that like with a lot of website launches, developers will add more resources and sit back and enjoy the show, only to stress when the inevitable contention issue arrives.
     
    Now, contention issues are hard to track down, but it can be done. Thorough load testing can actually catch them by noticing arcs in results, indicating that response times suffer then recover in a short amount of time. This time to recover estimates the cost of relieving this contention. It all boils down to understanding the code, recognizing when contention happens and knowing when you can prevent it.
     
    But don’t wait for that moment. If you’re conducting a load test, plug away and find the painful points of contention. You’ll thank yourself later.

    Jul 22 2015
    Jul 22

    When Drupal comes out of the box, it's configured for ease of development – not performance. But making the application production-ready should indeed start with checking settings on the Performance page. The settings here let you control caching behavior and optimize bandwidth. If anything, it’s a simple reminder to distinguish development settings from test and production settings to get the best results in each environment.

    This blog post, the last installment of a series that reviewed ways to improve Drupal website performance, offers some easy steps you can take to better your site.

    Controlling Your Caching

    An option on the Performance page turns on caching for anonymous users and for blocks. If block caching is turned on, even logged-in users will benefit. Unfortunately, this won’t happen if content access modules limit users to specific content. If the application includes modules that implement node grants, the block caching feature will be disabled.

    It’s also useful if you have content cached on a reverse proxy, like what is leveraged within Acquia Cloud. The "Expiration of Cached Content" setting tells the proxy how long to hold onto the page before requesting the latest version.

    Optimize your modules

    Don't forget the settings for individual modules. Depending on what you've loaded, you may have the ability to configure caching behavior in the admin user interface. Some modules have an admin interface that isn't needed in production, and you may be able to disable it to avoid the overhead.

    Reduce your requests

    Reducing the number of network requests and the size of files sent improves performance. Most Drupal sites have a few dozen CSS and JavaScript files. If these are compressed and sent in a single download, the number of requests needed and the size of the transmitted data are reduced.

    Configure your "Page Not Found" response

    You'd think a missing page would get a fast response, but by default, Drupal needs to perform a complete bootstrap to confirm the page doesn't exist. Fast 404 short-circuits this process and sends an error response immediately. Configure it by specifying the paths and file types that should send the error response.

    Tune your database

    The database is often the hardest place to optimize, but it's usually where the biggest bottlenecks occur. Eliminating unnecessary writes to the DB can lead to big gains in performance. By default, Drupal's Database module logs every event in the database. Instead, limit unnecessary log entries and use the Syslog module, which instead writes to the operating system's logs. Switching the logging destination is simple, doesn't really lose anything, and can significantly improve performance.

    Keep an eye on your system

    Performance tuning isn't a one-and-done process. As applications and users change over time, the performance they experience also changes. At Acquia, we use tools like Acquia Insight and New Relic to monitor sites and get suggestions for fixes. Acquia also has a Logstreaming tool that lets us see, live, what's going on with the site. Reacting to this information helps us understand how the site is working and recognize where additional changes are needed.

    I hope you enjoyed this series. If you have any questions or suggestions, please leave a comment below.

    Jul 14 2015
    Jul 14

    Drupal has modules for just about everything, including improving site performance. You can use these modules to see what's going on with a site and figure out the changes needed to increase Drupal's speed. As part of an ongoing series about ways to improve Drupal website performance, let’s take a closer look at the modules that can make your life a lot easier.

    Find the Bottlenecks: Devel

    Before trying to improve a Drupal site's performance, it's important to know where the bottlenecks are in order to avoid making random changes. The Devel module provides sharp insight by showing information such as how many queries ran to build a page, how long execution took, and how much memory was used. This information is especially helpful for assessing the impact of changes such as installing and disabling modules. Even if you don't understand all the detailed information the Devel module provides, seeing trends in the numbers will, over time, be useful.

    Improve Caching: Entity Cache, Views Content Cache, Panels Hash Cache, and Panels Content Cache

    Changing Drupal caching behavior can have a big impact on performance. When applications have a large amount of entity data (information on things like users and content), using Entity Cache can lead to large performance gains with almost no configuration. It's less useful if there's only a small amount of entity data.

    To control other cache settings, Block Cache Alter lets settings for each block be configured individually. This allows for more fine-grained control than the settings on the Performance page.

    Another change that can improve performance is using a cache based on content-driven expiration, rather than discarding cached data after a specified amount of time passes. The Views Content Cache, Panels Hash Cache, and Panels Content Cache modules provide this functionality.

    Improve Database Usage: Views Litepager and Memcached

    For sites that use the recommended InnoDB MySQL storage engine, Views Litepager speeds up the creation of pages for views. Rather than creating links to every single page, it provides just “next” and “previous” links. It's incredibly simple and beneficial. The drawback is that site visitors can move only one page at a time through a long list.

    Another great addition is Memcache, which lets you integrate Drupal with Memcached, a free and open source, high-performance, distributed memory object caching system that is available on Acquia Cloud. The combination lets Drupal use the database only for large, heavy content, and caches other information elsewhere. To get the best performance from Drupal, it's really important to move as much work – caching and logging – off the database so it can focus on providing the content.

    Standard Tools for Performance

    There's so much benefit from some of these modules that they're practically standard at many companies, including here at Acquia. Almost everyone uses Devel. Acquia uses Memcache in its cloud platform.

    But every organization is different, so find the tools and configuration settings that work for your needs and make them standard across all your development projects. That'll free up time for developing instead of tuning performance.

    Jul 09 2015
    Jul 09

    In the last installment of this series, we considered CSS optimization. This time we’re going to look at the impact of scripts.

    Remember, as architects and developers, it’s up to us to inform stakeholders about the impacts of their choices, offer compromises where we can, and implement in smart and responsible ways.

    So, picking up on our last post, most everything about the way Drupal handles CSS holds true for JavaScript, with a few notable exceptions.

    CSS aggregation removes whitespace, but JavaScript aggregation done using Drupal core's aggregation system doesn't do that or any other form of minification or uglification. It simply concatenates our scripts.

    Like CSS, JavaScript also has three groups:

    • Library - Libraries, via drupal_add_library
    • Default - Modules
    • Themes - Your theme

    Drupal creates aggregates for each of these three groups in the head, but can also deploy to the footer when the scope is set to ‘footer.’

    When and where to load your JS

    Drupal_add_js features a great option in the options array called scope that allows us to load JavaScript in the footer. This helps decrease our visual page load times by moving render-blocking JavaScript out of the way to a place where it won't impede the loading of other assets (like images, styles, other scripts).

    The options array also provides an option called type which defaults to ‘file.’ When using the default option of ‘file,’ it tells Drupal that this is a script hosted on our site, so it's eligible to be aggregated. Combined with the every_page flag set to ‘true,’ just like with our CSS, these scripts get aggregated with the scripts added using ‘.info’ files into the big site-wide aggregates. If the every_page option is left out, or it is set to ‘false,’ then these scripts are aggregated as one-offs outside of our main three site-wide JavaScript aggregate files, again, just like with our CSS.

    The type option can also be used to create inline scripts, which can be handy in a couple of ways. It will print our JavaScript directly into our header or footer depending on scope, but it's also useful for dynamically loading external scripts so they become asynchronous. Going forward, the async_js module is probably the way to go. I personally haven't had the opportunity to try it out, but I look forward to the chance. If you've used it, let us know in the comments how it worked out for you.

    The third 'type' is the one we use for loading external scripts, which we seem to do often these days. Using an asynchronous method, mentioned above, is important because of the additional round-trip time to get the script. However, a slightly less effective way to handle it without using the older method of an inline script, or an additional module, is simply scoping the script to the footer and setting the type option to external (which prevents it from being aggregated).

    Unlike with CSS, I'm less inclined to add JavaScript on every page because I like to scope JavaScript to the footer whenever possible. Since it isn't blocking render down there, the additional HTTP request doesn't really bother me. Generally, if it's on most pages, or a page visited by most users, go ahead and add it to every page. If it isn't and it's scoped to the footer, then only add it when it is needed. If it has to be in the header, and on an obscure page that isn't frequently visited by users, you're probably going to need to do some A/B testing to compare the performance hit on the obscure page by not including it on all pages vs. the performance hit on all the other pages by including it on all pages. I like to err on the side of the majority, meaning, I tend to only include the JavaScript on the obscure pages.

    JavaScript: Know when to say when

    You can do almost anything with JavaScript, and leveraging a framework like jQuery makes it easier to want to do everything with JavaScript. However, in addition to blocking page render and increasing the size of the page that has to be processed by the browser, there are other performance considerations with JavaScript.

    It runs locally, in the browser, which means it uses a visitor's memory and processor. Poorly written or heavy use of JavaScript can lead to a poor user experience in the form of everything from delayed and choppy animations to browsers becoming unresponsive and/or crashing. For simple animations, consider using CSS3 animations, benchmark them using a tool like Chrome's dev tools or Firebug, and go with the least expensive performance option (these usually end up being the smoothest animations as well).

    These script performance problems are often magnified on mobile devices where the hardware resources are more scarce and we often resort to using more JavaScript to solve challenges presented by the smaller viewport. This should reinforce the importance of a mobile first strategy, not only for design but also for development. It also highlights the need for open communication between the product owners, the design team, and the development team.

    Conclusion

    Scripts, like styles, contribute front-end implementations that can seriously hamper Drupal’s back-end magic. By favoring stylesheet aggregation and reigning in exuberant preprocessing, we can save the browser a lot of work. Applying the same principles to JavaScript, while properly placing scripts in the header or footer-based on function, can also improve our page-load times.

    Next time, in our final post of the series, we’ll take a grab-bag look at some subtle, more specialized techniques that just might shave off those last few milliseconds. Stay tuned for a post covering Content Delivery Networks (CDN), semantic HTML, and how to encourage improved client-side content selection.

    Pages

    About Drupal Sun

    Drupal Sun is an Evolving Web project. It allows you to:

    • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
    • Facet based on tags, author, or feed
    • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
    • View the entire article text inline, or in the context of the site where it was created

    See the blog post at Evolving Web

    Evolving Web