Caching to Improve Drupal Performance: The Three Levels You Should Know

June 30, 2015 at 4:07pm

image that illustrates how caching to improve drupal performance

In our continuing mission (well, not a mission; it’s actually a blog series) to help you improve your Drupal website, let’s look at the power of caching.

In our previous post, we debunked some too common Drupal performance advice. This time we're going positive, with a simple, rock-solid strategy to get you started: caching is the single best way to improve Drupal performance without having to fiddle with code.

At the basic level, it is easy enough for a non-technical user to implement. Advanced caching techniques might require some coding experience, but for most users, basic caching alone will bring about drastic performance improvements.

Caching in Drupal happens at three separate levels: application, component, and page. Let’s review each level in detail.

Application-level caching

This is the caching capability baked right into Drupal. You won't see it in action unless you dig deep into Drupal's internal code. It is enabled by default and won't ever show older, cached pages.

With application-level caching, Drupal essentially stores cached pages separately from the site content (which goes into the database). You can't really configure this, except for telling Drupal where to save cached pages explicitly. You might see improved performance if you use Memcached on cached pages, but the effect is not big enough to warrant the effort.

Drupal stores many of its internal data and structures in efficient ways to improve frequent access when application-level caching. This isn’t information that a site visitor will see per se, but it is critical for constructing any page. Basically, the only enhancements that can be made at this level are improving where this cached information is stored, like using Memcached instead of the database.

You just need to install Drupal and let the software take care of caching at the application-level.

Component-level caching

This works on user-facing components such as blocks, panels, and views. For example, you might have a website with constantly changing content but a single block remains the same. In fact, you may have the same block spread across dozens of pages. Caching it can result in big performance improvements.

Component-level caching is usually disabled by default, though you can turn it on with some simple configuration changes. For the best results, identify blocks, panels, and views that remain the same across your site, and then cache them aggressively. You will see strong speedups for authenticated users.

Page-level caching

This is exactly what it sounds like: The entire page is cached, stored and delivered to a user. This is the most efficient type of caching. Instead of generating pages dynamically with Drupal bootstrap, your server can show static HTML pages to users instead. Site performance will improve almost immeasurably.

Page-level caching gives you a lot of room to customize. You can use any number of caching servers, including Varnish, which we use at Acquia Cloud. You can also use CDNs like Akamai, Fastly, or CloudFlare to deliver cached pages from servers close to the user's location. With CDNs, you are literally bringing your site closer to your users.

Keep in mind that forced, page-level caching works only for anonymous users by default. Fortunately, this forms the bulk of traffic to any website.

It bears repeating: Caching should be your top priority for boosting Drupal performance. By identifying and caching commonly repeated components and using a CDN at page-level, you’ll see site speed improvements that you can write home about.

Next time: How to Evaluate Drupal Modules for Performance Optimization.

Tags:  acquia drupal planet
Categories: Planet Drupal

Seamless Migration to Drupal 8: Make it Yours

June 30, 2015 at 3:26pm

wildebeests migrating

Hi there. I’m Adam from Acquia. And I want YOU to adopt Drupal 8!

I’ve been working on this for months. Last year, as an Acquia intern, I wrote the Drupal Module Upgrader to help people upgrade their code from Drupal 7 (D7) to Drupal 8 (D8). And now, again as an Acquia intern, I’m working to provide Drupal core with a robust migration path for your content and configuration from D6 and D7 to Drupal 8. I’m a full-service intern!

The good news is that Drupal core already includes the migration path from D6 to D8. The bad news is that the (arguably more important) migration path from D7 to D8 is quite incomplete, and Drupal 8 inches closer with each passing day. That’s why I want -- nay, need -- your help.

We need to get this upgrade path done.

If you want core commits with your name on them (and why wouldn’t you?), this a great way to get some, regardless of your experience level. Noob, greybeard, or somewhere in between, there is a way for you to help. (Besides, the greybeards are busy fixing critical issues.)

What’s this about?

Have you ever tried to make major changes to a Drupal site using update.php and a few update_N hooks? If you haven’t, consider yourself lucky; it’s a rapid descent into hell. Update hooks are hard to test, and any number of things can go wrong while running them. They’re not adaptable or flexible. There’s no configurability -- you just run update.php and hope for the best. And if you’ve got an enormous site with hundreds of thousands of nodes or users, you’ll be staring anxiously at that progress bar all night. So if the idea of upgrading an entire Drupal site in a single function terrifies you, congratulations: you’re sane.

No, when it comes to upgrading a full Drupal site, hook_update_N() is the wrong tool for the job. It’s only meant for making relatively minor modifications to the database. Greater complexity demands something a lot more powerful.

The Migrate API is that something. This well-known contrib module has everything you need to perform complex migrations. It can migrate content from virtually anything (WordPress, XML, CSV, or even a Drupal site) into Drupal. It’s flexible. It’s extensible. And it’s in Drupal 8 core. Okay, not quite -- the API layer has been ported into core, but the UI and extras provided by the Drupal 7 Migrate module are in a (currently sandboxed) contrib module called Migrate Plus.

Also in core is a new module called Migrate Drupal, which uses the Migrate API to provide upgrade paths from Drupal 6 and 7. This is the module that new Drupal 8 users will use to move their old content and configuration into Drupal 8.

At the time of this writing, Migrate Drupal contains a migration path for Drupal 6 to Drupal 8, and it’s robust and solid thanks to the hard work of many contributors. It was built before the Drupal 7 migration path because Drupal 6 security support will be dropped not long after Drupal 8 is released. It covers just about all bases -- it migrates your content into Drupal 8, along with your CCK fields (and their values). It also migrates your site’s configuration into Drupal 8, right down to configuration variables, field widget and formatter settings, and many other useful tidbits that together comprise a complete Drupal 6 site.

Here’s a (rather old) demo video by @benjy, one of the main developers of the Drupal 6 migration path:

Awesome, yes? I think so. Which brings me to what Migrate Drupal doesn’t yet have -- a complete upgrade path from Drupal 7 to Drupal 8. We’re absolutely going to need one. It’s critical if we’re going to get people onto Drupal 8!

This is where you come in. The Drupal 7 migration path is one of the best places to contribute to Drupal core, even at this late stage of the game. The D7 upgrade path has been mapped out in a meta-issue on drupal.org, and a large chunk of it is appropriate for novice contributors!

