Apr 04 2019
Apr 04

With all the excitement about decoupled Drupal over the past several years, I wanted to take a moment to articulate a few specific factors that make headless a good approach for a project – as well as a few that don’t. Quick disclaimer: this is definitely an oversimplification of an otherwise complex subject, and is based entirely on our experience here at Aten. Others will draw different conclusions, and that’s great. In fact, the diversity of perspectives and conclusions about use cases for headless underscores just how incredibly flexible Drupal is. So here’s our take.

First, What is Decoupled?

I’ll keep this real short: decoupled (or headless) Drupal basically means using Drupal for backend content management, and using a separate framework (Angular, React, etc.) for delivering the front-end experience. It completely decouples content presentation (the head) from content management (the body), thus “headless”. There are tons of resources about this already, and I couldn’t come close to covering it as well as others already have. See Related Reading at the end of this post for more info.

Decoupled and Progressively Decoupled

For the purpose of this post, Decoupled Drupal means any Drupal backend that uses a separate technology stack for the front-end. Again, there’s lots of great material on the difference between “decoupled” and “progressively decoupled”. In this post, just pretend they mean the same thing. You can definitely build a decoupled app on top of your traditional Drupal stack, and there are often good reasons to do exactly that.

Why Decoupled?

Decoupled Drupal provides massive flexibility for designing and developing websites, web apps, native apps and other digital products. With the decoupled approach, designers and front-end developers can conspire to build whatever experience they wish, virtually without limitation. It’s great for progressive web apps, where animations, screen transitions and interactivity are particularly important. Decoupled is all but necessary for native apps, where content is typically managed on a centralized server and published via an API to instances of the app running on people’s devices. In recent years, Decoupled Drupal has gained popularity even for more “traditional” websites, again primarily because of the flexibility it provides.

Pros and Cons

I’m not going to list pros and cons per se. Other articles do that. I’m more interested in looking at the specific reasons we’ve chosen to leverage a decoupled approach for some projects, and the reasons we’ve chosen not to for others. I’m going to share our perspective about when to go decoupled, and when not to go decoupled.

When to Decouple

Here are a few key questions we typically ask when evaluating a project as a fit for Decoupled Drupal:

  • Do you have separate backend and front-end development resources? Because decoupled means building a completely separate backend (Drupal) from front-end (Angular, React, etc.), you will need a team capable of building and maintaining both. Whether it’s in-house, freelance or agency support, Decoupled Drupal usually requires two different development teams collaborating together to be successful. Organizations with both front-end devs and backend devs typically check “yes” on this one. Organizations with a few generalist developers, site builders or web admin folks should pause and think seriously about whether or not they have the right people in place to support a decoupled project.
  • Are you building a native app and want to use Drupal to manage your content, data, users, etc.? If yes, we’re almost certainly talking decoupled. See “Why Decoupled?” above.
  • Do you envision publishing content or data across multiple products or platforms? Example: we recently built an education product that serves both teachers and their early childhood students. We needed a classroom management app for the former, and an “activity explorer” with links to interactive games for the latter. Multiple products pulling from a single backend is often a good fit for decoupled.
  • Is interactivity itself a primary concern? There are plenty of cases where the traditional web experience – click a link, load a new page – just doesn’t do justice. Interactive data visualizations and maps are great examples. If your digital project requires app-like interaction with transitions, animations, and complex user flows, you will likely benefit from an expressive front-end framework like Ember or Angular. In those cases, decoupled is often a great fit.
  • Does working around Drupal’s rich feature set and interface create more work in the long run? Drupal ships with a ton of built-in features for managing and viewing content: node edit screens, tabs, subtabs, node view pages, admin screens, and on and on. Sometimes you just don’t need all of that. For some applications, working around Drupal’s default screens is more work than building something custom. In some cases, you may want to take advantage of Drupal’s flexible content model to store content, but need a completely different interface for adding and managing that content. Consider evites as a hypothetical example. The underlying content structure could map nicely to nodes or custom entities in Drupal. The process for creating an invitation, customizing it, adding recipients, previewing and sending, however, is something else altogether. Decoupled Drupal would allow you to build a front-end experience (customizing your invitation) exactly as you need it, while storing the actual content (the invite) and handling business logic (saving, sending, etc.) in Drupal.
  • Do you want the hottest technology? Sometimes it’s important to be at the cutting edge. We respect that 100%. Decoupled Drupal provides incredible flexibility and empowers teams to build rich, beautiful experiences with very few limitations. Further, it allows (virtually requires) your teams – both front-end and backend – to work with the very latest development tools and frameworks.

When Not to Decouple

