PluXml 5.9.0

Sudwebdesign · 7 févr.

Salut,
après 3 jours de taf et de recherches car j'avais certains flux rss avec l'erreur :
Erreur d’analyse XML : balise ne correspondant pas. Attendu : </description>.

L'erreur vient d'une fonction des plus utilisée ds le noyau (et plugins), alias plxUtils::strCheck qui a été en partie réécrite.

Une parade a été trouvé, voir https://github.com/pluxml/PluXml/pull/739
et https://github.com/pluxml/PluXml/pull/740 qui va plus loin et qui corrige 2, 3 trucs.

Il y à aussi plxFeed qui chagrine le plugin adhesion (peut-être d'autres) car il fait appel au getRss••• où il manque l'entête et le pied du xml, pour éviter cela et renouer avec la v5.8.9, il est modifié et y ajoute deux hooks qui permettrons au créateurs de greffons d'y adjoindre des balises a la fin de l'entête et au début du pied xml.
De plus il ajoute une fonction lastUpdated de @bazooka07 a plxRecord qui permet de retrouver la plus récente date.

Pour ce que cela intéresse, il est possible de fournir un exemple de comment faire boguer les rss, a votre guise

kamea · 8 févr.

Merci pour la réponse @bazooka07

bazooka07 · 8 févr.

@Sudwebdesign

Pour les problèmes de flux RSS voir PR#746

Sudwebdesign · 8 févr.

@bazooka07

Merci, ça roule avec adhesion il affiche bien les flux, et en toute probabilités d'autres

Mais il y a un problème lorsqu'un auteur a aucun article publié, son flux de nouvelle affiche juste <?xml version="1.0" encoding="UTF-8"?> et c'était pris en compte ds le commit, il affichait l'entête et le pied avec zéro item.

Étrange aussi, que la création dynamique de $this->lastBuildDate ne retourne aucune erreur, il est probable que comme nous somme ds la classe ça passe, par contre si un hook voulait l'utilisé ou la changé AMHA un Creation of dynamic property is deprecated avec php8.2 apparaîtra car elle n'est plus déclaré en amont

Il y a aussi la petite expreg où il manque le dernier point qui t'a échappé

ps: xml du rss toujours en erreur, mais pas du fait de plxFeed

bazooka07 · 9 févr.

@Sudwebdesign

Corrigé !
voir PR #747

Sudwebdesign · 11 févr.

@bazooka07 Oui s'il y a des articles
et non car si zéro article ou commentaire : feed.php?rss/commentaires/article1

Une élégante solution #749
Avec un nouveau hook plxFeedPrintRSSTop pour donner la possibilité aux créateurs de plugins d'adjoindre quelques bonus au xml avant les <item> des fluxes

bazooka07 · 11 févr.

@Sudwebdesign ,
Une plus élégante solution est de passer à la fonction printRSSTop() en paramètre par référence un pointeur sur la liste des enregistrements.
Voir PR #750

Sudwebdesign · 11 févr.

@bazooka07 Yep et avec le hook, sublime

Petite idée au passage : feed.php?rss/commentaires/user1
pour un fil de nouvelle de commentaires par utilisateur?
Pour l'instant ce type d'adresse (qui est donné nulle part) retourne le flux des articles.
[edit] ainsi que : feed.php?rss/cestenfaisantnimportequoiquondevientnimportequi

bazooka07 · 11 févr.

Comprends pas l'intérêt d'un feed.php?rss/commentaires/user1 !
feed.php?rss/user1 marche déjà pour les auteurs d'articles

Pas tenté par feed.php?rss/categorie999 ?
ou par feed.php?rss/tag/nainportequoi ?
ou encore feed.php?rss/user999 ?

Pas sûr que tous les lecteurs de flux RSS comprennent le langage HTML. Par contre, une erreur 404 doit mieux leurs parler.
voir PR #751

bazooka07 · 11 févr.

Et pour feed.php?rss/commentaires/article9999999 ?
voir PR #752

Sudwebdesign · 12 févr.

Comprends pas l'intérêt d'un feed.php?rss/commentaires/user1

Pour savoir quel sont les derniers coms reçu sans allez voir l'admin.
et c'est juste une idée, car il existe déjà les fils "admin" (mais plus global)

ou par feed.php?rss/tag/nainportequoi ?

ça fonctionne déjà si le mot-clé nainportequoi existe, sinon c'est page blanche.

Et pour feed.php?rss/commentaires/article9999999 ?

Parce que ça passait? Bien vu

Pas sûr que tous les lecteurs de flux RSS comprennent le langage HTML

Pour les "description" ça fonctionne très bien avec du html encodé avec "htmlspecialchar" comme jusqu’à la v5.8.9 et de plus cela conserve les paragraphes (pour la lecture c'est bien mieux)
Bien sûr s'ils respectent la spec "rss-2.0" de 2003 vu sur https://stackoverflow.com/a/10099772

Je suis pour "Rendre à PluXml sa gloire" ou au moins éviter de la perdre.
Donc un minimum de bogues avec un maximum de stabilité, de simplicité, de possibilités et de libertés pour les utilisateurs.

ps : Le "C'est en faisant n'importe quoi qu'on devient n'importe qui" vient de Rémi Guaillard (je pensais que tu connaissais, c'est un des plus grand prankeur Français). Et voici un peu d'humour pour détendre l'atmosphère.

bazooka07 · 12 févr.

Je me suis mal exprimé.
Avant, lorsque le lecteur de flux envoyait une requête invalide pour une catégorie inconnue (Ex: 999) ou inactive, un article inconnu (Ex: 9999) ou non publié, un mot-clé inutilisé, PluXml répondait en envoyant la page d'accueil du site en HTML. Pas sûr que tous les lecteurs comprennent alors qu'ils attendent un document XML ou RSS.
Maintenant, PluXml renvoie une erreur 404 en bon HTTP.

Je vais regarder pour la description en html.

Sudwebdesign · 12 févr.

@bazooka07 Bien vu pour la 404 des flux au lieu d'une redir et HTML en sortie

Sudwebdesign · 13 févr.

Bonjour,

En bossant sur spxvisualwizard free, je suis tombé sur une erreur de get_magic_quotes_gpc qui m'a permis de découvrir que les stripslashes sont (pratiquement) obsolète pour protéger les $_POST depuis PHP-5.4.
Voir : le premier commentaire de https://stackoverflow.com/questions/61054418/php-7-4-deprecated-get-magic-quotes-gpc-function-alternative

Pour en venir au sujet de PluXml, AMHA la `ligne 51` de `core/admin/prepend.php` peut être supprimé :

# Echappement des caractères
if($_SERVER['REQUEST_METHOD'] == 'POST') $_POST = plxUtils::unSlash($_POST);

D'ailleurs cela fait des années que je la commente celle là, car elle me gêne lorsque je modifie les pages statiques avec des antislash

Ps: gardons tout de même plxUtils::unSlash, selon mes souvenir elle est utilisé ailleurs* et est peut-être utilisé par des plugins.

Voici le *Ailleurs (plxMotor Ligne 402) # On a validé le formulaire commentaire :

                # On récupère le retour de la création
                $content = plxUtils::unSlash($_POST);

A Plux

bazooka07 · 13 févr.

plxUtils::unSlash() utilise la fonction de PHP get_magic_quotes_gpc().
Cette dernière est obsolète depuis PHP7.4 et supprimée depuis PHP8.0.0
https://www.php.net/manual/fr/function.get-magic-quotes-gpc.php
Il y a donc un souci.
Quant à la fonction stripslashes(), je doute de son efficacité face à du code malveillant dans des données stockées en XML.
Pour une base de données SQL, peut-être.
Je pense que pour avoir un minimum de sécurité avec $_POST, il serait plus pertinent d'utiliser htmlspecialchars, excepté pour le contenu des pages statiques qui peuvent contenir du code PHP et pour les templates des thèmes avec PHP et javascript.
Je vais regarder cela dès que possible.

Sudwebdesign · 13 févr.

@bazooka07 Ds la page : https://stackoverflow.com/questions/61054418/php-7-4-deprecated-get-magic-quotes-gpc-function-alternative
Phil dit : que depuis php5.4 il n'ajoute plus d'antislash aux requêtes, Since PHP no longer adds slashes to request parameters
Et je pense que la ligne susmentionnée plus haut était pour corrigé cela a l'époque (il a bientôt 20ans de vie notre PluXml adoré).

De plus il n'est peut-être pas utile de sortir l'armada de vérif pour l'admin, c'est sensé être sécure, enfin ce n'est que mon avis

Ps : l'appel a get_magic_quotes_gpc n'est plus ds PluXml depuis longtemps déjà et je l'ai carrément supprimé de spxvisuawizard. La fonction se nommait visualwizard_utils_unSlash

Sudwebdesign · 15 févr.

Salut,
je remonte un petit souci au niveau de lib/config.php
J'explique : avec certains plugins (gutuma et visualwizard entres-autre) lorsqu'ils émules core/admin/prepend.php.

Sauf que maintenant lib/config.php inclut le config.php de la racine, ça c'est bien

Par contre pour ceux qui souhaite supporté certaines anciennes version de PluXml, il y à un couak lorsque ils incluent le config.php racine avant car cela va dire que PLX_CONFIG_PATH est déjà définit...

Je me demande comment faire, car, soit on teste sur la version (bidouille en test en se sens avec gutuma) en incluant core/lib/config.php et verif si PLX_CONFIG_PATH (en cachant les erreurs) est définit (ou si PLX_VERSION < 5.9) c'est bon on continu, sinon (version <= 5.8.9) il garde en session la version, header('Location: '.$auMemeEndroit); et inclut config.php racine avant lib/config.php pour que PLX_CONFIG_PATH soit définit en amont.

J'ai donc pensé a :

if(!defined('PLX_CONFIG_PATH')) include PLX_ROOT . 'config.php';

ligne 34 de core/lib/config.php pour pallier au problème, car il est impossible de savoir la version de PluXml sans l'inclure.

Ou cela, c'est un peu trivial mais fonctionnel,
il suffit de vérifié si le (nouveau) fichier core/lib/class.plx.themes.php existe en amont pour savoir que c'est un PluXml >= 5.9 qui va être chargé.

Si quelqu'un a d'autres idées, je suis preneur...

Cdt.

gcyrillus-nomade · 15 févr.

@Sudwebdesign
Pour tester la version de Pluxml, j'utilise : if(version_compare(PLX_VERSION, '5.9.0', ">=")) {'echo 'version 5.9.X et superieurs ';} Cela me semble plus adapté.

Sudwebdesign · 15 févr.

@gcyrillus-nomade

Pour tester la version de Pluxml, j'utilise : if(version_compare(PLX_VERSION, '5.9.0', ">=")) ...

Oui, mais le problème n'est pas là, PLX_VERSION est définit ds core/lib/config.php jusque là ça va
Sauf que PluXml 5.9 inclut le config.php racine ds ce fichier (qui lui définit PLX_CONFIG_PATH) et c'est là que le bât blesse, comment fait-on pour savoir ds un prepend.php de plugin, si il doit ou non inclure le config.php racine avant d'inclure core/lib/config.php?

bazooka07 · 15 févr.

Effectivement, je pense que la seule solution est de tester la présence de la constante PLX_CONFIG_PATH dans lib/config.php.

Maintenant je m'interroge sur ces plugins qui émulent admin/prepend.php. Comment ces plugins sont lancés alors que $plxAdmin n'est pas instancié.

Je ne connais pas Gutuma et voir comment il opère.

Sudwebdesign · 15 févr.

@bazooka07 en fait on copie prepend.php a qui l'on change

PLX_ROOT = '../../../' et parfois PLX_CORE
puis on inclus les config.php ça c'était avant
on charge les classes et instancie $plxAdmin ou motor
Sais plus ou on session starte

Au cas ou si tu veux voir, télécharge visualwizard.free.2.7.zip archivé.
Regarde le fichier admin/ajax.php c'est vieillot et en rade mais tu aura l'idée...
Je suis en train d'y bossé pour le refaire tourner.

gcyrillus-nomade · 15 févr.

Je viens aussi de découvrir un bug avec les plugin ayant une page de configuration:

À l'enregistrement, on à le droit à une page blanche et : Warning: Cannot modify header information - headers already sent by (output started at \programFile\laragon\www\PluXml-5.9.0-rc5\core\admin\top.php:141) sur, (quelque soit le plugin) , la page config.php du plugin indiquant le numéro de ligne de

    header('Location: parametres_plugin.php?p=UnPluGinOuUnAutre');

Les paramètres sont enregistrés sans erreurs ni manque.

Les version rc4 et inférieurs n'ont pas ce bogue.

Cdt

Sudwebdesign · 15 févr.

@gcyrillus-nomade je viens de vérifiés avec 30 plugins activés et aucune erreur de ce type, mais je suis avec la toute dernière MAJ de la branche master. Peux-tu nous dire avec quel plugin par exemple. je vais tenter de redescendre en 5.9RC5 pour voir ça. [edit] Même avec la RC5, aucun souci

@bazooka07 d'abord merci pour tout ce que tu fait

je suis en train de tester les dernières MAJ pour les petits écran comme tu as du le remarquer avec le dernier PR qui corrige un bogue de longue date (2015) avec le lien admin/comment.php qui (n')amène (pas) au commentaire (sur le site) en cours de modification (mauvaise ancre).
J'ai préféré ré-annonymisé l'ancre, ça fonctionne aussi bien ainsi coté site qu'avec le numéro de l'article et le lien de l'admin est correct du coup.
article2/le-titre#c0002-c4 redevient article2/le-titre#c4
les liens répondre fonctionnent biens ainsi que ceux de la sidebar et feed.
Au cas ou, il y a une autre soluce incluse, a toi de voir

Ps : Pour me répondre a moi même, AMHA je vais utilisé la vérif du fichier plxThemes pour savoir si nous sommes avec un PluXml > 5.8.9 car sauf de modifier core/lib/config.php avec

if(!defined('PLX_CONFIG_PATH')) include PLX_ROOT . 'config.php';

je vois que ça PLM.

gcyrillus-nomade · 15 févr.

@Sudwebdesign tester par exemple avec plxMysearch , apache, et php 8.2.6
j'ai pris la rc5 en release.

gcyrillus-nomade · 15 févr.

je viens de retester avec la version du dépot , idem:
message = Warning: Cannot modify header information - headers already sent by (output started at \programFile\laragon\www\PluXml-02-15-24-rc5\core\admin\top.php:141) in \programFile\laragon\www\PluXml-02-15-24-rc5\plugins\plxMySearch\config.php on line 38

Config:

Vous utilisez la dernière version de PluXml (5.9.0-rc5)

Ces informations vous renseignent sur le fonctionnement de votre PluXml et peuvent s'avérer utiles pour son dépannage.

PluXml version 5.9.0-rc5 (encodage UTF-8)

    Version de PHP : 8.2.6
    Apache/2.4.54 (Win64) OpenSSL/1.1.1a PHP/8.2.6

    ✔ ../../ est accessible en écriture
    ✔ ../../data/configuration/ est accessible en écriture
    ✔ ../../data/configuration/plugins/ est accessible en écriture
    ✔ ../../data/articles/ est accessible en écriture
    ✔ ../../data/commentaires/ est accessible en écriture
    ✔ ../../data/statiques/ est accessible en écriture
    ✔ ../../data/medias/ est accessible en écriture
    ✔ ../../plugins/ est accessible en écriture
    ✔ ../../themes/ est accessible en écriture
    ✔ Module apache de réécriture d'url mod_rewrite disponible
    ✔ Bibliothèque GD installée
    ✔ Bibliothèque XML installée
    ✔ Fonction d'envoi de mail disponible

Installation neuve, et un seul plugin , rien qui polluerait à priori le fonctionnement.

bazooka07 · 15 févr.

@gcyrillus-nomade
J'ai reproduit le bug avec mon vieux plugin cacheCss.
Le problème vient de parametres_plugin.php.
Avant RC5, en début de fichier on appelle la page du config du plugin et on stocke le résultat dans la variable $output.
Pendant cet appel s'il y a un $_POST ou une requête illicite, on fait redirection avec header sur la page parametres_plugin.php.
Dans le cas normal après avoir sauvegardé le résultat de la page de config du plugin, on continue le traitement dans paramètres_plugin.php en faisant un include 'top.php', en affichant la variable $output et en finissant avec include 'foot.php'.
Je vais regarder demain pour rétablir l'usage de la variable $output.
Il y a aussi dans ce fichier 2 appels à $plxAdmin->checkProfil(). Le 1er est bloquant si on n'est pas admin, même si l'auteur du plugin a autorisé l'accès à la page de config à d'autres profils.

Le problème existe toujours sur la branche master.

bazooka07 · 15 févr.

@gcyrillus-nomade,
Merci pour le retour.
Si tu vois autre chose, n'hésites pas !

bazooka07 · 15 févr.

Voir PR #760

J'ai aussi modifié plxAdmin::checkProfil() ey lib/config.php dans la foulée

Sudwebdesign · 15 févr.

@bazooka07 🙏 😍

gcyrillus-nomade · 16 févr.

@bazooka07 , juste pour te confirmer que je n'ai plus le bug sur les pages de configuration des plugins

PluXml 5.9.0

Réponses

Pour en venir au sujet de PluXml, AMHA la ligne 51 de core/admin/prepend.php peut être supprimé :

Pour en venir au sujet de PluXml, AMHA la `ligne 51` de `core/admin/prepend.php` peut être supprimé :