Working on the Migrate API involves writing migrations, which are YAML files (if you’re not familiar with YAML, the smart money says that you will pick it up in, honestly, thirty seconds flat). You’ll also write automated tests, and maybe a plugin or two -- a crucial skill when it comes to programming Drupal 8! If you’re a developer, contributing migrations is a gentle, very useful way to prepare for D8.

A very, very quick overview of how this works

Migrations are a lot simpler than they look. A migration is a piece of configuration, like a View or a site slogan. It lives in a YAML file.

Migrations have three parts: the source plugin, the processing pipeline, and the destination plugin. The source plugin is responsible for reading rows from some source, like a Drupal 7 database or a CSV file. The processing pipeline defines how each field in each row will be massaged, tweaked, and transformed into a value that is appropriate for the destination. Then the destination plugin takes the processed row and saves it somewhere -- for example, as a node or a user.

There’s more to it, of course, but that’s the gist. All migrations follow this source-process-destination flow.


id: d6_url_alias
label: Drupal 6 URL aliases
migration_tags:
  - Drupal 6

# The source plugin is an object which will read the Drupal 6
# database directly and return an iterator over the rows of the
# {url_alias} table.
source:
  plugin: d6_url_alias

# Define how each field in the source row is mapped into the destination.
# Each field can go through a “pipeline”, which is just a chain of plugins
# that transform the original value into the destination value, one step at
# a time. Source values can go through any number of transformations
# before being added to the destination row. In this case, there are no
# transformations -- it's just direct mapping.
process:
  source: src
  alias: dst
  langcode: language

# The destination row will be saved by the url_alias destination plugin, which
# knows how to create URL aliases. There are many other destination plugins,
# including ones to create content entities (nodes, users, terms, etc.) and
# configuration (fields, display settings, etc.)
destination:
  plugin: url_alias

# Migrations can depend on specific modules, configuration entities, or even
# other migrations. 
dependencies:
  module:
    - migrate_drupal
I <3 this, how can I help?

The first thing to look at is the Drupal 7 meta-issue. It divvies up the Drupal 7 upgrade path by module, and divides them further by priority. The low-priority ones are reasonably easy, so if you’re new, you should grab one of those and start hacking on it. (Hint: migrating variables to configuration is the easiest kind of migration to write, and there are plenty of examples.) The core Migrate API is well-documented too.

If you need help, we’ve got a dedicated IRC channel (#drupal-migrate). I’m phenaproxima, and I’m one of several nice people who will be happy to help you with any questions you’ve got.

If you’re not a developer, you can still contribute. Do you have a Drupal 6 site? Migrate it to Drupal 8, and see what happens! Then tell us how it went, and include any unexpected weirdness so we can bust bugs. As the Drupal 7 upgrade path shapes up, you can do the same thing on your Drupal 7 site.

If you want to learn about meatier, more complicated issues, the core Migrate team meets every week in a Google Hangout-on-air, to talk about larger problems and overarching goals. But if you’d rather focus on simpler things, don’t worry about it. :)

And with that, my fellow Drupalist(a)s, I invite you to step up to the plate. Drupal 8 is an amazing release, and everyone deserves it. Let’s make its adoption widespread. Upgrading has always been one of the major barriers to adopting a new version of Drupal, but the door is open for us to fix that for good. I know you can help.

Besides, core commits look really good with your name tattooed on ‘em. Join us!

Tags:  acquia drupal planet
Categories: Planet Drupal

From consumption to contribution - Drupal business in India, Part 2

June 26, 2015 at 3:46pm
Language Undefined

Ani Gupta, Drupal Mumbai community lead, StartupNext lead, formerly at Axelerant in India, and I got the chance to continue the conversation I began with Piyush Poddar at Drupal Camp London about the changing face of IT and open source in India. Under the heading "from consumption to contribution" we talk about India's move from being perceived as being good for cheap, outsourced code to being a place rich with brands and startups in their own right and the home to much open source contribution. We also talk about old versions of Drupal, the Drupal community and its mentoring culture, open source acceptance in business and government, and more!

Categories: Planet Drupal

Drupal: Helping NGOs & Civil Society in Myanmar and beyond

June 19, 2015 at 2:11pm
Language Undefined

When Tom Feichter told me he only gets to one Drupal event a year, I wanted to know why. When he told me it's because he runs a Drupal shop–mspiral creative media–in Yangon, Myanmar, I had to know more! We talked about Tom's history in Drupal, how Drupal's multilingual capabilities have helped him, how excited he is about Drupal 8's architecture, his history working with NGOs on the Thai/Burmese border and how that has flowed into ethical digital agency work, and more.

Categories: Planet Drupal

How Weather.com Improved Their Page Load Times

June 18, 2015 at 5:07pm

migrating weather.com to drupal

In November, 2014 Weather.com launched on Drupal and became one of the highest trafficked websites in the world to launch on an open-source content management system (CMS). Mediacurrent and Acquia are excited to announce a new, 3-part blog post series that will share insight around how Weather.com was migrated to Drupal. Our team of experts will share best practices and what lessons we learned during the project.

There's an old saying, “Everyone talks about the weather, but nobody does anything about it.” While we are a long way from controlling the weather, Weather.com has done a spectacular job of delivering accurate weather news, as rapidly as possible, to all kinds of devices.

This is a small miracle, especially when you consider Weather.com served up a billion requests during its busiest week. Even slow weeks require delivering hundreds of dynamic maps and streaming video to at least 30 million unique users in over three million forecast locations. The site has to remain stable with instantaneous page loads and 100 percent uptime, despite traffic bumps of up to 300 percent during bad weather.

Page load times are the key to their business and their growth. When The Weather Channel's legacy CMS showed signs of strain, they came to Drupal.

On their legacy platform, Weather.com was tethered to a 50 percent cache efficiency. Their app servers were taking on far too much of the work. The legacy platform ran on 144 origin servers across three data centers. It takes all that muscle to keep up with the number of changes that are constantly happening across the site.

Traditionally, when you have a highly trafficked site, you put a content delivery network (CDN) in front of it and call it a day. The very first time a page is requested, the CDN fetches it from the origin server and then caches it to serve to all future requestors.

