Nous venons d’ajouter sur notre plateforme les versions 8.0 et 8.1 de PHP.
Rendez-vous sur Ouvadmin pour sélectionner l’une de ces versions. Rien d’autre à faire … en cas de dysfonctionnement sur le site, il suffit de revenir à une version de PHP antérieure (il faut compter une trentaine de minutes pour que le changement soit effectif).
Si vous ne savez pas ou plus comment faire, consultez la documentation dédiée aux changements de versions de PHP.
Il est recommandé de vérifier, avant de changer la version, que votre site utilise bien un logiciel compatible avec PHP 8.
Idéalement il faut mettre à jour votre CMS (Wordpress, SPIP, Joomla etc) ainsi que tous les plugins et thèmes, avant de modifier la version de PHP !
Nous ajouterons fin novembre la version 8.2 qui va prochainement être publiée par PHP.
Nous allons également supprimer définitivement les versions obsolètes de PHP (5.6, 7.1, 7.2 et 7.3) de nos serveurs pour améliorer la vitesse de mise en ligne de vos nouveaux espaces web et la vitesse de bascule d’une version de PHP à une autre.
Un petite subtilité si vous utilisez Joomla 4, il faut modifier les deux fichiers libraries/src/Filesystem/Folder.php et libraries/src/Filesystem/File.php pour y remplacer les occurrences de :
@set_time_limit(ini_get('max_execution_time'));
par :
if (function_exists('set_time_limit')) {
@set_time_limit(ini_get('max_execution_time'));
}
La comportement de l’opérateur de contrôle d’erreur @ n’est plus le même en PHP 8, ce qui provoque sur notre plateforme une erreur bloquante sur Joomla 4 en PHP 8.x, sans ces modifications.
Bonjour,
À noter aussi que Dolibarr 16 n’est pas encore pleinement compatible avec PHP 8.0 et 8.1. Il faudra attendre Dolibarr 17 à priori.
Merci pour l’upgrade
Bonjour à tous,
Deux compléments si ça peut aider :
Curieusement, l’erreur set_time_limit survient en version 8.X, même avec Joomla 3.10… et la correction conseillée est efficace. Merci Matthieu !
Pour ceux qui utilisent le composant Akeeba Backup de Joomla, il faut faire les mêmes corrections dans les fichiers de même nom dans le dossier libraries/vendor/joomla/filesystem/src/
Je suppose qu’il y a une bonne raison pour ne pas activer la fonction set_time_limit, mais laquelle ?
S’il est prévu que la réactivation n’intervienne jamais, on pourrait simplement supprimer ces lignes.
En tout cas, je garde cette information précieusement puisqu’elle risque d’être fort utile lors des prochaines mises à jour.
La fonction set_time_limit() est problématique sur une plateforme mutualisé comme la notre en cas de scripts trop gourmands, défectueux ou malveillants. Elle peut permettre de prolonger trop longtemps un script de ce genre ce qui peut avoir des conséquences négatives sur l’ensemble des sites hébergés.
Certains CMS comme Nextcloud par exemple réalisent une vérification et râlent si set_time_limit() n’est pas là, mais ils fonctionnent quand même. Malheureusement Joomla utilise @ (voir plus haut) pour ça et ce @ ne fonctionne plus de la même façon depuis PHP 8, ce qui provoque maintenant une erreur bloquante qui n’est plus ignorée.
Bonjour,
Je continue de tester les fonctions de Joomla!.. et c’est vaste !
J’ai déniché une autre occurence d’appel à set_time_limit() et qui plante les mises à jour sous PHP 8.1 :
libraries/src/Installer/InstallerHelper.php
Même traitement et même succès, mais je crains qu’il y en ait d’autre(s)…
Mise à jour 15 h plus tard :
Fichiers concernés chez moi, mais ça doit être différent en fonction des modules, plugins, etc. :
J’ai utilisé la fonction de recherche dans le contenu des fichiers sur « set_time_limit » et c’est ce que je conseille.
Il me semble qu’une solution plus pérenne serait de trouver un moyen de remplacer la fonction d’origine par une fonction « blanche » qui ne ferait rien. Enfin, rien d’autre que d’éviter l’erreur…
Bonjour,
En fait, j’aurais dû commencer à chercher par là :
C’est tout bête, dans le index.php de la racine, en tout début de fichier, la ligne juste après le "<?php", insérer :
if (!function_exists('set_time_limit')) {
function set_time_limit($a) {}
}
Jusque là, ça a l’air de marcher. À voir à l’usage !
Bonjour,
Après Joomla!, je me suis attelé à Nextcloud… avec le même genre de problème :
Sous PHP 8, tout semble bien fonctionner sauf l’onglet « système » qui me renvoie systématiquement une page d’erreur :
Erreur interne du serveur
Le serveur est incapable d’exécuter votre requête.
Si cela se reproduit, veuillez envoyer les détails techniques ci-dessous à l’administrateur du serveur.
Le fichier journal du serveur peut fournir plus de renseignements.
Renseignements techniques
Adresse distante : (mon IP)
ID de la demande : 1xroYlCwkxkIM2orekrU
La journalisation indique : Exception: Call to undefined function OCA\ServerInfo\OperatingSystems\shell_exec() in file ‹ …/httpdocs/apps/serverinfo/lib/OperatingSystems/DefaultOs.php › line 227
C’est donc, là encore, un problème de fonction désactivée, « shell_exec() » et je suppose que, là aussi, il y a de bonnes raisons de l’avoir fait.
Tout semblant par ailleurs fonctionner normalement, l’accès aux informations système n’est pas bloquant, mais j’aimerais quand même trouver une solution à ce problème
Merci Matthieu,
J’ai dû attendre (longtemps ?) le retour à la version 8.0.20 mais le problème est toujours là.
Il apparaît qu’il concerne les serveurs mutualisés sérieux, donc prudents, et la demande de correction de Nextcloud est en instance sur GitHub.
Ça viendra, il n’y a plus qu’à attendre
Oui shell_exec() (et aussi set_time_limit()) est délicat à activer sur les plateformes mutualisées.
Désolé pour le délai de prise en compte du changement de version de PHP, nous réalisons quelques vérifications sur la plateforme et l’exécution automatique du script de déploiement des modifications est coupé (voir https://ouvaton.info/).
Bonjour
Je rencontre le même problème pour installer une nouvelle extension :
« Call to undefined function Joomla\Filesystem\set_time_limit() »
Je suppose qu’il faut intervenir dans un fichier mais je ne sais pas lequel.
Merci pour votre aide.
Madeleine
Pour régler le problème ponctuellement, il faut activer le rapport d’erreur de Joomla! :
Configuration > Onglet Serveur > Rapport d’erreurs : Maximum
Il signalera le fichier incriminé pour cette opération… mais ne dira rien pour les autres, et le même problème pourra intervenir, plus tard, ailleurs…
La solution que j’avais proposée dans le index.php de la racine ne règle pas tout. La seule solution est de faire une recherche de la chaine « set_time_limit » dans tous les fichiers et de traiter chaque occurence. Ça en fait beaucoup mais c’est faisable
La fonction set_time_limit() est disponible depuis hier sur toutes nos versions de PHP. Il ne doit plus être nécessaire de réaliser des modifications sur les Joomla, ils doivent fonctionner sans problème.
L’absence de cette fonction était aussi un problème sur notre plateforme avec les Wordpress en PHP 8 (impossible de mettre à jour, d’ajouter des plugins ou thèmes, etc) et l’objet d’un avertissement sur les Nextcloud. Tout doit maintenant être réglé.
Je m’aperçois que dans les paramètres d’administration de Nextcloud il y a le même genre d’erreur lorsque l’on veut paramétrer « Discussion ».
Erreur interne du serveur
Le serveur est incapable d’exécuter votre requête.
Si cela se reproduit, veuillez envoyer les détails techniques ci-dessous à l’administrateur du serveur.
Le fichier journal du serveur peut fournir plus de renseignements.
Est-ce que c’est à cause de shell_exec() ?
Par avance merci et bon lundi, profitez-bien celles et ceux qui font le pont
Je suis curieux (et en pleine procrastination) et je voulais voir ce que c’était que ce paramètre « Discussion », mais je ne le trouve ni dans les paramètres de l’admin, ni dans les apps…
C’est quoi ce mystère ?
