- 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
When PHP won't find existing source files
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 ?
On the current Jessie build, this happens in line 436 of select_lang.lib.php, which just does
require_once GETTEXT_INC. It didn't seem much, so I looked it at it: a simple
echo GETTEXT_INC showed that the file wass expected to be found in the same
- Check disk: file is there. Hmm...
- check if it can be found in PHP using the basic
realpath()returns the absolute path normally.
is_readableboth return true.
- Use the same
is_readable()in the PhpMyAdmin code : realpath() return empty, and the two checks return false. WTF ?
So, the file is there, PHP CLI can read it, but PHP mod_apache can't. Looks like a
php.ini difference, maybe
open_basedir ? Nope, it's empty in both. What can it be ?
Actually, it turns out
open_basedir is indeed set (and problematic) within the PhpMyAdmin configuration, although the
php.ini configurations are the same. It is set within the Apache / PhpMyAdmin integration in
php_admin_value open_basedir /usr/share/phpmyadmin/:/etc/phpmyadmin/:/var/lib/phpmyadmin/
We have a culprit ! The restricted basedir prevents PhpMyAdmin from loading the required file. Let's add the reference PHP directory to that list
php_admin_value open_basedir /usr/share/php/:/usr/share/phpmyadmin/:/etc/phpmyadmin/:/var/lib/phpmyadmin/
Issue fixed !