Unfortunately, it doesn't work that way for a site like Weather.com.

Consider this: If a user in Austin visits a forecast page, they see a certain version of that page. A visitor from Houston sees a slightly different version of that page. Not only are there two different versions of the page, one for each location, but much of the information on the page is only valid for about five minutes.

At the scale of three million locations, that's a lot of pages that have to rebuild on an ongoing basis only to be cached for 5 minutes each. Couple this with the fact that the number of served locations kept increasing as developers worked on the site, and you can see that things are rapidly getting out of control.

The first thing we did was break up the page into pieces that have longer or shorter life spans based on the time-sensitivity of the content. That allowed us to identify the parts of the pages that were able to live longest and that we could serve to the majority of users. The parts that varied, we no longer change on the origin servers, but instead delegate to systems closer to the user where they actually vary.

To accomplish that trick, we switched to a service-oriented architecture and client side rendering, using Angular.js, ESI (Edge Side Includes), and some Drupal magic. The combination of these three components boosted cache efficiency, page performance, and reduced the required number of servers to deliver it.

The result? After launch, we showed Weather.com a 90 percent cache efficiency. In other words, in going from 50 to 90% cache efficiency they reduced the number of hits to the origin servers, which means that you need fewer of them. Post launch, we were able to increase cache efficiency even further.

This cache efficiency was also measured only at the edge. Varnish (a caching proxy) further reduced the amount of traffic, meaning that Drupal itself and the Varnish stack were serving less than 4 percent of their requested traffic. The benefits of the service-oriented architecture also mean that scaling is simpler, architectural changes are less painful, and the end user can experience a richer user experience.

Doing something about the weather is still way out on the horizon, but Weather.com can certainly claim that it has improved the delivery of weather news.

Tags:  acquia drupal planet
Categories: Planet Drupal

Build Your Drupal 8 Team: The Forrester Digital Maturity Model

June 15, 2015 at 2:46pm

In business, technology is a means to an end, and using it effectively to achieve that end requires planning and strategy.

The Capability Maturity Model, designed for assessing the formality of a software development process, was initially described back in 1989. The Forrester Digital Maturity Model is one of several models that update the CMM for modern software development in the age of e-commerce and mobile development, when digital capability isn't an add-on but rather is fundamental to business success. The model emphasizes communicating strategy while putting management and control processes into place.

Organizations that are further along within the maturity model are more likely to repeatedly achieve successful completion of their projects.

Let's take a look at the stages of this model, as the final post in our Build Your Drupal 8 Team series.

Here are the four stages:

Stage 1 is ad hoc development. When companies begin e-commerce development, there is no defined strategy, and the companies' products are not integrated with other systems. Most products are released in isolation and managed independently.

Stage 2 organizations follow a defined process model. The company is still reactive and managing projects individually, but the desired digital strategy has been identified.

Stage 3 is when the digital strategy and implementation is managed. An overall environment supportive for web and e-commerce development exists, and products are created within the context of that environment.

In Stage 4, the digital business needs are integrated. Products aren't defined in isolation, but rather are part of an overall strategic approach to online business. The company has a process for planning and developing the products and is focused on both deployment and ongoing support.

The final capability level, Stage 5, is when digital development is optimized. Cross-channel products are developed and do more than integrate: they are optimized for performance. The company is able to focus on optimizing the development team as well, with continuous improvement and agile development providing a competitive advantage.

Understanding where your company currently finds itself on the maturity scale can help you plan how you will integrate and adapt the new functionality of Drupal 8 into your development organization.

If you are an ad hoc development shop, adopting Drupal 8 and achieving its benefits may be very challenging for you. You may need to work with your team to move up at least one maturity level before you try to bring in the new technology.

In contrast, if your team is at stage 5, you can work on understanding how Drupal 8 will benefit not just your specific upcoming project, but also everything else that is going on within your organization.

Resources:

  • A comprehensive SlideShare presentation on Digital Maturity Models.
  • A blog post by Forrester's Martin Gill that mentions the Digital Maturity Model in the context of digital acceleration.
Tags:  acquia drupal planet
Categories: Planet Drupal

Migrating Content to Drupal: The Weather Channel

June 11, 2015 at 1:31pm

migrating drupal content truck

One of the major challenges facing every digital publisher is making sure its content will display properly up on every possible venue: desktop, tablet, and phone of course, but also in web services, and on the emerging display opportunities arriving with the Internet of Things, like wearables.

Acquia partner Mediacurrent recently tackled this challenge on an awesome scale: migrating the giant The Weather Channel site to Drupal in a way that worked with all the above venues, and then some. (Have you thought about how your content will look on gas station pumps? Mediacurrent and The Weather Channel have.)

Recently, Matt Davis, a senior Drupal developer at Mediacurrent, explained how the team approached this task, in the first blog post in a projected series on the topic: Migrating Weather.com To Drupal: Increased Content Portability.

If your goal is to "write once, use everywhere" (and it should be), this post is worth checking out.

Tags:  acquia drupal planet
Categories: Planet Drupal

Real world change with PHP and community: "The sky's the limit."

June 10, 2015 at 1:01pm
Language Undefined

Michelle Sanver–developer at Liip–and I sat down and talked at SymfonyCon 2014 in Madrid. Michelle and I have a number of interests in common (community, FTW!) and I really enjoyed getting to know her better in a conversation in front of my microphone and camera. We covered her long history in PHP, her SymfonyCon presentation (Life After Assetic: State of Art Symfony2 Frontend Dev) the PHP Renaissance bringing communities together, Michelle's "open source addiction", building PHP applications that touch the lives of almost everyone in Switzerland, and more.

Categories: Planet Drupal

Drupal 8 - 1st product of the PHP-FIG Era

June 5, 2015 at 3:45pm
Language Undefined

I was happy to talk with two major contributors to Drupal 8 at the same time at Drupal South 2015 in Melbourne Australia. At the time we recorded our conversation in March 2015, Hussain Abbas from Bangalore, India and Jibran Ijaz from Lahore Pakistan had both contributed well over 100 patches to D8. In this podcast we talk about their history in Drupal, open source software as a force for good in society, the benefits of contribution, Drupal as the 1st project of the PHP-FIG era, Drupal 8 for developers, the incredible energy and size of the Australasian Drupal community, and more.

