- 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
PHP Tips and tricks
The problem: packages.drupal.org broken
I was starting my weekly work for the Drupal GraphQL module by the customary
composer update --prefer-source -vvv command, ready to watch composer spit out some hundred lines sipping my coffee, but this time something turned out to be wrong:
The "https://packages.drupal.org/8/drupal/provider-2016-4%24a30289dd8394e5271bd77777bb14b361c5938656f1cddad7fae1c00d5d6ba9c6.json" file could not be downloaded (HTTP/1.1 404 Not Found)
OK, so packages.drupal.org is down for now. How can we work around this ?
There are a number of issues on StackOverflow and elsewhere about the problems met when upgrading to PHP 7, so when I upgraded a Debian Wheezy server this week, I only upgraded to Jessie with its standard 5.6 version, not expecting problems. But of course, there had to be this mystifying error which seems to be most often associated with PHP 7.0 : like Debian bug 709302:
[Wed May 22 14:20:26 2013] [error] [client 127.0.0.1] PHP Fatal error: require_once(): Failed opening required './libraries/php-gettext/gettext.inc' (include_path='.') in /usr/share/phpmyadmin/libraries/select_lang.lib.php on line 389 [Wed May 22 14:20:26 2013] [error] [client 127.0.0.1] PHP Fatal error: /require_once(): Failed opening required /'./libraries/php-gettext/gettext.inc' (include_path='.') in //usr/share/phpmyadmin/libraries/select_lang.lib.php on line 389 [Wed May 22 14:20:26 2013] [error] [client 127.0.0.1] PHP Fatal error: require_once(): Failed opening required './libraries/php-gettext/gettext.inc' (include_path='.') in /usr/share/phpmyadmin/libraries/select_lang.lib.php on line 389
So how do we fix this for 5.6 ?
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
// Start logging on the default database.
// 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 !
While porting (well, actually rewriting) an old PHP library to Go, I had to use a CRC (cyclic redundancy check) on a buffer. In old-school PHP, the standard is well established since PHP 4: just use
crc32 from the
strings package, and beware of the sign bit or, to be a bit more current while still compatible, use the
hash() function from the
hash package, like this example:
Call a method on a nil pointer (null object) ? This is a classical bug. What if it somehow turned out to be a valid and useful construct in some languages, say in Go ? And what about PHP ?
Among the interesting features of Phing is its extensibility, and of the hallmarks of that exensibility is the ability to define new
Task types as PHP classes, which are by default located in the default namespace only. Can we do better ?
Step 0: "Ad-hoc" (inline) tasks
At the simplest,
Task classes are created by embedding ad-hoc tasks like:
Some of the features in PHP may be surprising. Think for instance of the way PDO is able to create classed results, place the query results into them, and only then invoke the constructor when using
PDO::FETCH_CLASS fetch mode without the additional
PDO::FETCH_PROPS_LATE. Every wished you could do this in userland code ? Turns out this has long been possible, and is even simpler since PHP 5.4.
I was checking a bunch of Behat features left by former developers on a project, and noticed that the Rake rule to run them looked like:
$ behat -c config/behat.yml features
But this looked suspiciously like defaut options. How about running them more simply like just
$ behat ? Alas, this would throw something like: