PluXml 5.8.9 et PHP 5.6

bazooka07 · août 2022

Bonjour,

Certains utilisent Free.fr comme hébergeur et ne peuvent utiliser la dernière version officielle (5.8.9) de PluXml.
Cela est dû principalement à l'introduction de la bibliothèque PHPMailer dans les dernières version de PluXml, qui impose au minimum PHP version 7.2.5.
Si on prend soin de tester la version de PHP et de désactiver PHPMailer alors PluXml 5.8.9 peut fonctionner. Il faut également fixer quelques bugs mineurs introduits par PHP 7.0.0.
Voici une version 5.8.9-simple non officielle de PluXml qui règle ces problèmes.
Cette version corrige également quelques problèmes spécifiques à Free.fr.

Voir la démonstration chez free.fr
Ce site utilise également le plugin kzDemo qui permet de visiter le back-office de PluXml avec différents profils sans possibilité de sauvegarder.
Pour profiter de cette version, cliquer sur uns des liens suivants :

https://kazimentou.fr/static8/download ( télécharger pluxml-simple.zip et éventuellement unzip.php pour téléverser directement l'archive chez votre hébergeur )
https://github.com/kazimentou/pluxml/tree/5.8-simple ( branche 5.8-simple )

A noter que cette version n'intègre pas PHPMailer et toutes ses dépendances.
Si vous en avez besoin, ouvrez une fenêtre de terminal, allez dans le dossier core du site, vérifiez la présence du fichier composer.json et lancer la commande "composer install".

PHPMailer et cie ne sont pas développés par l'équipe de PluXml. Ils devraient donc être intégrés comme sous-modules sur le dépôt Github et non figurés comme source de PluXml. Ce qui éviterait des commits inutiles.

Pour les développeurs, notez qu'il est possible de faire tourner plusieurs versions de PHP sur un serveur si vous travaillez avec une distribution Linux :

Dans ce cas, Nginx est plus facile à utiliser que Apache.

gcyrillus-nomade · août 2022

Bonsoir,

Il serait judicieux aussi de désactivé l'option d'URL rewriting si le ndd(hebergeur) est en free.fr , sinon = une erreur 500 et l'obligation de passer par le ftp pour refaire le fichier htaccess. note amusante, on peut avoir un sous dossier en php 5.6 et la racine en php 4 chez free, tout dépend ou l'on met le fichier htaccess pour emuler php 5.6

bazooka07 · août 2022

Bonsoir,
Je n'avais jamais testé le "url-rewriting" chez "free.fr". Et effectivement beau plantage pour mettre les newbies dans le décor.

Je considère que c'est plutôt un bug de PluXml. J'explique :

Dans le fichier parametres_infos.php, on fait appel à la fonction plxUtils::testModRewrite().
Dans cette dernière, on teste si la fonction apache_get_modules() existe.
Si c'est négatif, on retourne "true" et rien n'est affiché. Même pas le moindre message d'erreur. Et si le paramètre $io est à false, on devrait plutôt false au lieu d'un message d'erreur.

Donc quand on active le url-rewriting on devrait d'abord vérifier que plxUtils::testModRewrite(true, '') retourne bien true.
Dans le cas contraire, l'url-rewriting doit être désactivé obligatoirement.
Cela évitera de faire de free.fr une généralité.
Perso, j'utilise un serveur Nginx. Donc les .htaccess n'ont aucun intérêt pour moi.

P.S.: Pour faire un test chez free.fr, on peut rajouter les lignes suivantes quelque part dans parametres_infos.php :

<pre>
<?php
if(function_exists('apache_get_modules')) {
        $apacheMods = apache_get_modules();
        var_dump($apacheMods);
} else {
        echo 'Pas de fonction apache_get_modules()' . PHP_EOL;
}
?>
</pre>

gcyrillus-nomade · août 2022

re et bonjour ,

Mon approche n'est pas celle d'un développeur mais plutôt d'un débutant ou d'un codeur occasionnel (du dimanche quoi) d'où mon précédent post. Quelques sujet sur le forum reflètent bien ce genres de soucis. C'est aussi un défaut général de PluXml simple et léger mais nécessitant un minimum de connaissance en codage pour l'installation (install + theme + plugin) puis la maintenance.