Categories: Planet Drupal

Drupal in China

June 5, 2015 at 2:11pm

Drupal Camp ChinaThat's me: front row, second from the left.

On 14th March 2015, as everyone was coming down from the month-long Valentines Day high, I was in the midst of an exciting Open Source event in Shanghai, China.

With several hundred attendees, the camp attracted people from all over China and the world. Experts and beginners -- in both Drupal and a number of Open Source technologies -- engaged in conversations about CMS, design, language and even solar panels.

Partnering with the Shanghai Barcamp, DrupalCamp China brought together Drupal users, developers, architects, and entrepreneurs from all over China, and the world, to talk Drupal and Open Source.

I was lucky enough to have the opportunity to be asked to speak about Drupal 8 at the event.

As both a Drupal 8 advocate, and someone highly interested in the development of the Drupal community in the Asia Pacific & Japan region (you can read about my Acquia background here), I jumped at the chance to give my take on how the latest version of Drupal will revolutionize open source in China.

Covering the key changes and new features that make Drupal 8 the most exciting version of the framework yet, we took the whistle stop tour of all the features Drupal most needs out of the box:

  • multilingual
  • mobile first
  • inline editing
  • site preview
  • configuration management
  • REST
  • incorporation of other PHP projects

Since this was a Barcamp event, it wasn’t only Drupal community members benefiting from this knowledge, but the entire Shanghai and Chinese technology community.

My friend Sheng Wang has written up a more in-depth report on the day's events, and a broader analysis of Drupal in China. I highly recommend that you check it out.

Both Sheng and I agree: knowing the level of adoption of Drupal in China currently, and looking at the benefits companies are able to take advantage of when laid out against existing solutions, it’s only a matter of time and understanding that will propel Drupal into the forefront -- as it has done in so many other countries.

Tags:  acquia drupal planet
Categories: Planet Drupal

Drupal replaces in-house CMS at Digital Agency - meet John Doyle

May 29, 2015 at 2:27pm
Language Undefined

In April 2015, I was excited to talk with John Doyle, General Manager Technology & Solutions Architecture at the Australian full-service digital agency Komosion, to explore their decision to adopt Drupal to replace other technologies, including an in-house CMS they'd invested 10 years of work in. In this podcast, John very clearly lays out what Komosion's priorities were in making this decision, the benefits for the agency and its clients, and the future he sees using Drupal as the basis for future work.

Categories: Planet Drupal

Front End Performance Strategy: Image Handling

May 21, 2015 at 7:33pm

Javascript code

Business is keenly aware of the importance of page-load time, and its impact on conversion and search engine optimization. It’s now a priority at companies like Wal-Mart, Amazon, and Mozilla.

At Acquia, we hear about it from virtually every customer. They all want to know how our platform and services can improve the performance of their websites. How much can we speed up the responsiveness of the digital experience they are offering their users and customers.

Performance is often considered to be primarily a back-end problem, but frankly what we find after we dig through back-end code: often poor front-end optimization is the culprit and not Drupal itself.

While internet users don't have a page-load value in mind — they’re not counting seconds — they do want their content now. A content owner’s fear is that with a finger hovering over the back button, a user's brain is doing an automatic cost-benefit analysis on whether the loading content is worth the wait. If the site is too slow, they are impatiently wondering if they can get what they’re looking for somewhere else, somewhere quicker.

Its important for business to understand the impact of design and feature-level decisions on performance, and the importance of balancing a sophisticated and elegant user experience with nimble performance. As Engagement Managers, Architects, and Developers, it’s up to us to inform stakeholders of the impacts of their choices, offer compromises where we can, and to implement in smart and responsible ways. Regardless of the heroic efforts we are asked to make at the code level, we should all be able to agree on this:

Faster Page Loads = Happier Users

This article kicks off a series about optimizing the requests made by a Drupal site after the DOM loads. The goal of the series is to give site and product owners a new set of tools to evaluate their internal performance and to provide architects and developers specific recommendations. Today we’ll tackle image handling. Subsequent posts will cover JavaScript and CSS optimization, Content Delivery Networks (CDN), semantic HTML and better content selection. We’ll start with image handling because it’s low-hanging fruit and a front end swing-and-miss we often see.

Our first post is divided in two: Theme Images, the images comprised in your design, and Content Images, the images chosen and uploaded by authors, editors, and producers.

In Theme Images we cover sprites: why you should use them, how we employ them at Acquia, and some resources to get you going. In Content Images we explore how to deliver high quality images, optimized using compression and size adjustments, and how we accomplish this at Acquia. Finally, we’ll link to some additional resources.

IMAGE HANDLING

Your images need to be optimized. Full stop. Apply some lossy compression to that 50 image gallery. Dump all your theme images into one sprite file. Don’t serve a retina-quality image to an outdated smartphone. All of these impact page-load times, and we’ll touch on each one here.

Theme Images

We have the most control over theme images because the end users who create content on a site rarely need to manipulate them. Theme images don’t change much after the designer has created them. That makes them ideal for combining into CSS sprite files. A sprite works by combining all theme images into one file and using the x and y positioning values of the “background” CSS property to control which portion of the image is visible.

Sprites hold the advantage of existing in a singular file that is almost always smaller than the sum of its would-be piecemeal parts, plus it can be downloaded with a single HTTP request and cached for reuse. While nothing new, if you’re unfamiliar or need a refresher on sprites, CSS Tricks has a great introduction.

There are a lot of ways to create sprites, including manually in Photoshop. Various Ruby gems and Grunt/Gulp plugins make the process easier. Here at Acquia, we tend to rely on Compass to do the heavy lifting for our Professional Services builds. When creating sprites with Compass, you can use directories to group images that will form separate sprites. So, instead of creating one enormous sprite for all of my styles, I'll break them up into logically grouped images based on their use. These almost always end up being PNGs. When employing icons, I try to use a font-icon or an SVG icon if possible. And if you’re considering SVGs because they look great at different resolutions and screen sizes, you can sprite those too.

Content Images

Content images differ from theme images in that we as designers don’t have full control. We’re shackled to the whims of a writer or a content producer with a burning desire for that full-window 50-image slideshow. Nevertheless, we need to make sure those 50 images hit a sweet spot for size and compression. That means we’re applying an acceptable amount of lossy compression on our JPGs and sizing them to correspond with viewport size and device resolution.