Conversely, here are a few key questions we ask that might rule out Decoupled Drupal for a project:

  • First, take another look at the list above. If you answered “no” to all of them, Decoupled Drupal might not be a great fit for your project. Still not sure? Great, carry on...
  • Are you hoping to “turn on” features in Drupal and use them more-or-less as-is? One of the major draws for Drupal is the massive ecosystem of free modules available from the open source community. Need Disqus comments on your blog? Simply install the Disqus Drupal module and turn it on. How about a Google Map on your contact page? Check out the Simple Google Maps module. Want to make a slideshow from a list of images? No problem: there are modules for that, too.
    With Decoupled Drupal, the ability to simply “turn-on” front-end functionality goes away, since Drupal is no longer directly managing your website front-end.
  • Do your front-end requirements match Drupal’s front-end capabilities out-of-the-box? We work with a number of research and publishing organizations whose design goals closely align with Drupal’s capabilities. I’m hard pressed to recommend a decoupled approach in those cases, absent some other strong driver (see above).

Related Reading

Mar 06 2019
Mar 06

I recently wrote an article about Flexible Authoring with Structured Content. In this follow-up post, I'm going to dig into more detail on one specific approach we've been working on: Entity Reference with Layout.

If you use the Paragraphs module and wish there was a way to more easily control the layout of referenced paragraphs on a particular node, check out Entity Reference with Layout, a new module for Drupal 8. Entity Reference with Layout combines structured content (a la Paragraphs) with expressive layout control (a la Layout Discovery in core). Now you can quickly add new sections without leaving the content edit screen, choose from available layouts, add text or media to specific regions, drag them around, edit them, delete them, add more, and so on. The experience is easy-to-use, fast, and expressive.

Background

Structured Content FTW.

We’ve been working with Drupal for a very long time: since version 4.7, way back in 2006. We love the way Drupal handles structured content – something that has only improved over the years with support for important concepts like “fieldable entities” and “entity references.” Integration with flexible rendering systems like Views, and in more recent years the ability to quickly expose content to services for headless, decoupled applications, relies largely on structured content. With structured content, editors can “Create Once, Publish Everywhere (COPE),” a widely-recognized need for modern web authoring. Drupal’s support for structured content is an important advantage.

Drupal, We Have a Problem.

But Drupal’s interface for creating structured content– the part that editors use daily, often many times per day – is lagging. In the era of SquareSpace, WIX, and Gutenberg, Drupal’s clunky authoring interface leaves much to be desired and is quickly becoming a disadvantage.

Complex form for adding different types of content called paragraphs

Paragraphs to the Rescue. Sort Of.

There have been a number of really interesting steps forward for Drupal’s authoring interface as of late. Layout Builder is powerful and flexible and soon to be a full-fledged part of Drupal core. Gutenberg, an expressive authoring experience first developed for Wordpress, now offers a Drupal version. The Paragraphs module solves similar problems, providing a way for authors to create structured content that is incredibly flexible.

We started using Paragraphs years ago, soon after it was first introduced in Drupal 7. We liked the way it combined structure (Paragraphs are fieldable entities) with flexibility (Paragraphs can be dragged up and down and reordered). We used nested Paragraphs to give authors more control over layout. The approach was promising; it seemed flexible, powerful, and easy-to-use.

For more complex applications, though, nested Paragraphs proved anything but easy-to-use. They could be profoundly complicated. Managing intricate layouts with nested Paragraphs was downright difficult.

If only there was a way to have it both ways: Drupal Paragraphs plus easy layout control. Well of course, now there is.

Introducing Entity Reference with Layout

We created Entity Reference with Layout to give authors an expressive environment for writing structured content. As the name suggests, Entity Reference with Layout is an entity reference field type that adds an important element to the equation: layout. It leverages the layout discovery system in Drupal Core, allowing editors to quickly add new paragraphs into specific regions. The authoring experience is expressive and easy, with drag-and-drop layout controls.

Give Entity Reference with Layout a Whirl

Entity Reference with Layout is available on Drupal.org. Installation is quick and easy (we recommend composer, but you can also just download the files). The module is experimental and still under active development; check it out and let us know what you think. We’d love to hear feedback, bug reports, or feature requests in the issue queue. And if you think your organization’s web editors might benefit from this approach and want to learn more, drop us a line and we’ll follow up!

Feb 15 2019
Feb 15

As a writer or editor for your organization’s website, you should be able to quickly write articles or build pages that are collections of smaller elements. You should be able to write some text, add a slideshow, write some more text, perhaps list a few tweets, and finish things off with a list of related content. Or maybe you paste in a pull quote, add a couple full-width images with captions, or even put together an interactive timeline. Your content management system should let you do all that, easily. But chances are, it won’t be with the WYSIWYG you’re used to right now.

