Tech Articles

PHPCS most recent commit

I recently worked on a site with a tremendous amount of technical debt and wanted to set up code validation for the project. Fixing all of the code violations up front would have been prohibitively time consuming, so I decided that we should do it gradually. Each time that a developer made a change to a file, that particular file would be code sniffed. I wanted to enforce this rule with a check that would be run by our continuous integration server. Here is the command that I came up with:

git diff-tree --no-commit-id --name-only -r HEAD | xargs ./vendor/bin/phpcs -v --standard=./vendor/drupal/coder/coder_sniffer/Drupal/ruleset.xml --extensions='module,inc,install,profile,test,info'

If you'd like this to apply only to a specific directory, like */modules/custom, pipe the changed files through grep:


Apparently MAMP's version of cURL doesn't ship with the ca-cert bundle, which can cause your cURL request to HTTPS resources to throw errors like this:

curl: (35) error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure

To solve this, you can re-compile MAMP's cURL binary. I found partial instructions here, but had to perform a few extra steps. All steps documented below:

Drupal Lock Stampede

When a Drupal site begins to be overwhelmed by high volumes of traffic, one of the worst bottlenecks is Drupal core's menu system. A menu rebuild during high traffic can easily causes a stampede on your database, which is exacerbated by the architecture of core's Lock API.

The order of operations that leads to the stampede behavior is as follows:

Behat is exploding with Fatal require errors

If you're getting fatal errors due to missing, required files, there's a good chance that you're running into the issue described here:

In short, a menu rebuild is being called from outside of the Drupal root, thereby exploding your registry. For me, this was caused by views_content_cache, which calls views_invalidate_cache() and triggers a menu rebuild after certain entity operations. Here's how I got around that.

In your featureContext.php file's __construct() function, add:

Rendering the same for twice leads to incorrect submission

If you render the same form (with the same exact form id) on the same page more than once, Drupal will incorrectly submit all matching forms on the page to the first-rendered form. To avoid this, you must create dynamic form ids. This can be achieved by using hook_forms() to map dynamic form ids to the appropriate callbacks.

Here's an example from the usasearch_field module:

Push and submit Pull Request alias

This alias allows you to push the current branch to origin and submit a pull request the integration branch in just three characters:

alias gpr='git push origin $(git rev-parse --abbrev-ref HEAD) && hub pull-request -b integration -m "$(git log -1 --pretty=%B)" -o'

If you don't already have the hub command available, be sure to install it.


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)--each with 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. The solution is the Local Path Ignore module. It ignores the language of a given path, and instead forces all paths to have a language of "undefined," effectively allowing path aliases to behave the way you'd expect--one path per node.