We see a lot of designers and developers getting around responsive challenges by simply loading a larger image then necessary, not declaring dimensions on the image, and scaling the image using styles.

Instead, we should use our current best option, Drupal’s Picture Module. The picture module uses the (soon to be accepted) HTML5 picture element and is a backport of Drupal 8's Responsive Image module which is a part of core Drupal 8. For many, the current preferred solution is to use an image tag with “srcset” and, yes, I am aware of the ongoing conversation around Drupal 8 image handling. Presently, however, the picture element and a polyfill is Acquia’s go-to solution for responsive images. It uses the Breakpoints Module to load the correct image according to viewport size and pixel density, and adopts our defined image styles to create derivatives for different viewports.

This solution takes care of both image size and compression, doing the math to find that optimized sweet spot so you don’t have to.

CONCLUSION

Drupal can be a speedy back-end workhorse, but sloppy front-end implementations can quickly undo all your hard work. Employing the strategies I’ve outlined here can decrease your page-load times by a significant amount. Using sprites for theme images reduces the number of HTTP requests, and enables caching for future use. Drupal’s Picture Module takes the guesswork out of image delivery, optimizing with appropriate compression and size manipulation.

And this is just a start towards your faster Drupal website. In the next post in this series, I’ll show you how to optimize your javascript and cascading style sheets -- two more ways you can improve your site’s front end to create faster page loads, and happier customers.

Tags:  acquia drupal planet
Categories: Planet Drupal

Karma and the journey from consumption to contribution - Drupal in India

May 20, 2015 at 11:04pm
Language Undefined

At Drupal Camp London 2015, I spoke with Piyush Poddar, Director of Drupal Practice at Axelerant. We talked about Piyush's history in Drupal, Drupal as a business-ready solution, India's coming of age in open source culture, and how that is driving business value.

Categories: Planet Drupal

How to Select Drupal Modules: Part 3 - Evaluation Tips

May 18, 2015 at 8:26pm

choosing a module

In the previous posts we’ve focused on defining your requirements and the basics of searching for modules. Once you’ve found a Drupal project you’re interested in, now you can make a quick evaluation of the project to determine if you should dig deeper before you test it out.

Evaluation Criteria

Each module you select and install on your site must be maintained. There will be security updates, feature improvements and bug fixes offered on a rolling basis. The update manager within Drupal will notify you when new releases are available. This means you will never miss a key security release.

If a module is actively maintained it will mean that one aspect of your site is more likely to be secure and bug-free. One less thing to worry about! Take a “maintenance first” approach to module selection to limit potential issues arising from compatibility issues or security issues that might arise.

An initial evaluation is something an experienced Drupal developer might do in about one to two minutes, simply to compare two modules to decide which to download and try first. However, let’s tease this apart. There are three useful criteria for evaluating a module.

  1. Reputation: How many maintainers? What other contributions have the maintainers made? Is the individual or company a member of the Drupal Association?
  2. Reach: Is there a community around the module? Are there related modules which integrate with it? What is the total number of installations? Checking the usage over time is there a stable arc?
  3. Currency: Have there been recent commits? Are issues being added by users? Is the maintainer responding? Is there a stable (green/not alpha or beta) release available?

These criteria can give you some indication of the level of effort that is being invested in maintaining the software, and help you interpret information on the project page.

The Project Page

You can determine how a project scores against those criteria based on the information available on the project page itself. A wealth of information is available.

example drupal project page

  1. Description: This should provide some basic information about the project and you should be able to tell what requirements the module has.
  2. Project information: Maintenance status and how many reported installations. Just because only two others use a project, doesn’t mean it’s not a good start for a solution for your team.
  3. Downloads: Is there a compatible version available? If it's not recently updated it might be a warning sign, or it might just be a stable, well-used module that just works.
  4. Maintainers: Is there an active team of maintainers? You can look at their profiles which also list other contributions and activities.
  5. What are current issues? The graphs indicate recent activity and also a brief analysis of how responsive the maintenance team is. Keep in mind most of this work is done on a voluntary basis, so if you’re willing to help out, you can often get a better response.
  6. Is documentation available? This will help you in the next step of testing and exploring the module.

The project information provided should be considered in relation to the other information. For example, you might see a project like Bean doesn’t have a Drupal 8 version. This might make you wonder if the solution is future-friendly. In this case, similar functionality has been incorporated into Drupal 8, so it actually makes this module unnecessary.

To give another example, a project with few installations could be just that unique solution you need to connect your Drupal site to an obscure third party application. And as another example, a project managed by a Drupal newcomer who has few contributions could be a great sign that someone is bringing in new skills and experience to the community.

I would never disparage or dismiss a project based on just one of the criteria. Make sure you look at each aspect of the project and balance it with the rest of the information available.

How can I help?

OK, now we’ve whittled down our choices and found a module or two we’d like to try out. In the next blog post, we’ll actually install and test out a module. After that, I’ll show you how to explore and “learn” a new module.

In our Drupal Site Building course we focus on the essential building blocks of Drupal and contributed modules. In fact, some of the contributed modules we use in the Drupal 7 course have become core in Drupal 8, which is a good sign that the community has convened around specific requirements and solutions.

If you’re stuck trying to find a module for X, please leave a comment and I’ll help you find the module you’re looking for.

Tags:  modules drupal 7 site building training learning functionality acquia drupal planet
Categories: Planet Drupal

Web Accessibility for Developers -- Part 2

May 14, 2015 at 8:15pm

access

We’re at the halfway point of what hopefully has been a helpful guide for developers to make a website accessible for all visitors. (If you missed the first part of this two-part series, please click here.)

In this blog, we’ll review how instructional text, navigation, and other parts of development can allow those with blindness and low vision, deafness, and other disabilities to make full use of a website.

There’s a Proper Place for Instructional Text

When providing an example that will help the user fill out a field, place it after the label of the field and before the field itself. This will let the screen reader pinpoint the instructional text and leave no doubt to the user that they’re hearing an example of what’s required. For instance, an example of how to enter the country code and remaining digits of a telephone number should come just before the field.

A Search that Searches When Instructed

