PHP

• https://www.php.net/manual/fr/tokens.php
• https://www.php.net/manual/fr/langref.php
• https://stitcher.io/blog/php-8-nullsafe-operator

Un problème assez inquiétant que j’ai découvert. J’ai 2 dokuwiki installé chacun dans leur répertoire respectif et pour une raison douteuse, l’accès aux wiki génère des erreurs 500.

et voici les logs d’erreur

Si je vais sur le WIKI_A j’obtiens

PHP Fatal error:  require_once(): Failed opening required '/var/www/WIKI_B/vendor/composer/autoload_real.php' (include_path='.:/usr/share/php:/usr/share/pear') in /var/www/WIKI_A/vendor/autoload.php on line 5

Si je vais sur le WIKI_B j’obtiens

PHP Fatal error:  require_once(): Failed opening required '/var/www/WIKI_A/vendor/composer/autoload_real.php' (include_path='.:/usr/share/php:/usr/share/pear') in /var/www/WIKI_B/vendor/autoload.php on line 5, referer: http://wiki.edmc73.com/

On constate que le code du wiki fait un require_once sur un fichier de l’autre wiki..

Analysons le code du fichier autoload_real.php

require_once __DIR__ . '/composer' . '/autoload_real.php';

Riens de sorcier, on dirait que DIR renvoit n’importe quoi, le test suivant est pourtant correct

echo __DIR__ . '/composer' . '/autoload_real.php';

Le bon chemin est retourné, donc pourquoi le chemin est mauvais lorsqu’il est appelé dans un require_once ??

Après des heures de galères, j’ai trouvé la réponse ici : https://forum.nette.org/en/27363-one-nette-application-tries-to-touch-files-in-another

Il s’agirait du module de cache opcache de php qui provoque ce bug.

Solution :

Installer xcache

apt install php5-xcache

et désactiver le module php5 opcache

php5dismod opcache

Maintenant tout fonctionne correctement ou presque… j’ai encore eu le problème avec xcache, en le disactivant, plus de problème mais plus de module de cache.

Au final j’ai décidé de comprendre le fonctionnement du cache pour résoudre complètement le problème.

Pour en savoir plus sur opcache ⇒ https://www.ekino.com/php-comment-configurer-utiliser-et-surveiller-opcache/

J’ai installé un petit script php qui permet de surveiller le fonctionnement d’opcache

• https://github.com/carlosbuenosvinos/opcache-dashboard

1er constat: “cache_full = true” le cache de 64Mo par défaut est déjà plein, ce qui pourrait expliquer un dysfonctionnement aléatoire…

Si le problème revient, il faudra essayer d’activer l’option

opcache.revalidate_path=1