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


How to access the mount point without a slash in Silex mounted routes

The problem: routing /blogs, not just /blogs/ in Silex

Route mounting in the Silex PHP framework allows conveniently grouping controllers per feature in separate files, then using mounting them on some prefix path like $app->mount('/blogs'). This will prepend the prefix "/blogs" to the paths defined in the the feature controller, effectively delegating to it all the /blogs/* routes. However, as the Silex documentation claims:

When mounting a route collection under /blog, it is not possible to define a route for the /blog URL. The shortest possible URL is /blog/.

This means handling the route mount point has to be done by a route outside the mounted feature, which makes it slightly less clean, as you have to do something like:

= require_once __DIR__ . '/controllers-blog.php';
// This will handle /blogs/ and below, but not /blogs
$app->mount('/blogs', $blog);
// So we have to use a non-mounted route from a sub-request to avoid a redirect().
$app->get('/blogs', function () use($app) {
// forward to /blogs/
$subRequest = Request::create('/blogs/' , 'GET');
$app->handle($subRequest , HttpKernelInterface::SUB_REQUEST);

But is there really no workaround for this limitation ? Sure 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...

Profiling Silex controller actions in the Web Profiler timeline

The WebProfilerServiceProvider brings the Symfony Profiler to Silex apps, and with it the nice "Timeline" feature, detailing for each request cycle the time spent handling each event dispatched by the EventDispatcher, from kernel.request to kernel.terminate, with detail time spent in each individual listener.

The timeline looks like this one:

This is all nice and well, but there is a problem with this timeline: although the beginning and end of the request cycle is profiled in depth, it represents less than half of the total time spent for this request.

More than half of the total request time is spent in the controller, and this example does not even perform any database access, which would make the controller represent event more of the total time, making the detailed analysis of the beginning and end of the request cycle less relevant.

What would make sense would be to subdivide the time spent in the controller in much the same way the time spent in the event listeners is already plotted. Is there a simple way ? Sure: let us see how the profiler works.

Syndicate content