Many people love filters that are dynamic — offering results after each selection is made — but it’s not the best thing for a text reader. Dynamic searches cause the page to constantly refresh, leaving a visitor who’s using a text reader to wonder what’s going on. A page shouldn’t reload until the user hits a button. That means all filters and search functionality should have “submit,” “go,” and “apply” buttons.

Jump Directly to Main Content

Readers without disabilities probably take it for granted that they can jump directly to the main content on a webpage. But for those using a screen reader, they first have to listen to a long list of navigation links, icons and other elements before reaching the main content. That’s where a “skip to main content” link comes in handy. It allows a user to skip everything at the top of the page.

The good news for developers using Drupal is that the “skip to main content” link is beginning to come right out of the box and is already included in some themes. If it’s not included, don’t worry. The code in your template should look similar to:

<a id="skip-link" href="#main-content" class="element-invisible element-focusable">Skip to main content</a>.

The CSS code should make the link invisible to a sighted user but will allow a screen reader to focus on the link.

An Easier Way to Zoom and Shrink

Visually impaired people who don’t need a screen reader still may need to manipulate the size of text. They don’t always know how to use keyboard shortcuts and need a user-friendly aid. In a matter of minutes, a site administrator can plop a text-resizing module onto a Drupal webpage. Here’s a handy helper on how to do it. Just keep in mind that it doesn’t always work for menu items, but it usually does resize static text.

Know What to Show; What to Hide

CSS allows developers to change the style of a webpage and make content sparkle. But some text-based screen readers or older screen readers need to read the page with all of the styles disabled. It’s important to make sure that if the stylesheets are turned off, the screen reader will still be able to read the order of the content correctly and be able to access all functionality.

Most of the responsive Drupal themes are already providing this functionality out of the box, but this standard is important to think about, and test when choosing how you will lay out your pages.

In order to test, disable your stylesheets — as seen in this screenshot of a White House page, for instance — and scroll down the page to ensure that the content order is the same as you originally intended.

white house screenshot

These are only a few steps that can help developers make a website accessible to all visitors. If you’d like to see more ideas — or perhaps even gain a greater understanding of Web accessibility itself — here are two resources worth checking out:

The first is a checklist of standards from Section 508 of the federal Rehabilitation Act that government agencies must follow to provide full and fair Internet access to people with disabilities. Even though only federal agencies are required to follow them, the standards serve as a thorough and detailed source of steps for businesses and organizations to use.

Another useful resource are the Web Content Accessibility Guidelines offered by the World Wide Web Consortium (WC3). The guidelines are comprehensive and should also help you on the way to creating an accessible website.

Thanks for reading. Please leave a comment below if you have other suggestions you’d like to share.

Down the road, we’ll post a companion, two-part series on accessibility for clients – stay tuned.

Tags:  acquia drupal planet
Categories: Planet Drupal

Build Your Drupal 8 Team: Technical Roles and Required Skills

May 14, 2015 at 1:38pm

Last time, we discussed some big themes your Drupal 8 team should be synched up with, like object-oriented programming. Now we're going to drill down into more specifics on the technical side.

Is your tech team full of generalists, or do all your developers have special skill sets and focus on specific kinds of functionality, like databases or communications? Either way, someone on your team will have to fill each of these technical roles for a successful Drupal 8 project.

Drupal 8 Architect

More than anyone else on the project, the Drupal 8 architect needs to understand Drupal 8 in depth. The architect needs to make the decisions about the project's overall architecture, which requires envisioning how the system works as a whole. This is bigger than just the Drupal 8 application, because the project needs to fit into your company's entire software environment. It may need to be integrated with other corporate back-end systems, so this role needs to understand the full technical environment, not just the tech stack that comes with Drupal 8. As much as possible, this individual needs to have a strong understanding of front-end and back-end development tools in addition to a thorough understanding of how Drupal 8 works.

UI Designer

The UI designer needs to understand what the technology is capable of and how to use it to create the best experience for end users. To work with Drupal 8, the UI designer should keep building HTML, CSS and Javascript knowledge, but also develop a Drupal 8-specific understanding of how to create themes and build sites. Learning the capabilities of Twig is needed because Twig replaces PHPTemplate in the new version of Drupal. Instead of .tpl.php files, .html.twig files are needed.

Front-End Developer

All that stuff the UI designer promised the business? It's the front-end developer's job to turn that hypothetical design into a functioning interface. Like the UI designer, front end developers should enhance their knowledge of HTML, CSS and Javascript, and pick up knowledge of Twig. PHP knowledge will help also; so will knowing MySQL. The front-end developer will also want a Drupal 8-specific understanding of how to create themes and build sites, as well as how to develop custom modules and address Drupal 8 performance and Drupal 8 security concerns.

Back-End Developer

Clicking on website front-end elements does nothing until you implement the functionality in the back-end. You need to be able to write new functionality from scratch, building on existing components when possible. When the application needs to integrate with other systems, the back-end developer writes the code that hooks it all together into a system that functions seamlessly. This role needs some knowledge of front-end tools like HTML, CSS and JavaScript, but it also requires understanding back-end tools like PHP and MySQL in depth. For Drupal 8 knowledge, the back-end developer should focus on architecture and planning topics as well as how to develop custom modules and address Drupal 8 performance and Drupal 8 security concerns.

Marketing Technical Lead

The marketing technical lead owns the content publishing process. She defines the procedure for publishing content and makes sure it adheres to site standards. Because content doesn't accomplish anything unless someone sees it, the marketing technical lead needs to make sure it follows good SEO and SEM practices. It's important that the marketing tech lead keeps current with ever-changing SEO practices, and focuses on learning Drupal 8 as a content management system. Learning about the administration functions, and the kinds of changes you can make that won't require a developer to write code, will be especially useful for this role.

Next time: Non-Technical Team Roles and Required Skills for a Drupal 8 Project.

Tags:  acquia drupal planet
Categories: Planet Drupal

Web Accessibility Tips for Developers

May 7, 2015 at 7:06pm

access

Creating the code that makes a website accessible to all visitors doesn’t have to be as time-consuming or resource-intensive as you might think. All you need to do is follow some simple steps that require a little extra time and effort. But these efforts will ensure that your Web content is at the fingertips of everyone — including those with blindness and low vision, deafness, and other disabilities.