What You See Isn’t What You Get

WYSIWYG editors still fall short when it comes to doing much more than simple formatting and embedding a few images. Anything beyond that, and the underlying technology has to leverage some kind of proprietary “smart code” or “token” and do some find-and-replace magic that makes slideshows, media players, or other more complex blocks of content show up right to the editor. These tokens aren’t typically based on any adopted standard. It’s just this custom, arbitrary formatting shortcut that programmers decided to use that tells the CMS, “Replace this snippet with that other piece of content.”

If it sounds complicated, that’s because it is. It’s hard to get right. It’s hard to build in a sustainable way. It’s hard – impossible, really – to make it look right and work well for authors. It’s REALLY hard to migrate.

Here’s an example: In earlier versions of Drupal, Node Embed was a way to embed one piece of content (say, an image) inside the body of another (like an article). The “smart code” [[nid: 123]] tells Drupal, “replace this with the piece of content that has an ID of 123.” It worked, but the authoring experience was janky. And it really wasn’t structured content, since your markup would end up littered with these proprietary snippets referencing objects in the CMS. Somewhere down the line, someone would inevitably have to migrate all of that and write regular expressions and processors to parse it back into a sane structure for the new system. That gets expensive.

Simple form with input, select, and textarea

Fieldable Entities and Structured Content

The thing that lets you, the web editor, write content that is both manageable and flexible is breaking your content into discrete, single-purpose fields. In Drupal it’s called “fieldable entities.” You don’t dump everything into the WYSIWYG (which would be hard to do anyway). Instead, there’s a field to add the author’s name, a field for attaching images, and a field for the text (that last part gets the WYSIWYG). More generally, this serves an important concept called “structured content.” Content is stored in sensible chunks. It adapts to a variety of contexts, like a mobile app or a news aggregator or (of course) your website. In the case of your website, your CMS pushes all those fields through a template, and voila, the page is published beautifully and your readers eat it up.

Complex form with input, select, textarea, and multiple fields nested inside

What If My Fields Have Fields?

Here’s where it gets interesting. Back to our earlier example: let’s say your article has a couple slideshows. Each slideshow has a few images, captions, and links. Suddenly your discrete, single-purpose field (slideshow) has its own fields (images, captions, links). And, you may want to add a slideshow virtually anywhere in the flow of the page. Perhaps the page goes text, slideshow, text. Or maybe it’s text, slideshow, text, some tweets, another slideshow. And now you want to swap some things around. Again, you should be able to do all that, easily.

Drupal Paragraphs

Enter the Drupal Paragraphs module. Paragraphs takes the approach of creating content bundles, or collections of fields, that can be mixed and matched on a given page in virtually countless configurations. They’re called “Paragraphs” because they are flexible, structured building blocks for pages. The name is a little misleading; in fact, they are 100% configurable groups of fields that can be added, edited, and rearranged however you want on a given article. You can have paragraph types for slideshows, pull quotes, tweets, lists of related content, or virtually anything else. Paragraphs are building blocks: smaller elements that can be combined to build a page. And like I said earlier, you should be able to easily make pages from collections of smaller elements.

Complex form for adding different types of content called paragraphs

Drupal Paragraphs is Sort of Easy

We use Drupal Paragraphs whenever a particular type of content (a news article, blog post, etc.) is really built up of smaller, interchangeable collections of other fields (text, slideshows, videos, etc.). Drupal Paragraphs are flexible and organized. They let authors create whatever kinds of pages they want, while storing content in a way that is structured and adaptable. Migrations with Paragraphs are generally easier than migrations with special, proprietary embed codes. Breaking content types into Paragraphs gives authors the flexibility they need, without sacrificing structure. You don’t end up with a bunch of garbage pasted into an open WYSIWYG field.

So what’s the catch? Well, the interface isn’t awesome. Using Drupal Paragraphs can add a lot of complexity to the authoring experience. Forms will have nested forms. It can be overwhelming.

Alternatives to Drupal Paragraphs

As I’m writing this, another approach to page building is gathering momentum in the Drupal universe. Layout Builder is currently an experimental module in core, and slated to ship as a stable release with Drupal 8.7. Layout Builder provides a slick drag-and-drop interface for editors to build pages from blocks and fields. We’re excited to see how Layout Builder develops, and to see how well it performs for large editorial websites. For websites with hundreds or thousands of articles, managing pages with Layout Builder may be difficult. As Drupal’s founder, Dries Buytaert, pointed out in a post late last year, “On large sites, the free-form page creation is almost certainly going to be a scalability, maintenance and governance challenge.”

