Latest sites

  • 2017-11-26: New Drupal 8 site at Rue du Commerce, architected and tech-led by OSInet, just went throught Black Friday week with flying colors thanks to RabbitMQ
  • 2017-05-26: New headless Drupal 8 / Symfony 3 site at FranceTV Sport, architected and tech-led by OSInet, with RabbitMQ
  • 2017-02-20: New Drupal 8 site galaxy (+/- 70 sites) for Agences Régionales de Santé architected and tech-led by OSInet, delivered by Klee
  • 2015-08-21: 50% less server load with MongoDB on the Drupal 7 site factory at France Télévisions
  • 2015-07-15: Our first Drupal 8 production site at France Télévisions is live
  • 2014-08-18: 400% speedup in 3 weeks for : who said Drupal back-offices had to be slow ?
  • 2014-02-07: Sotchi Olympics traffic not a problem for , which I rearchitected on Drupal 7 in 2013
  • 2011-09-14: Completed migration of FranceInfo.FR from SPIP to Drupal
  • 2011-07-13: The new social network features of Le Figaro are now powered by an OSInet-designed MongoDB implementation

Quick news

  • 2014-03-27: MongoDB Watchdog module ported to Drupal 8 at the Szeged Dev Days.
  • 2014-01-26: My post on the Symfony web profiler in Silex selected in Week of Symfony. w00t !
  • 2013-10-18: My first commit went into MongoDB today. And, guess what ? It's in JavaScript
  • 2013-09-20 to 29: Working on Drupal 8 EntityAPI at the extended code sprints during and around DrupalCon Prague
  • 2012-08-19: Working on Drupal 8 EntityAPI at Drupalcon Munich
  • 2012-06-15: Working on Drupal 8 EntityAPI at DrupalDevDays Barcelona
  • 2012-03-23: Working on the future Drupal Document Oriented Storage at DrupalCon Denver. D8 or later ? Bets are on Later

Drupal 8 tip of the day: autoloaded code in a module install file

(updated 2017-08-30, see bottom of post). Autoloading in D8 is much more convenient that in previous versions, however, it still has limitations. One such issue is with hook_requirements(), which is supposed to be present in the module install file, not the module itself: when called at runtime for the site report page, the module is loaded and the PSR/4 autoloader works fine. However, when that hook is fired during install to ensure the module can indeed be enabled, the module is not yet enabled, and the autoloader is not yet able to find code from that module, meaning the hook_requirements('install') implementation cannot use namespaced classes from the module, as they will not be autoloadable. What are the solutions ?

The bad

The first solution is obvious but painful : since the file layout within the module is known at the time of committing, it is possible to avoid autoloading using require_once for each class/interface/trait needed by the code, typically like this:

// to male \Drupal\mymodule\Some\Namespace\Class available in mymodule_requirements().
require_once __DIR__ . '/src/Some/Namespace/Class.php';
// ... for each such class

The good

But there is a better way: just make the classloader aware of the module being installed:

// Not needed at runtime.
if ($phase === 'install') {
$module = 'mymodule';
drupal_classloader_register($module, drupal_get_path('module', $module));

During module enabling, its path is already known, so drupal_get_path can be used. With this little help, the module autoloaded code will be available during the install, and allow the hook_requirements() implementation to use it.

The ugly

One obvious temptation would be to put the hook_requirements() implementation in the module file, reasoning that, since if is in the module file, it implies that the module is available when the hook is fired. And indeed, this works for hook_requirements('runtime').

However, during install, the module is still not loaded, so the implementation for hook_requirements('install') is simply not found and the requirements check is ignored. Don't do it.

UPDATE 2017-08-30

On, this issue is referenced, and the practice described above is discouraged, because registering classes with the autoloader MAY cause undesired side-effects if the module installation fails. If the install may fail, the officially sanctioned practice is to use direct require_once(__DIR__ . '/..(relative path to classes'; for each class needed during install.

Check for current details.