It’s up to both the developer and the client to achieve site accessibility. Although they usually work together in the planning and later stages of website creation, a developer and client also have separate responsibilities in making a site accessible. This blog post, the first in a four-part series that offers website accessibility tips for developers, will make this important part of development easy to follow. And it comes just in time for Global Accessibility Awareness Day on May 21.

Reading More Shouldn’t Take More Effort

The visually impaired rely on screen readers to help them learn what’s on a page, and to navigate a site. But without the proper code in place, a screen reader that’s reading a short list of blog posts on a landing page that will direct users to a longer list of items, will only say “read more” over and over again.

Not knowing what the “more” is, a user will probably get frustrated and go somewhere else. Fortunately, all that’s needed to get a screen reader to articulate the details that accompany the “more” is just a few snippets of code — commands that accommodate disabled people while at the same time hiding text and not cluttering up the screen for non-disabled people.

A developer simply needs to include a small snippet of code similar to:

<a href="/">Read more <span class="readmore"> [site] Blogs</span></a>.

The “read more” CSS class should include code that makes the span class invisible to sighted users but can be heard by non-sighted users. Sighted users would still see “Read More” but non-sighted users would hear “Read More about [site] Blogs.”

Alt Text Should Paint a Clear Picture

Developers should stress to clients the necessity and importance of using alt text on a webpage. It helps visually impaired visitors know all there is to know about an image.

It’s easy to overlook when constructing a webpage, but it’s super easy to include alt text in an image’s markup code. A simple description of what the image is, and its title, are all that’s needed — as seen in this example of the markup box for a photo of Attorney General Eric Holder.

Spell Out What’s Required in a Required Field

Many websites use an asterisk as a cue for people to know what’s a required field of input on a form — but that’s not the best method to reach everyone. That sort of general warning doesn’t always work with screen readers; the user will be left guessing where the required field is. Not to mention, a colorblind visitor won’t see the red or green that’s typically used to highlight the field asterisk warning.

The solution is easy. First, the code behind the field should spell out the name of the required field, and the fact that inputting information there is required — so that people using screen readers will have no doubt about what they need to do. Also, the code should inform users that an asterisk is indeed the warning that’s denoting a required field; that way colorblind visitors who can’t see the red or green text that’s often used on websites as the only type of warning won’t have to second-guess and those using a screen reader will also will know what to do.

Don’t Bury Mistakes; Put the Error Message at Top

Another thing about website forms: A visitor who errs when completing an online form should be immediately informed on the refreshed page about where they’ve made a mistake. Otherwise, a screen reader will speak the entire page again and mention the errors only when it reaches the incorrect fields. The refreshed page should instead offer — at the very top — a basic box that lists what went wrong and what is required.

That’s it for now. Stay tuned for second part of this series, as we take you, the developer, down a true and easy path to website accessibility.

Tags:  acquia drupal planet
Categories: Planet Drupal

Building a great remote team, helping clients & giving back

May 7, 2015 at 4:26pm
Language Undefined

The European Acquia Client Advisory team had an onsite week in Reading the week after Drupal Camp London 2015. I got the chance to see a number of them there and sit down with two of my friends from "Supporta!"–Daniel Blomqvist and Henk Beld. We talked about remote teams and helping others succeed with Drupal, while also paying it back/forward by sharing and teaching what they learn and what they know.

Categories: Planet Drupal

Security in the Cloud: Why Open Source is the Best Choice

May 7, 2015 at 2:37pm

cloud locked
This is the first of a series of security-related postings, which Acquia will compile into a free ebook. In this entry, we’ll look at the perennial question: Is Open Source software inherently more secure than commercial closed-source software?

Securing applications is an ongoing process. It’s a continuum that requires vigilance.

Application security begins during the requirements analysis stage of the Software Development Lifecycle, and must be nurtured throughout the life of the application to be successful.

With Drupal properly configured and managed, it is as secure and reliable as any enterprise content management tool available. However, a Drupal application must be maintained and enhanced over the course of its existence. Acquia Cloud eases this management and maintenance burden on customers, and substantially reduces the risk that software vulnerabilities, external actors, or poor human choices will compromise the integrity of the application or the organization.

As requirements are gathered for a new project, and both open and closed systems are considered, evaluators often ask, Which solution is more secure?

This is frequently cast as a contest between the ideologies of open and closed source software.

It’s the wrong question. All software is susceptible to errors at every step of the lifecycle: from first release, through patches, and on through end-of-life support, when the provider no longer supports the code.

Repeated professional and academic assessments have demonstrated that coding errors are simply part of software development. The professionalism of closed-source commercial software development, which has continually improved its security reviews and practices, is matched by the professional commitment of open source engineers. The main difference between the two is the visibility of source code to all users.

Because most malicious users take the same approach to probing for and exploiting known vulnerabilities, by trying to enter systems on the Web, source code availability seldom plays an important role in discovering flaws in mistakenly unprotected servers, services, or protocols. Open source code, however, enjoys a greater flexibility and speed-to-solution when a vulnerability is discovered, which we will look at later.

Writing, testing, and shipping perfect code is the impossible dream that falsely creates the impression that some software is inherently more secure than others. All non-trivial software is imperfect, and the hardware it runs on can also carry vulnerabilities. In fact, the likelihood of security vulnerabilities is inherent in any application, because people often make mistakes in development or configuration of an application.

So, when we talk about “computer security,” we must recognize that we’re really talking about human security practices that can fail at any number of user-controlled points. Open source software makes those potential flaws a discussion among a group of coders, reviewers, and security professionals. In closed source software, a potential flaw is often regarded as a secret -- one that may impede the resolution time or increase the risk of a discovered vulnerability.

A race with intruders

At the time a vulnerability is discovered, the clock starts counting down to an increase in attacks against that vulnerability. The closed-source software world depends on “security through obscurity,” the assumption that hiding source code makes it harder to discover vulnerabilities. This means that a newly discovered vulnerability sets off a race between the developer and malicious users: who’s going to patch or exploit that vulnerability first?

The same race happens in the open-source software field, but there are many more people familiar with the open source code, so the dynamics are very different. Sometimes projects even collaborate with each other to increase the number of developers working on the same fix, as was the case in August, 2014 for the XML-RPC Denial of Service affecting both WordPress and Drupal.

By comparison, in proprietary software only the commercial software company’s employees can work to fix an error in the closed code.

