La méthode `PharData::extractTo()` est victime d’un bug corrigé en PHP 7.4.15
qui fait qu’elle extrait les fichiers zippés en les laissant compressés !
Heureusement, ce n’est pas le cas sur ZipArchive : on l’utilise de préférence
si la fonction est présente. Et sinon on génère une erreur si on est en PHP < 7.4.15
Refs: #39
Refs: https://bugs.php.net/bug.php?id=69279
Il y a manifestement des soucis dans certaines configuration
de relecture des fichiers. Comme on ne veut pas le faire systématiquement,
car cela serait abusif, on propose une route manuelle pour le faire.
Après une analyse plus approfondie, l’opcache sur certains hébergeemnts,
avec les Phar, pose problème… il n’arrive alors pas à charger les fichiers internes.
Plusieurs contournements :
- désactiver opcache s’il est actif semble suffisant
-- mais on tente d’abord sans le désactiver (parce que après tout ça fonctionne presque partout)
-- on retente désactivé
-- en dernier recours on execute opcache_reset() (bon là c’est très mal, car ça détruit le cache de tout le fpm de l’hébergement)
- require plutôt que require_once évite certains cas particuliers
Ce ce que j’ai vu LWS (un PHP 8.0, apache) nécessite la désactivation de l’opcache
De même que Nginx (PHP 8.2 sur Mamp Pro en local)
Au moins on ne vide pas le cache opcache brutalement maintenant.
Par défaut Nginx se plante sur les chemints `spip_loader.php/index.php` ou
`spip_loader.php/assets/css/all.css` car il cherche directement l’existance de 'index.php'
par exemple…
On évite donc d’avoir des Urls de la sorte en ne redirigeant pas sur `/index.php`
et en passant les assests/ via ?file=assets/...
+ Le debug affiche des informations en pied de page.
- Parfois le rewrite du phar ne reçoit pas le chemin du fichier recherché !
- Parfois aussi PHP_SELF n’est pas correctement rempli (cette fois il manque le contenu de PATH_INFO dedans)