Other open source CMS communities are seeing a similar rise in the demand to provide authors with flexible page-building tools. WordPress released Gutenberg, a powerful drag-and-drop editing experience that lets authors quickly build incredibly flexible pages from a massive library of components. It’s worth noting Gutenberg is not without challenges. It poses accessibility issues. Antithetical to the themes in this post, it does not necessarily produce structured content. It relies on proprietary tokens for referencing embedded blocks of content. But it is very flexible, and offers an expressive interface for authors. For Drupal users, there’s a Drupal port for Gutenberg.

For us at Aten, the balance comes back to making sure content is stored in a way that is structured, can be adaptive, is reusable, and is relatively easy to migrate. And that you, the writer, can easily build flexible web pages.

Structured and Adaptable: Drupal Paragraphs with Layout Control

We’ve been working on an approach that keeps Paragraphs in place as the primary way content is managed and stored, but also gives authors the ability to easily control layout. Using Drupal’s core Layout Discovery system, Entity Reference with Layout is a custom field type that combines layouts and Paragraphs. It’s still in very early experimental development, but we’re excited about the impact this approach might have on making it even easier to create flexible pages. And it uses Paragraphs for content storage, with the benefits we’ve already touched on: content is well-structured and relatively easy to migrate. It’s not as flexible or robust as Layout Builder, but might be a great option for authoring flexible pages with Paragraphs. (More on this in a future post.)

Reusable and Flexible: Advanced Paragraphs

Since Drupal Paragraphs are themselves collections of flexible fields, there are all kinds of interesting ways they can be applied to building complex publishing features. We’re working with a client in publishing who needs the ability to completely customize the way content appears on their home page. They would like to promote existing content to the homepage, but they may want to override article titles, images, and summaries. Since the article authors aren’t the same people editing the home page and other key listing pages, they didn’t want authors to have to think about all of those variations. The way content is presented on an article page isn’t always the best-suited for the homepage and other contexts. We used paragraphs to give home page editors the ability to drop articles onto the page, with fields for overriding everything they need to.

Where to Go From Here

Your CMS should make it easy to write content and build pages. If you’re interested in seeing a demo of Drupal Paragraphs, Layout Builder, or Gutenberg, drop us a line. We’d love to help.

Oct 31 2017
Oct 31

Here at Aten, we do a lot of work with Drupal, mostly on large redesign projects for nonprofits and universities. We’ve been in the business for a while now (since 2000), and one thing we’ve been talking about for years is the predicament of “buy-maintain-replace” release cycles. Specifically, website redesigns often fall prey to a problematic purchasing cycle that directly counteracts strategic goals.

It goes like this: first there’s a capital campaign, then a big spike in funding to do a redesign project, followed by modest support budget for a few years. During support, things everyone would like to change start to pile up, often beginning as a “backlog” or “wish list,” inevitably becoming a “gripe list” for all the things that are slowly and surely making your website obsolete. Time passes and the gripe list grows. We hear things like, “Our current website is horribly outdated; it isn’t even responsive.” Rather than invest in old technology and continue addressing the growing list of issues, tasks are pushed off for a future redesign. Eventually, there is a new capital campaign. The cycle starts over, rinse and repeat.

If you’re coming from a product background and you’re programmed to value ongoing development and continuous innovation, this already sounds bad. But if you’re from traditional IT management, you might think of redesigns more like purchasing any other technology solution. You buy it, it gets old, you replace it – often with some form of ongoing support between major expenditures. The smaller the support requirement, the more successful the project. Likewise the longer you can go without upgrading, the more successful the project.

The trouble is, your website, app, etc. doesn’t really work that way. Your website shouldn’t just be checking boxes on functionality requirements the way your phone system or workstations do; rather, your website is the public face and voice of your organization. It needs to keep up and tell your story clearly, every day. It needs to evolve as quickly as your organization does. And that requires ongoing investment. More than that, it requires a fundamental shift in the way decision makers think about planning digital projects.

There’s already a ton of fantastic material about the need to adopt a product approach over the more traditional project mindset. One of my favorite posts on the subject was written back in 2015 by the team at Greenpeace titled, “Product teams: The next wave of digital for NGOs?” I especially love this infographic. The illustration is spot on: first, a huge spike in money and time with a brief climax at launch, followed by diminished investment during a prolonged support period with equally diminished satisfaction, all to be repeated over and over again.

Interestingly, this problematic “buy-maintain-replace” cycle actually aligned closely with the release cycle for previous versions of Drupal. For years, timing for the “buy” stage in the cycle aligned surprisingly well with the stable release for major Drupal versions. First, you built a website on Drupal 4. Support phase ensued. Over a few years wish lists turned to gripe lists. Momentum grew behind doing the next major redesign, right on time for the stable release of Drupal 5. Rinse. Drupal 6. Repeat. Drupal 7.