Indeed, many commercial software security vulnerabilities are discovered by outside consultants and security professionals, who inform the company that built the application. These outside discoverers may bring a solution to the problem along with their vulnerability report, but ultimately the vulnerability will only be patched when the company decides to respond, when it is able.

In some situations, this vulnerability becomes an open secret held closely by an ever-expanding circle of people in the know, all hoping the Bad Guys don’t find out before they deliver a patch. By contrast, commercial companies with a vested interest in the security and capabilities of certain open source systems are now frequently joining together to fund development or security remediations out in the open. Thus, open source actually adds another dimension of security through this community approach to development: it provides a constructive outlet for coders whose passion is searching for vulnerabilities.

Open source code software allows many hands to work towards the mission of identifying and fixing vulnerabilities. The same race to patch a vulnerability exists, but the open source community has a more distributed approach to responding to a known issue. This is generally understood to be an advantage. In a 2009 University of Washington paper, Is Open Source Software More Secure?, researchers, including a Microsoft contributor, concluded:

“...Open source does not pose any significant barriers to security, but rather reinforces sound security practices by involving many people that expose bugs quickly, and offers side-effects that provide customers and the community with concrete examples of reusable, secure, and working code.”

It’s worth mentioning, by the way, that in late 2014 Microsoft itself, once the paragon of the closed software model, announced that it will make its server-side .NET stack and core runtime frameworks available as open source code. Acquia’s Christopher Stone said it was the software equivalent of the falling of the Berlin Wall.

So the real operational security challenges come after a vulnerability is discovered, in the time between a patch becoming available and the time that customers patch their software. Most successful attacks occur in that window. Any system left unpatched is likely to be targeted at some point.

This is why Acquia Cloud's managed platform includes patching and maintaining of all server components, prepares security updates for their customers with Remote Administration, and recommends security best practices and configuration hardening for Drupal applications.

With Acquia, customers can count on rapid responses to vulnerabilities and a quick delivery of patches when available.

The intractable problems in computer security remain: open or closed, people write imperfect code; many are lazy about patching or upgrading to the latest version to close newly discovered vulnerabilities.

The challenge is bigger than open source versus closed software.

That’s why we’re confident that the Acquia approach is the best hybrid response to the threat of imperfect software. We leverage professional practice, the open source community, and a tightly managed continuous-deployment workflow to quickly patch vulnerabilities on our platform, while providing the tools to customers to stay up to date with regards to patching their Drupal applications.

We’ll get into the details of Acquia’s approach to patch management in one of our next posts.

Tags:  acquia drupal planet
Categories: Planet Drupal

Four Final Questions You Should Ask Your Drupal Cloud Host

May 5, 2015 at 4:48pm

You know how when you're buying a car, and the questions just keep on coming? And the salesperson keeps making roundtrips to the manager's desk?

It's kind of like that when you're considering where to host your website. There's always time for more questions. It's one less surprise later on.

That's why I keep adding to my list.

It started, you may recall, with just five questions. A week later, I added five more. Now, before closing out this series, I've got a final four.

Ask now, avoid unpleasant surprises later. That's my motto, and it should be yours.

1. What is your level of Drupal expertise?

Acquia offers the industry's highest level of technical Drupal expertise. Our support organization is larger than most hosting companies––over 60 professionals worldwide with over 250 years of combined experience. And Acquia’s overall level of in-house Drupal expertise is unparalleled with over 150 Drupalists, including core owners, security team members, and module contributors. Furthermore, Acquia’s wealth of Drupal knowledge is being expanded continuously. Closed loop processes between our support and engineering organizations help to drive new tools and add to our Help Center, which we then share with the Drupal community.

2. If my site turns into a volcano of errors, will you proactively notify me?

Acquia monitors the health of customers’ servers, and we proactively notify customers of the nature of any issues we detect. When the problem is server-side, we mitigate it, and when the issue is caused by something on the application side, we provide recommended steps to resolve the issue (though we do not usually implement them ourselves unless the customer cannot for some reason).

Acquia also gives customers access to advanced monitoring at the application level, via partners like New Relic or features like our Uptime Monitoring tool—both of which can be used to alert customers in a self-service fashion whenever the application is suffering. If the root cause is server-related, we will notify the customer proactively, but some issues are application-only (meaning they do not trigger server health alerts on our end), so that is why we recommend that customers utilize application-level monitoring whenever possible.

3. Do you offer advanced platform analysis tools to help ensure that my application is running at its best?

Every Acquia Cloud Subscription comes with a suite of tools that make managing your Drupal sites easier than ever before. Drupal site developers, administrators, and site owners can quickly identify problems, eliminate costly mistakes, simplify processes, and improve overall site performance. Acquia’s monitoring tools analyze and measure the quality of your site based on security and performance parameters. Dozens of tests ensure your site’s conformance with best practices for security, performance, and general Drupal and web application development. Monitoring over 50 settings, these tools provide real-time analysis and proactive alerts for issues with your Drupal code and configuration. You can identify code issues and modifications fast, easily download patch files, and view needed updates at-a-glance. You’ll receive a site score to help you improve the quality of your site. You’ll get clear, actionable recommendations to help solve problems and expand your Drupal knowledge.

Acquia provides several additional tools that help you quickly troubleshoot problems with your application. The Uptime Monitoring tool monitors your site’s uptime and responsiveness. It checks your site every minute to see if it’s online and serving pages. For a developer looking to quickly and easily get visibility into a problem, log streaming is a solution that allows for easy access to information without having to download a full day’s log file. It provides real-time access to server logs from within the UI—making troubleshooting more efficient.

4. What is your uptime Service Level Agreement (SLA), and how do you ensure that you meet it?

Acquia commits to 99.95 percent platform, infrastructure, and application uptime. To ensure this, we operate monitoring services 24x7. Acquia uses the Nagios monitoring platform to provide instant access to over 50 vital real-time and historical metrics. We also maintain robust home-grown monitoring tools to ensure performance. Our team of Cloud Operations professionals is always standing by—proactively monitoring your environment and responding to critical issue alerts. With coverage in all time zones and fluency in five languages, the team is available 24x7 for critical, site-impacting issue response.

Tags:  acquia drupal planet
Categories: Planet Drupal

Pages