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

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.

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:

I've been discussing Monolog in Drupal events (DrupalCamp Lyon, DevDays Barcelona) as a possible alternative to the legacy Drupal watchdog() service for quite some time, but never took the time to explain it in writing, and the feature freeze date is looming ahead, so since I'm taking part in th Gent code sprint, and code has been starting to take shape here, here, and there, here is an overview of the Monolog classes.

The diagram below is a simplified version of the Monolog architecture. It includes all classes and interfaces, but only the most significant methods, no constants, and none of the non-bundled classes and interfaces upon which some of the builtins depend.

If you have been wondering about the general organization of Field API in D8 and did not take time to work yched's existing D8 Field API sandbox, here is a simplified and cleaned-up version of the currently envisioned class and interface set.

Over the last few days, I finally decided to revisit the old OSInet PHP library, to dust it off somehow, and convert the class-based parts to PSR0 and the whole to what seems to be liable to become PSR1 at some point.

This library contains a zoo of function helping with PHP-GTK development, and three packages with their demo application:

Class Grapher

Build a graph of inheritance and interface implementations on a directory (and subdirectories) of PHP code

This package uses the Drupal Grammar Paser to parse code, and includes a Drush 5 plugin for easy use within a Drupal site, but can also be used to parse non-Drupal code, as long as the Grammar Parser - which does not depend on Drupal either - is installed in the include path.

It is a more complete version of the Drupal-only Class Grapher sandbox on drupal.org.

In the current version, graphs are generated using GraphViz. An extension to a client-side visualization tool like the Infovis toolkit should come someday. Suggestions for other client-side libraries welcome (please comment!).

Open Document Calc reader

This package provides a few classes and methods to extract the content of OpenDocument (LibreOffice, OpenOffice.org, ...) spreadsheets.

Finite State Machine

This package is used to build applications designed around a finite state machine, and is mostly intended for use in PHP-GTK applications, to provide asynchronous processing.

The demo application uses the PHP FTP extension to expose its asynchronous notifications in a PHP-GTK UI

Coming back from yesterday's first Drupal 8 core code sprint in Paris with lifted spirits from the event, I has a rather disturbing surprise awaiting me on this Drupal (and music) blog: there, on the comment approval queue, stood a single comment on an old blog post for Planet Drupal, authored by someone supposedly called "Johnson" and supposedly writing from "remo2301@gmail.com":

I recently decided to actually run the examples in David Herron's Node Web Development book (disclaimer: Amazon affiliate link) and, while all examples until the middle of chapter 4 worked with the current Node 0.6.14 version, the Connect examples rely on the Router middleware, which TJ Holowaychuck removed from Connect.

Of course, Connect 1.6.1 still contains the Router, but it only works from Node 0.4.1 included to 0.5.0 excluded. And I still wanted to see these examples run on a current Node. A simple (and dirty) hack did the trick:

Unfuddle is a very convenient and fairly cheap SaaS hosted Redmine (with extensions) and SVN/Git, which I use regularly on customer projects. Their service includes reassuring "Backup" options, going as far as to include the ability to backup to your own Amazon S3 bins in addition to their local backups.

Recently, however, I had to go back to an archived project for which I had dutifully taken a dump before closing it on Unfuddle, and looked for a way to restore it to my Unfuddle account. To no avail. Unfuddle support then kindly confirmed that the service did include a backup feature, but no restore:

Backups of projects within Unfuddle are for personal use only and cannot be restored into accounts via the interface. This however may be possible with some custom scripting on your part and with the use of our API (http://unfuddle.com/docs/api).

So the scenario is this: you notice that you are no longer able to login on your Drupal site:

• the {users} table entry for your account looks just fine
• the login and access timestamps on your account are just a few seconds old, matching your latest attempt to login
• you reset your password in the DB, just in case, and it still does not work
• the telltale is that Drupal will not even tell you your login failed: it actually works, as the {users} table shows, but yet you are not logged in

Can you guess what can have been going wrong and fix it ?

mysql -BNe 'SELECT COUNT(*) FROM TABLES' information_schema