The opening talk as DrupalCamp Paris 2019 was a presentation given by Thomas Jolliet (FranceTV) and yours truly about how we rebuilt FranceTV Sport to a Symfony 4 / headless Drupal 8 combo.
The most salient points of the talk are probably the "defense in depth" mechanisms we built for scalability and fault tolerance, and the business results, like -85% full page load time, -65% speed index, or +50% iOS app traffic.
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:
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:
LogLog_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 eventLog 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.
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. |
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.
Now that Drupalcon Chicago is over, I found some time to fix the slides from my session at the Drupal Dev Days in Brussels. It took some time because neither Google Presentations nor Slideshare apparently like the MgOpen font family.
The presentation is now on Slideshare at http://www.slideshare.net/fgm-osinet/drupal-views-development.
The progressive code samples are attached to this blog entry, as a tarred Git repository.
If you haven't been able to attend DrupalCon Paris, or missed the session I led on Views for developers there, you can find its first part on archive.org:
Roughly two years ago, I prepared a diagram of the dependencies in the then-current version of Drupal e-Commerce (eC) for Drupal 4.6.
Now, with other eC projects looming ahead, a
possible session about eC at Szeged,
and eC 4 being in alpha, I figured it was time to update the model. Boy, has it changed ! Click the thumbnail for the full-size view.