While we were talking more and more about a product approach, the technology actually lent itself to the project mindset. Quick example: retainers are a big part of our business at Aten, and have been important for helping us support clients in the product approach. With retainers, clients invest consistently in their digital platforms over the long term. We identify strategic priorities together, maintain a backlog, organize sprints and deploy iterative releases. But with past versions of Drupal, an organization still needed to invest heavily for major release upgrades. At some point in the cycle, there were diminishing returns associated with ongoing investment in an outdated system. We started prioritizing tasks based on the fact that a large redesign was looming. We said things like, “Let’s just wait on Drupal 7 for that.” In many ways the underlying platform was promoting a “buy-maintain-replace” development cycle. The product approach was still valuable, but hampered by inevitable obsoletion of the technology.

Enter Drupal 8.

With Drupal 8, there’s a lot to be excited about: configuration management, component-based theming, improved performance, content moderation, modernized development tools, support for API-first architecture, and the list goes on. But I want to focus for a minute on Drupal’s release cycle.

Drupal’s vastly improved upgrade path is a huge win for the platform and a major reason organizations should consider migrating to Drupal 8 sooner rather than later.

With past versions of Drupal, major release upgrades (i.e. D6 to D7) required a significant development effort and usually constituted a major technology project. As I’ve touched on already, upgrades would typically coincide with a complete redesign (again, buy-maintain-replace).

With Drupal 8 the release cycle is changing. The short, non-technical version is this: Drupal 8 will eventually become Drupal 9. If you stay up-to-date with underlying changes to the platform as it evolves, upgrading from 8 to 9 should be relatively simple. It’s just another release in your ongoing development cycle.

With Drupal 8, an organization can invest consistently in its digital platform without the problem of diminishing returns. As long as you adopt the product approach, your platform won’t become outdated. And that’s fantastic, because the product approach is what we’re all going for – right?

Resources and Related Reading:

Apr 26 2016
Apr 26

If you are working on a website redesign, 404s are the very real monsters under your bed. Ignore them, and they will wreak havoc on your website’s traffic. Worst of all, by the time you realize what’s happening it may already be too late.

What are 404s?

Very simply, 404s are broken links. More specifically, 404 is the HTTP response code for “Not Found,” signifying that a web page is not available at the provided URL. Reorganizing old content, changing old URLs and selectively discarding content that is no longer relevant are all common activities during website redesign projects that can result in 404s.

Why 404s Are so Bad

Your legacy content – the stuff that’s been around for 15 years, from the most up-to-date research articles, to blog posts written by employees long-gone, to PDF files in random folders off your webroot – has been quietly growing your website traffic, catching inbound links and increasing effectiveness of organic search. And the longer it has been around, the more valuable it has likely become, even if the content itself is no longer of much relevance to your organization. A quick scan of your Google Analytics will likely confirm this. Your organic search traffic probably has a very long tail: thousands or tens of thousands of pages with a few hits each, funneling users to your website.

If those URLs change, or that content is abandoned entirely, the potentially massive net you have been casting – and growing – for years will be damaged. Despite the very best user experience, the most on-target messaging and the most compelling design, years of search engine optimization (SEO) progress can be lost – all because of 404s. Your organic search rank will drop as search engines remove the now-broken URLs from their indexes. As a result, traffic will plummet. All of this can very quickly bring the success of your entire redesign project into question.

In website redesigns, 404s may very well be your worst enemy.

Combatting 404s Starts with Content Strategy

Dealing with 404s is an important, often overlooked component of effective content strategy. Communications teams frequently devote significant time to performing content audits, flagging content to be be reorganized, rewritten or abandoned altogether. Far less time – if any – is given to thinking through exactly what to do with content that is left behind. It is simply abandoned. Soon after launch, someone in marketing notices a drop in traffic and suddenly 404s are on everyone’s radar.

By Default, Keep Everything

When redesigning a website, we recommend keeping just about everything. That might be opposite of what you’ve heard before. It doesn’t lend itself to the “cleaning out the garage” or “moving to a new house” metaphors. In reality, though, your legacy content is one of your greatest assets. That junk in the garage is gold. Deal with it, but don’t abandon it.

For outdated content, channel users to more relevant offerings with good user experience design and carefully crafted messaging. Old content – even if outdated – represents an opportunity to connect with users you otherwise might miss entirely, communicating key changes in your organization or pointing to relevant, up-to-date resources. Again, dealing with legacy content is an important element of content strategy. It deserves design attention and good user experience. Craft a simple message that says “This resource is out of date. To see our more recent work in this area, see X, Y or Z.”