C'est un profil assez commun chez les utilisateurs de free (premières tentatives de mise en ligne d'un site) et le défaut c'est que l'option d'urlrewriting reste active /affichée dans free et le message L_MODREWRITE_NOT_AVAILABLE n'est jamais affiché, un débutant apprentis sorcier peut-être tenté de l'activé et tout casser ...

editEn fait

apache_get_modules() is only available when the PHP is installed as a module and not as a CGI == It doesn't work with php-fpm.

Ce qui explique que cette fonction ne sert sur aucun de mes hebergement ou en local

il y aurait une piste alternative https://stackoverflow.com/a/9021523/2442099 ?

strpos(shell_exec('/usr/local/apache/bin/apachectl -l'), 'mod_rewrite') !== false

fin edit

C'est peut-être plus un bug qu'autre chose car la fonction testModRewrite() {if(){}else{}} me renvoie toujours Pas de fonction apache_get_modules() quelque soit l’hébergement ou la version de PHP .
Par ailleurs, si le moderwrite est inexistant (si fonction de test efficiente), en plus d'un message d'avertissement (qui ne s'affiche pas) il serait aussi plus sûr de passer le select en readonly et scotché sur non , enfin , à l'opposé, je ne sais pas si une option d’édition avancée du fichier htaccess dans l'admin pourrait-être utile pour les utilisateurs avertis ?

Cdt

H.S. Pour nginx, je ne connais pas et ne sais donc pas comment l'urlrewriting se configure (mais activable en lieu et place d'apache dans laragon, je prendrais le temps de tester)

re-edit en passant de apache à nginx , le test if(plxUtils::testModRewrite(false)) est tout autant inefficace, pas de message d'erreur à propos du fichier htaccess ni de message indiquant que l'urlrewriting n'est pas disponible (activé) , résultat, la navigation de pluxml ne renvoie qu'en page d'acceuil et tout le site devient inaccessible. Il y a un défaut avec cette fonction qui ne semble servir à rien en final.

edit . Il mes semble aussi , que pour palier à ces défaut, le test d'urlrewrtiting pourrait être tester des le lancement de index.php ou au moins à l'installation pour laisser cette option opérante ou la forcer sur sa valeur par défaut afin d'eviter un dysfonctionement du site.

bazooka07 · août 2022

Bonjour,
Merci pour la remarque à propos d'un serveur PHP-FPM derrière Apache2. J'utilise toujours PHP comme module d'Apache. Je testerai dès possible.
Pour en rajouter une couche, si la directive AllowOverride de Apache est à None, l'urlrewriting ne marche pas. C'est l'installation par défaut sur Ubuntu et Debian.
Pour savoir si PHP tourne sur un serveur indépendant PHP-FPM, on peut regarder avec phpinfo() la valeur de "Server API"
Je te confirme que la fonction plxUtils::testModRewrte(false) n'est pas correcte.
J'ai donc corrigé la dernière version de PluXml pour y remédier. Si on n'arrive pas à déterminer si le module Rewrite d'Apache est présent, on désactive l'urlrewriting. Les URLs seront peut-être moins jolies mais le site tournera !
Voir la branche plxUtils-testModRewrite-220824 sur mon dépôt kazimentou chez Github
Cela fonctionne avec les dernières versions de PHP, mais il y a une erreur 500 avec PHP5.6 sans aucun message. Il faut que je corrige cela avant de merger avec la branche 5.8-simple.
Pour Free d'après cette page, il y a peut-être la possibilité d'utiliser la directive RedirectMatch de Apache. Il faut que je fasse des essais.

Pour Nginx, il y a le fichier de configuration avec le lien suivant. Les règles de ré-ecritures d'URLs y sont déjà présentes.
https://wiki.pluxml.org/docs/install/nginx.html

bazooka07 · août 2022

Bonjour,
@gcyrillus-nomade,
J'estime que la fonction testModRewrite est bugguée.

J'ai refactorisé la fonction plxUtils::testModRewrite().
Diverses corrections dans plxMotor::getConfiguration(), parametres_avances.php, etc..

Dans parametres_avances.php si le module Rewrite n'est pas détecté, le select est remplacé par un champ caché et une notification s'affiche. De plus en absence du module, la ré-écriture est désactivée au chargement de la config de PluXml.

Voir Pull-Request 573

PluXml 5.8.9 et PHP 5.6

Réponses