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 ?

Logging for MongoDB

One nice thing during Drupal 7/8 development is the ability, thanks to the devel module, to get a list of all SQL queries ran on a page. As I've been working quite a bit on MongoDB in PHP recently, I wondered how to obtain comparable results when using MongoDB in PHP projects. Looking at the D7 implementation, the magic happens in the Database class:

// Start logging on the default database.
define(DB_CHANNEL, 'my_logging_channel');

// Get the log contents, typically in a shutdown handler.
$log = \Database::getLog(DB_CHANNEL);

With DBTNG, that's all it takes, and devel puts it to good use UI-wise. So is there be an equivalent mechanism in MongoDB ? Of course there is !

Tip of the day: Standalone DBTNG outside Drupal

A few days ago, while I was writing a bit of Silex code and grumbling at Doctrine DBAL's lack of support for a SQL Merge operation, I wondered if it wouldn't be possible to use DBTNG without the rest of Drupal.

Obviously, although DBTNG is described as having been designed for standalone use: DBTNG should be a stand-alone library with no external dependences other than PHP 5.2 and the PDO database library, in actual use, the Github DBTNG repo has seen no commit in the last 3 years, and the D8 version is still not a Drupal 8 "Component" (i.e. decoupled code), but still a plain library with Drupal dependencies. How would it fare on its own ? Let's give it a try...

The Drupal Block system from drop.org to Drupal 8: video from DrupalCon Prague

So DrupalCon Prague is almost over, and I can now share with you the video of my session about the history of the Drupal block system, from drop.org to Drupal 8, just as recorded on wednesday.

The session page is available on https://prague2013.drupal.org/session/blocks-drop.org-drupal-8-and-beyo… where you can also rate it. Please to it over there, or add your comments here: it is very useful for me to see what needs to be adjusted for upcoming presentations. Based on the overall feedback, it seems that:

Rethinking watchdog(): logging in Kohana 3

Continuing this exploration of logging solutions used in various projects, let's look at logging in Kohana 3.

Kohana 3.3 Logging - bundled classes While Monolog and log4php share a mostly common logging model of a frontal Logger object instantiated as many times as needed to supply different logging channels, in which log events are Processed/Filtered then written out by Handlers/Writers, Kohana builds upon a simpler model, which can be summarized by three patterns:

  • Singleton: there is only one instance of the Kohana Log
  • Observer: Log_Writer instances are attached (and detached) to(/from) the logger instance and handle events they are interested in based on their own configuration. Much like a Drupal hook, all writer instances receive each Log event
  • Delegation: the Log exposes a write() to trigger the buffered writing, but does not implement it itself, but delegates to the Log_Writer objects to perform it. Buffered logging control is a Log property, not a Log_Writer property.

Rethinking watchdog(): Monolog vs log4php

Beyond Monolog, other packages provide advanced logging services. Apache log4php is another well-known logging solution, used (among others) by CMS Made Simple, SugarCRM, and vTiger CRM.

It is based on the famous log4j package from the Java world, and from uses of this package I have seen on customer sites, I feel that it carries a lot of useless baggage, and is - in my opinion - significantly less of a good match than Monolog for Drupal 8.

Monolog vs log4php : equivalences

There is some degree of equivalence between the Monolog and log4php components:

Purpose Monolog log4php Notes
Log an event Logger Logger Very similar
Store an event Handler Appender both can be chained, group, control bubbling (Monolog) / filtering (log4php)
Format an event representation Formatter Layout log4php layouts can format a group of events, Monolog formatters format an individual event
Massage event data Processor Renderer Not so similar. Monolog processors will often add extra data, while log4php Renderers are typically used to format non-string events as strings.