Six months ago, Drupal's evaluator experience was complex, time-consuming, and frustrating. That's changed dramatically.

I previously published an article in which I compared the evaluator experience for Drupal against that of Wordpress, Symfony, and Laravel. I attempted to get a new "Hello World" site up and running in each of the four different PHP frameworks and recorded a few statistics.

The documentation initiative was announced at DrupalCon Nashville nearly four months ago. In his keynote, Dries’ highlighted my blog post, in which I provided statistics and anecdotes about the challenges of Drupal.org’s documentation and evaluator experience. The documentation initiative aims to address these challenges. What’s happened since then?

I recently performed an experiment in which I attempted to emulate the experience of a Drupal evaluator. I highlighted a few glaring pain points and shared my experience and conclusions in a blog post: Stranger in a familiar land: Comparing the novice's first impression of Drupal to other PHP frameworks.

Drupal 8 adoption is flagging. Why? I tried to lay my biases and assumptions aside and set out to find the answer. What I found surprised me.

I decided to perform an experiment. Placing myself (as much as possible) in the shoes of a senior developer without any Drupal experience, I attempted to get a new "Hello World" site up and running in four different PHP frameworks: Wordpress, Laravel, Symfony, and Drupal.

I set a few ground rules for myself:

LogicException: The controller result claims to be providing relevant cache metadata, but leaked metadata was detected. Please ensure you are not rendering content too early.

Some methods of URL generation cause accountability metadata to be rendered too early, resulting in a fatal error. The solution is to generate the URL differently:

This function will convert a PHP array of nested CSS selectors into a CSS string. Nesting comes in handy with SASS rules or nesting standard CSS within media queries.

If you'd like to define a few super-simple custom panels pane styles, here's the bare bones code.

In a custom module:

<?php 
/**
 * Implements hook_ctools_plugin_directory().
 */
function grasmash_panels_ctools_plugin_directory($module, $plugin) {
  if ($module == 'panels' && $plugin == 'styles') {
    return 'plugins/' . $plugin;
  }
}
?>

In plugins/styles/gold.inc:

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:

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: https://www.previousnext.com.au/blog/using-behat-and-drupaldriver-beware-pathauto

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.

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.