Tech Articles

Remove language from all Drupal aliases

Drupal's locale module includes a lot of great features for supporting multilingual sites. One such feature is the ability to associate a language with a path alias. This allows you to have one node with two versions, let's say an English version and a Spanish version. This permits each version to have its own alias.

But your use case may not require language-specific paths per node. Maybe you want to call a spade a spade-- you've got a Spanish node or and English node and that's it. No fancy multiple versions.

Well then you've got a bit of a problem--a few actually. This can wreak havoc with aliases, and pathauto in particular. So here's a snippet that essentially neuters Drupal's ability to assign different languages to paths:

* @file
* Code for the DOJ Translation feature.

Provision Zombie.js on Ubuntu via Vagrant

Simple snippet to install Zombie JS on Ubuntu via Vagrant

# Install Zombie.js for Behat javascript testing.
exec { 'node-add-repo':
command => 'add-apt-repository ppa:chris-lea/node.js',
unless => 'apt-cache policy | grep chris-lea'
package { [ 'nodejs' ]:
require => Exec['node-add-repo'],
ensure => present
exec { 'zombie-install':
# Behat 2 requires Zombie <= 1.4.1
# Behat yml file should specify:
# zombie:node_modules_path: /usr/lib/node_modules/
command => 'npm install [email protected] --global',
require => Package['nodejs'],
creates => '/usr/lib/node_modules/zombie'

Behat step: Get IE version

   * Determines whether the current browser is Internet Explorer.
   * @return int
   *   If the browser is IE, the IE version will be returned. Otherwise, -1.
public function getIeVersion() {
$ie_version = $this->getSession()->evaluateScript('

Maintaining your installed Drupal distro provides a number of pre-packaged distributions (e.g., Drupal Commons, DKAN, etc.) that allow users to get a fully-featured Drupal installation up and running in no time, but maintaining an installed distribution can be tricky. You may need to juggle distribution updates with contrib module updates, core updates, and your own customizations. If you aren't careful, it can become a maintenance nightmare!

The Drupal community has a few tools for dealing with common maintenance problems, but you'll be hard pressed to find comprehensive documentation on the matter. This blog post will make an attempt to codify best practices for maintenance of an installed distribution.

Let's start by establishing some goals. In maintaining an installed distribution, I'd like to:

Introducing Views Cache Bully: You're gonna cache your views, and you're gonna like it.

views cache bully admin settingsTucked away under the Views UI's "advanced" fieldset is a too-seldom-used option: Views caching. It allows you to cache the query results and/or rendered markup for any given view. This can drastically improve your site's performance.

Unfortunately, many people don't use this option. Maybe they don't know about it, maybe they've forgotten about it, or maybe they don't like it. Well, the Views Cache Bully module is here to say "Too bad. You're gonna cache your views, and you're gonna like it."

To quote Dave Stoline (dstol):

CapitalCamp Presentation: Building an API (that people will actually use)

Uploading a copy of the CapitalCamp 2013 presentation given by David Platek and me:

If you attended the presentation, please feel free to leave feedback below!

Presentation description:

Learn why and how to expose your Drupal installation’s data and functionality via an API, and entice developers to extend your application’s reach through supportive documentation, implementation examples, and even SDKs.