- 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 http://france3-regions.francetvinfo.fr/ : who said Drupal back-offices had to be slow ?
- 2014-02-07: Sotchi Olympics traffic not a problem for http://www.francetvsport.fr/ , 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
- 2010-12-21: Madame Figaro brand new site by OSInet and others
- 2010-08-16: France.FR is back online with OSInet and Typhon
- 2010-06-15: the new France Culture, which OSInet helped reach its performance goals, is now online
Grokking Drupal, Drupal tips and tricks, DRUPAL-4-7, DRUPAL-5, DRUPAL-4-6, DRUPAL-6, drupal, DRUPAL-7, drupalcon, DRUPAL-8, DrupalDevDays
So your site has been hacked ? Or more likely you wonder what to do when it eventually happens : the video for my "Life after the hack" is now available. From initial diagnosis to return online, with a healthy dose of forensics along the way.
The slides are also available for easier access, but of course absent the extra speaker comments :
When you use Drush, especially in crontabs, you may sometimes be bitten by RAM or duration limits. Of course, running Drush with the "-d" option will provide this information, but it will only do so at the end of an annoyingly noisy output debugging the whole command run.
On the other hand, just running the Drush command within a
time command won't provide fine memory reporting. Luckily Drush implements hooks to make acquiring this information easily, so here is a small gist you can use as a standalone Drush plugin or add to a module of your own:
On behalf of all contributors to the MongoDB module suite for Drupal over the years, I am pleased to announce the 8.x-2.0-alpha1 release of the MongoDB package for Drupal 8, six years after we started this project on Drupal 6.
This release is the first step to an initial stable release of the MongoDB package for Drupal 8, containing:
mongodba module exposing the new PHP library as Symfony services exposed to a Drupal 8.x instance. It is designed as a minimal and consistent connection layer on top of the PHP library for MongoDB, for all modules targeting MongoDB on Drupal 8.x, be they contributed or bespoke.
mongodb_watchdoga PSR-3 logger storing event data in MongoDB. On top of the features already present in 6.x and 7.x versions, it introduces a per-request report showing all events logged during a request, in order.
When running tests on a server using the recent versions of the MongoDB module for Drupal, and more specifically the MongoDB simpletests, the simpletest runner may leave droppings in your MongoDB Drupal database, which have no business remaining there. How to remove them while keeping the good collections ?
The typical case will be after a failed test runs, looking like this:
One of the big trends during the Drupal 8 creation has been the replacement of info hooks by two main mechanisms: annotations, and YAML files. In that light,
hook_drush_command(), as the CLI equivalent of the late
hook_menu, replaced by various YAML files, looks just like a perfect candidate for replacement by a
commands section in some
mymodule.drush.yml configuration file. Turns out it is incredibly easy to achieve. Let's see how to kill some hundred lines of code real fast !
UPDATE 2015-12-04 : Tinytest is now documented, for the upcoming Meteor 1.3 release. See the official README.md. Better use the official information than my unofficial cheatsheet.
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 ?