For content that is rewritten or moved to a new URL, use 301 redirects to redirect users automatically from old pages to their new equivalents. 301 redirects, or 301s, signal to search engines that a resource has not been eliminated; rather, it has been “Moved Permanently” and should be reindexed at its new location. 301s are hands-down the most important technical device for dealing with 404s.

(Note that 301s do not guarantee that your content will maintain its rank within search results. Rather, 301s indicate to search engines that the resource for a particular URL has been moved. Search engines will queue the new URL for reindexing, and search rank will once again be determined by a broad spectrum of factors like keyword density, page title, inbound links, etc.)

Add 301 Redirects for All Migrated Content

When migrating legacy content into your redesigned website, add a 301 redirect for every single resource, article or page being migrated. As of right now in Drupal 7, a patch for the redirect module makes this process easy: simply map the old URL to the special destination field “migrate_redirects” and the redirect module will take care of the rest.

In Drupal 8, the redirect module provides built-in support for migrating redirects from older versions of the Content Management System. A little bit of custom code in your scripted migration can take care of adding redirects for migrated nodes. (Need more info? Let us know in the comments or get in touch.)

Find and Prioritize All Legacy URLs

While adding 301 redirects for every migrated page is critical, it is not enough. Google has likely indexed large numbers of URLs for content that will not be included in your scripted migration process. Landing pages, listing pages, PDFs and anything you have specifically decided not to migrate will be omitted if your focus is solely on individual articles. To better understand the full scope of URLs that need to be dealt with, download a report of all pages from Google Analytics or whatever analytics platform you are using. This not only provides a thorough catalog of web pages, PDFs and other resources being viewed, but also shows a count of monthly page views and is incredibly helpful for establishing priority for specific pages to be redirected. Remember, your traffic has a long tail; the potentially thousands of pages that receive one or two views per month are still important.

Test All Legacy URLs In Your Redesigned Website

Once you have a list of all legacy URLs you need to test your new, redesigned website to see which URLs are resulting in “404 Not Found” errors. We have a few custom scripts that do exactly that, written in environments ranging from Drupal modules to standalone NodeJS apps. Regardless of the specific implementation, the script needs to do the following:

  1. Import a list of legacy URLs downloaded from your analytics service.
  2. Loop through the list of URLs and test each on the new website to see what HTTP status code is returned.
  3. If a 301, 302 or other redirect is returned, follow it to ensure it eventually results in a URL with an acceptable status (200 OK).
  4. Generate a report of returned status codes. We typically include page views from the originally downloaded analytics report in this CSV so we can see the status code directly beside the number of monthly views for each URL. Seeing the HTTP status code, URL and number of pageviews all side-by-side in spreadsheet format is incredibly helpful for gauging priority.

The first time you run your script, you will likely see a very high volume of 404s. That’s fantastic: you’re seeing them now, during the redesign, before they are anywhere close to impacting SEO or traffic.

Fix the 404s

Your report of returned status codes provides a prioritized list of 404s that need to be dealt with. You will likely see a mix of landing pages, listing pages, articles, PDF files and other resources. Each URL needs to be dealt with.

Often, large numbers of similar URLs can be redirected programmatically – that is, by matching patterns rather than specific addresses. For example, a collection of folders containing PDFs may have been moved to new locations. Or URLs for pages that show content by category may need to be mapped to new category ids. Depending on the complexity of the specific redirect pattern and the environment in which your website is hosted, programmatic redirects can be added to Drupal in a variety of ways, as follows:

Remaining URLs will simply need a single, manual redirect added. The redirect and path redirect import modules are excellent resources for manually adding 301s.

Watch Out for Index.html

If your legacy URLs are directory indexes (i.e. ending with “index.html” or “index.htm”) you will need to add an additional redirect for the version that does not include the file name.

Example: if your legacy URL is “http://example.com/path/to/file/index.html” and the new equivalent is “http://example.com/new/path/to/file”, you will need two redirects:

We typically add additional redirects for directory indexes once all other redirect work is finished, using a simple custom script that scans the redirects table for index pages and generates the appropriate equivalent.

Test Again, Rinse and Repeat

Once all 404s have been dealt with in the ways outlined above, test your redesigned website again. You will likely find a few URLs that still need to be addressed. Rinse and repeat until the entire list of prioritized pages returns the acceptable status code of 200.

Not Quite Done

And that’s it. Almost. The final piece to combatting 404s is to monitor them closely after launch. The redirect module provides a simple admin page for doing exactly that. We strongly recommend monitoring 404s for several days after launch and adding 301s wherever appropriate.

