Updated on June 15, 2022

This post is based on a talk I gave at DrupalCon Barcelona and this year at MidCamp. You can see a video version of the talk below.

I needed to create a new webform on a production site recently. But as a dev, I don't have direct access to the production admin backend; I'm only allowed to push code changes and let the client's team migrate them to prod via drush updb. So I'm supposed to export the webform configuration to code, and deploy it via an update hook, but how?

If you have a Drupal multilingual website, you've probably heard about the Entity Translation module, a module that allows you to translate fields in Drupal, instead of translating nodes. This means that instead of creating a node, taxonomy term, and user for each language on your site, you can create a single entity and translate the fields on it. The Entity Translation module includes a submodule that helps you upgrade to this new translation method.

The Web Experience Toolkit distribution of Drupal (aka WxT-Drupal, wetkit, or wet-boew) is a version of Drupal designed for organizations with a bilingual and accessibility requirements. Specifically, it's designed for Canadian government and public organizations. It has built with support for English and French, and includes a theme that provides accessibility and responsive support.

In part 1 of this tutorial, I covered how to make your own custom field and widget. Here I'll cover how to validate that input and format it using a custom formatter.

The power of Drupal stems from our ability to customize it. One common requirement is the need to define complex fields with custom widgets and formatters that are unavailable in core or contributed modules. This allows us to collect more sophisticated data from users, and define exactly how that data is presented. Drupal's Field API provides the hooks needed to make just about any field we want.

We often define custom blocks in a site-specific module. Sometimes the markup in these blocks can start building up and we realize that it's time to create a template for the block. This is a good way to keep markup out of the module code. It's also a good way to practise writing cleaner and more themer-friendly modules.

Lately, we have been involved in a project where our clients needed a site capable of serving a large number of anonymous users and a reasonable number of concurrently logged in users. In order to reach these goals, we looked to the cloud. I'll give a quick overview of our configuration using nginx, boost, apc, cacherouter, memcached, and glusterfs. This has allowed us to scale up considerably.

Building a comprehensive information architecture for a content-heavy website can be a challenge. Luckily, Drupal is great for rapid development and by building content types early on, it's easier to discover issues with either the content, design, or architectural decisions.