Sit Back and Relax

Website redesign projects usually impact organizations at all levels, and we know you probably won’t be able to truly sit back and relax after launch. There will be final communications details, stakeholder reviews, content updates, ongoing bug fixes and likely a growing list of next-phase wishlist items. That said, dealing with 404s will help protect your investment in organic search and mitigate deleterious effects on web site traffic. There will still be a dip in the numbers as Google and other search engines update their indexes and re-crawl new content. This post doesn’t address SEO strategy in-depth, nor setting specific traffic goals and benchmarks as a part of planning and discovery for your website redesign. It does express the very clear need to accommodate modified URLs and abandoned pages. Without an effective redirect strategy, 404s will almost certainly wreak havoc on your organic search traffic. Good content strategy and 301 redirects are critical allies for fighting 404s and protecting your years-long investment in SEO.

Oct 16 2015
Oct 16

In case you've had trouble tracking it down (I did), the approach to caching custom blocks is different in Drupal 8 than in Drupal 7. In Drupal 8 all renderable arrays are cacheable – including, of course, those returned by custom blocks.

The new and much-improved Cache API in Drupal 8 provides a sophisticated approach to caching all things renderable–whether pages, entities or, for our case, blocks. Whereas in Drupal 7 default cache settings were returned along with other block settings in "hook_block_info()", Drupal 8 allows developers to manage cache behavior for blocks directly in the render array returned by the block object's "build()" method.

In Drupal 7, caching a block by role looks this:

function mymodule_block_info() {
  $blocks = array();
  $blocks['mymodule_example_block'] = array(
    'info' => t('Block title'),
    // Block caching options (per role, per user, etc.)
    // DRUPAL_CACHE_PER_ROLE is the default.
    'cache' => DRUPAL_CACHE_PER_ROLE,
  );
  return $blocks;
}

In Drupal 8, cache settings are manipulated directly in renderable arrays returned by (among other things) a block's build() method:

class MyCustomBlock extends BlockBase {
  public function build() {
    return array(
      '#markup' => $this->t('My custom block content'),
      '#cache' => array(
        'contexts' => array('user.roles'),
      ),
    );
  }

Available parameters for manipulating cache settings include 'keys', 'contexts', 'tags', 'max-age' and 'bin'. Detailed documentation about cache management in Drupal 8 is available on Drupal.org.

Beyond implications for caching blocks (which had me scouring Google when first writing custom block plugins for Drupal 8) there are huge implications for caching everything. In Drupal 8, cache behavior needs to be a consideration when rendering absolutely anything via the render API. More on that on Drupal.org.

Sep 16 2013
Sep 16

Voting is open for two At-Large Director positions on the Drupal Association Board. Responsibilities for board members include providing financial oversight and strategic direction for the DA. Aten's own Matthew Saunders, VP of Project Management, is running for the position. Matthew's combined experience in the non-profit world, Drupal, and the Drupal community make him uniquely positioned to help shepherd the Association.

We fully support Matthew's nomination, and we're looking forward to supporting his efforts on the Board as he helps direct the Association! We hope you’ll choose to support him as well.

May 30 2013
May 30

Last week 9 of us from Aten attended DrupalCon Portland, 2013. With more that 3,300 registrations, this was the largest DrupalCon yet. Our team was privileged to be sponsors, speakers, and co-organizers for the event. As always, there were plenty of incredible sessions, so many people to catch up with, and no shortage of after-parties. Here are a few highlights from the team.

A recurring theme that surfaced in a number of sessions was that of changing processes. Responsive web design has had a huge impact on how we design and develop websites. Jared Ponchot's talk, "Designing on Purpose: Design Process & Deliverables in the Responsive Age", dove into the UX side of designing for a responsive web while Sam Richards and Mason Wendell gave front-end developers lots to think about in their session "Managing Responsive Web Design with Sass and Breakpoint".

I'm extremely excited that Twig is going to make it into Drupal 8. This change will be one of the greatest boons to front-end development for Drupal in years. Jen Lampton has done a fantastic job leading the initiative and it was great to see so many people working on Twig at the code sprints on Friday.

Finally, John, Garrett and I spent a lot of time discussing the future of Center and Prototype, the base and starter themes Aten uses internally to kickstart projects. They're now full projects on drupal.org and we're planning on having a release for each in the coming weeks. Exciting stuff!

It was good to see so many people turn out for the "Drupal DoGooders Happy Hour" that went to benefit Aaron Winborn. A couple rooms full of people were able to enjoy some food and drink, and talk with Aaron and his family via Google Hangout. I think we all appreciated being able to thank Aaron for the years he spent contributing to the Drupal Community and to give a token of our appreciation back to him and his family.

My favorite part of DrupalCon was probably Ashe Dryden's "Programming Diversity" session. I'm sure I wasn't the only audience member hoping Ashe would give us a silver bullet for diversity problems in our industry. Instead, she explained the complexity of the problem and gave us some practical approaches to helping solve it. One of her tips, "Have the hard conversations," I unfortunately had an opportunity to apply while still at DrupalCon, in some hard conversations I might have let pass without Ashe's well-designed slides fresh in my mind.

What an amazing week! Though this was my 5th DrupalCon, it was also my first opportunity to actually be part of a company that had a booth. That was an interesting perspective to the conference from the get go. It was fun to be able to greet people, talk about the awesomeness of Aten, and hand out scout books.

I didn't make it to too many sessions this time around. However, I ran the "Making Drupal Meetups and Events Rock" session with an amazing panel of Drupal contributors. We had great feedback from that session and more questions than we had time to answer.

The other highlight of the week for me was the "Women in Drupal Meet & Greet Reception" on Tuesday night hosted by Aten Design Group and Squishy Media at the Squishy Media offices. Despite the torrential downpour we had an amazing turn out. Women started piling in right around 6pm, and continued throughout the night. Squishy Media had to send the final ladies home around 11 pm. Beyond great networking, events like this do so much to promote women in the community.

For those who didn't catch the featured Coding/Development session, "Development, By The Numbers" was a fantastic look at the long term readability and maintainability of open source projects. The short end of that is Drupal is looking better and better as time passes. The concepts and tools discussed, such as checking cyclomatic complexity with phpmd were invaluable, and I encourage every developer to check it out.

I also had a great time attending a couple of BoFs. One was on non-profits and NGOs, and people expressed frustrations in upgrading distributions, which was extremely valuable given that Aten maintains the OpenAid distribution.

I was delighted at the opportunity to host a BoF on Vagrant, and it was a little awkward given my utter lack of experience in hosting "BoFs"–but I had a blast nonetheless. The Drupal community could use some input from those who have DevOps experience, and I hope to have inspired others to contribute back to the DevOps Drupal group.

I had a blast in Portland. It was great to get a chance to see coworkers face-to-face again after working abroad in Australia for the last 6 months.

I was super excited to see Jonathan Snook present on SMACSS after reading his book a couple times and having presented on the subject myself in the past. He didn't disappoint.

For me, the highlight of the conference was Karen McGrane's keynote, "Thriving in a World of Change: Future-friendly Content with Drupal". Karen's thoughts on structuring content for longevity and flexibility are a fundamental shift in how we view website development. Read her book if you haven't. Drupal is ahead of most platforms when it comes to structured content. However, Karen warned we may be taking a step back with in-place editing features in core. While easy to use, in-place editing leads authors to believe their content will always live within the context of the current page. We should be encouraging authors to look beyond the page.

Since sessions were recorded, I've been catching up on a few that I missed while at the event. "Plugin Haikus" is one of those, and is definitely worth watching for anyone interested in a better understanding of the cTools plugin system–something that's been on my mind a lot lately.

Drupalcon seems to always be as much about kicking with cool folks as it is about sessions, and this round was no different. I especially enjoyed getting to high-five John Ferris in person, as he's been representing Aten in the southern hemisphere since last December.

The front-end track contained some really great content, the highlight for me being Jonathan Snook’s "Scalable and Modular Architecture for CSS". The session was essentially an overview of Snook’s excellent book of the same name, which reaffirmed some of the front-end approaches we’ve been building for at Aten.

The DrupalCon 2013 highlight for me was having so many people from the Aten team in Portland; it’s always a good time when we get out of the office together! We enjoyed watching sessions by our team members, roaming the streets of downtown Portland, trying new restaurants, new bars, and debriefing in our hotel lobby. Ken Woodworth, Aten’s Art Director, flew in from our Rochester, NY office, and John Ferris, Front-end Developer, was able to join us all the way from Australia; it was great to see them!

Spending time at the booth talking to old friends, new friends, and colleagues is always a treat. We shared hundreds of our DrupalCon Portland sketch books, new posters, and great conversation about our work and clients. These times always reinforce my gratitude for being able to work with such a great team doing good work for an amazing client base.

For my part, DrupalCon is always a great opportunity to connect with people – clients, friends, other shop owners, and even colleagues – who we otherwise just don't see very often in person. I had some great conversations and was inspired by the sheer growth in the Drupal community... there are some incredible organizations doing all kinds of great work, and it was great to see that again first hand.

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