PluXml 5.9.0

Sudwebdesign

Bonjour, bonsoir
une erreur js Uncaught TypeError: invalid assignment to const 'dta' ligne 666 de core/admin/article.php lorsque l'on écrit l'image d'accroche.

                const dta = el.value;

remplacer const par let ligne 662

                let dta = el.value;

Cordialement

Sudwebdesign

Bonjour, bonsoir
Ayant vue ds la fonction javascript précédente le match avec |data
Cela peut-il causer un souci si le dossier data est modifié par un admin?
Il y en a 4, voir (il faut être connecté a gh pour y avoir accès)

Et utiliser $••••->aconf['medias'] peut-il faire le taf?

ÉDIT : sauf pour plxMotor->urlRewrite()

ps: cela semble être ancien...
ps²: Et non bloquant

Cordialement

bazooka07

Bonjour,
@gcyrillus-nomade ,
Effectivement, il faut remplacer md5() par plxUtils::urlify() comme dans plxShow::authorsList()

@Sudwebdesign,
Exact plxUtils::checksite() est la seule fonction à prendre le paramètre par référence parmi les 3 fonctions plxUtils::check....()
Mais cela ne suffit pas pour prévenir une attaque XSS.
J'ai donc modifié plxUtils:getGets() comme recommandé par php.net
Pour article.php, tu fais une confusion. Le data dont tu parles est celui qu'on va mettre dans l'attribut src de <img>
src peut contenir soit une url, soit des données binaires encodées qui sont l'image elle-même. Rien à voir avec le data de la configuration de PluXml.
Pour le script js, ok pour remplacer const par let.
Mais il y a un autre gros problème. Quand on saisit l'adresse de l'image d'accroche au clavier, à chaque frappe de touche on génère une erreur 404 en voulant actualiser l'image affichée. Il faut utiliser l'évènement change.

PR #797 pour les corrections

Merci pour vos retours.

Sudwebdesign

Bonjoir,
@bazooka07 merci pour le suivi et les explications, cela augmente nos connaissances sur notre superbe poids plume

bazooka07

PR #798
Utilisation de plxMotor::urlRewrite() dans sitemap.php

Sudwebdesign

@bazooka07 quitte à être ds les coms,
un oubli de ma part pour les champs requis pour le fichier core/admin/comment.php

                <label for="id_author"><?= L_COMMENT_AUTHOR_FIELD ?> :</label>

devrait être

                <label for="id_author" class="required"><?= L_COMMENT_AUTHOR_FIELD ?> :</label>

ET

                <label for="id_content"><?= L_COMMENT_ARTICLE_FIELD ?> :</label>

devrait être

                <label for="id_content" class="required"><?= L_COMMENT_ARTICLE_FIELD ?> :</label>

ÉDIT

                <?php plxUtils::printArea('content', $content, 0, 7, false, 'full-width', 'placeholder=" "'); ?>

devrait être

                <?php plxUtils::printArea('content', $content, 0, 7, false, 'full-width', 'required placeholder=" "'); ?>

ÉDIT 16/03/24 : voir pr800

En toutes Cordialités

Sudwebdesign

@bazooka07 vu le pr798
Il me semble judicieux d'utiliser les L_URL's
et bien vu pour le urlrewrite
@ plux

bazooka07

PR #799 pour urls multilingues dans sitemap.php

Sudwebdesign

Bien le bonjour,
Une MAJ et une petite refactorisation de la page admin/comment.php qui ajoute les classe "required" voir le post #Comment_64889 et qui place les liens site et mailto dans leurs label respectifs ainsi que l'ajout des espaces insécables.

ÉDIT : regex retouchés (\.), code plus lisible et liens multilingues : ?article vers ?' . L_ARTICLE_URL

voir le pr800

Une idée pour aller plus loin :
Une sidebar à droite avec IP, Statut, Type, Article attaché et Date (comme pour la page admin/article.php), qu'en dite vous?

Sudwebdesign

@bazooka07 En ayant modifié le pr800 avec L_ARTICLE_URL, me suis aperçu qu'il reste des ?url-en-dur qui traîne : je suis en train de bosser dessus...

C'est fait pour le noyau multilingue : voir pr801

ÉDIT : les deux pr (800 et 801) sont complémentaire.

En toute cordialité.

gcyrillus-nomade

Bonjour,
Un petit bug sur les lien des fils des RSS des commentaires seulement si la langue du site et la langue de l’utilisateur dans l'admin sont différentes.
1. une page blanche pour le fil des commentaires
2. un Bad request for RSS feed pour le fil des commentaires d'un article précis.
3. une page blanche pour le fil RSS des articles par mot-cle

L'interface en front prend la langue de l'administration si on est connecté, ainsi que les urls. je n'ai pas remarqué d'autres bugs que celui des fils RSS des commentaires des article par mots clés.

cdt

Sudwebdesign

@gcyrillus-nomade cela est peut-être réglé avec les pr 800 et 801 car il manque l'internationalisation a quelques endroits.
M'en vais tester ça en mixant les 2 pr en local, pour voir si ces pages blanches sont présentes...

Sudwebdesign

@gcyrillus-nomade En effet, (Même avec le MIX des pr 800 et 801) lorsque l'on est connecté a l'admin avec une autre langue que celle du site (frontend) les urls pour les flux donnent des pages blanches... Car plxFeed ne charge pas la $_SESSION pour des flux rss et c'est normal a quoi servirait elle.

Site en FR (et déconnecté) : urls : mot-cle/lemotcle + feed/rss/mot-cle/lemotcle = OK
Si connecte en ES a l'admin et retour sur le frontend :
etiqueta/lemotcle = OK qui donne pour les flux rss feed/rss/etiqueta/lemotcle = Bad request for RSS feed.
Mais avec l'adresse de la langue du site réglé en FR feed/rss/mot-cle/lemotcle = OK

@bazooka07 comme @gcyrillus-nomade je remarque aussi que les URL sont donc modifiées en fonction de la langue choisit par l'utilisateur, cela pose un problème pour le partage avec un copier coller de l'url a partir de l'admin (d'un article par exemple) avec une autre personne qui n'est point connecté ou que la langue choisit par le 2e soit différente.

@bazooka07 Peut-être un ajout de constantes comme URL_ARTICLE, URL_STATIC etc. qui prennent les valeurs des L_URL's de la langue du site et placé aux bons endroits...
ÉDIT : ou (mais ça te plaira ptêt pas) garder juste les L_URL's d'une langue et comme ça problème réglé (et je dirais même plus) remettre a ces constantes les url originelles (elles seront plus simple a trouver avec mes 2 derniers pr et les tiens car il suffira de chercher L_\w+_URL ds tout le code pour les retrouver pour une future version

Cordialement

bazooka07

PR #802
issue #549

Dans medias.php, il n'est plus possible d'afficher directement une image dans un nouvel onglet ou une fenêtre séparée.
Elle sera affichée comme les vignettes dans le zoombox existant. Risque d'un script malicieux en javascript inséré dans une image au format svg.

Politique "noreferrer nofollow" pour les liens externes au site ( plugins, thèmes, commentaires, ...) pour éviter le tracking.

Sudwebdesign

Bonjour, bonsoir @bazooka07
Après beaucoup de tests et essais avec le plugin adhesion pour éviter les 404 sur chacune de ses pages...
Son hook plxMotorPreChauffageBegin gère depuis longtemps $this->mode et $this->template
Comme préconisé maintenant ligne 166 de plxMotor

        # Hook plugins
        if(eval($this->plxPlugins->callHook('plxMotorPreChauffageBegin'))) {
            # En cas de succès, le hook doit gérer $this->mode et $this->template.
            return;
        }

Sauf qu'il utilise aussi le hook plxMotorDemarrageBegin et aussi le hook plxMotorDemarrageEnd (donc exit le return au Begin).

le seul moyen simple trouvé est de supprimer le dernier $this->error404() ds le cas par défaut du démarrage.
En toute logique, il fait doublon avec ceux déjà présents ds le préchauffage qui déclenchent déjà le mode erreur.

    public function error404($msg) {
        header('Status: 404 Not Found');
        header('HTTP/1.0 404 Not Found');
        $this->plxErreur = new plxErreur($msg);
        $this->mode = 'erreur';
        $this->template = 'erreur.php';
    }

De plus, s'il est absent, pluXml renvoi bien une 404 lorsqu'aucun mode qu'il connaît n'est trouvé.

Le test a "supprimer des que possible" peut être supprimer dés à présent car il empêche d'atteindre plxMotorDemarrageEnd avec le mode défini par un plugin (adhesion ici) car il le remplace par le mode erreur

Il parait plus judicieux et plus simple avec le case par défaut de ne rien faire du tout.

Ou a minima, remplacer avec un code qui renvoi une 404 si aucun mode est réglé au préchauffage comme ci-dessous :

                # Aucun Mode
                if( ! $this->mode) {
                    $this->error404(L_ERR_PAGE_NOT_FOUND);
                }

Mais risque de créer des nombreux retour négatif car jusqu'à présent (v5.8.9) les modes erreurs sont gérés par le préchauffage ligne 318.

        } else {
            $this->error404(L_ERR_PAGE_NOT_FOUND);
        }

De plus cela re-permet a PluXml d'accepter les modes créés par les plugins et ainsi d'atteindre le hook plxMotorDemarrageEnd avec les bons modes, templates (et headers) sans bidouiller PlxMotor
(et peut-être certains plugins)

voir pr803

En toutes cordialités.

TIM

Bonjour
JE viens de tester, aucun souci pour moi

gcyrillus-nomade

@Sudwebdesign

Le test a "supprimer des que possible" peut être supprimer dés à présent car il empêche d'atteindre plxMotorDemarrageEnd avec le mode défini par un plugin (adhesion ici) car il le remplace par le mode erreur

As tu vérifier que cela est vrai avec d'autre plugin tel que les plugins dit officiels et toute la palanquée de ceux utilisant exactement leur modèle d'insertion(vu comme officiel et recommandé depuis 2011->2024) comme mode ? Je ne vais pas ré-argumenter sur ces besoins de retro compatibilité ni autre façon de gérer la variable index.php?modeOuPasMode capter par PluXml, ni re exposer mon point de vue la dessus et encore moins sur le rôle du préchauffage et du démarrage de moins en moins clair qui finissent par se confondre...

Je ne sais pas vraiment combien de plugin qui s'affichent en front, je n’ai pas non plus maintenant, ni dans la semaine à venir le temps de me poser la question en faisant un inventaire et de tester ceux-ci avec une 5.8.9 Vs une en dev en direct du repo, pour simplement émettre un message d'alerte pour les utilisateurs de tel ou tel plugin dans le cas d'une mise à jour.

Y a/avait-il besoin de refondre autant et certaine parti du code qui fonctionne ? pour sortir une nouvelle version ?

• Pas sur, pour le moment ça ne se passe que sur le forum et, pour ceux qui irait chercher leur archive sur le repo, sur github.
• Sinon, je dirais que la correction de la ligne 1420 de pluxUtils pouvait justifier une maj et une petite monté en version pour signifier le sérieux et le suivi de PluXml pour la compatibilité PHP8X , c’était un minimum à faire pour taire les warnings On est loin de simple correction de mise à jour ou de refactorisation du code . Ce n'est plus une 5.9.0 qui est en chemin, la 6.9.0?

bazooka07

Bonsoir
Si un plugin utilise son propre mode, quel est l'intérêt de le comparer aux modes standards de PluXml ?
Faire ces tests inutiles ralentit le serveur .
Le job qu'il fait avec le hook plxMotorDemarrageEnd ne peut-il pas être fait dans le hook plxMotorDemarrageBegin à la fin du code existant pour ce dernier hook ?
Cela éviterait d'utiliser le serveur dans ces tests inutiles.

Pour le bug sur les flux RSS, le problème, si tel est le cas, vient du test elseif(isset($_SESSION['admin_lang'])) dans plxMotor::_construct(), ligne 120 actuellement dans class.plx.motor.php.
Je peux le supprimer mais le problème se posera également pour le test elseif(isset($_SESSION['lang'])) qui permet à un plugin de modifier la langue du site (plxMultiLingue ?).

Je vais modifier les regex dans plxFeed::fprechauffage() pour accepter toutes les langues dans les urls. C'est relativement facile pour moi, même si cela prend un peu de temps.

Pour l'instant, je m'abstiens d'ajouter toute nouvelle fonctionnalité à PluXml, à part corriger des bugues mineurs.
En parallèle j'ai créé sur mon PC une nouvelle branche pour générer les urls à la "plxMyBetterUrls"
Et j'ai aussi en projet d'intégrer la fonctionnalité du plugin kzUploader qui permet d'installer sur un serveur distant ou local un plugin ou un thème depuis son archive zip.
J'ajouterai cela après la prochaine release de PluXml dès que possible

Pour PluXml 6.0 qui consiste à relooker le back-office de PluXml principalement et aussi de passer à un librairie plus récente pour gérer le XML, cela attendra l'hiver.

Avec le retour des beaux jours, je serai moins disponible pour faire évoluer PluXml !
Et je n'ai pas trop envie de rétrograder cette nouvelle version de PluXml pour la rendre compatible avec des plugins mal fichus, même si leurs auteurs/mainteneurs sont aux abonnés absents.

bazooka07

@gcyrillus-nomade ,
C'est quoi cette ligne 1420 dans plxUtils ?
Actuellement cela correspond à "}"

gcyrillus-nomade

@bazooka07
c'est : <option disabled value=""$classAttr data-level="$dataLevel">$prefix${caption}/</option> qui demande juste a passer ${caption} en {$caption} , je parlais de la 5.8.9 officielle php8 etant de plus en plus présent, ce petit details apparait plus souvent C'est ce qui me faisait dire aussi, qu'une maj mineure entre temps aurais pu voir le jour et s'inscrire dans le calendrier .
Il n'y a quasiment que toi qui est capable de prendre l'ampleur des choses qui doivent être corriger mais il faut avouer que tu est parti sur un chantier de grande ampleur sans communiquer sur les objectifs de la fin de ce chantier.

Quant aux test des plugins, je ne comprend toujours pas, il existent. Mais bon, je ne suis pas développeur. simplement, je vois la un bazar qui s'installe et une flopée d'incrédule qui auront de drôle de surprise en faisant en toute confiance la mise à jour de leur PluXml. Personnellement, je ne m'en fais pas.
Il manquait une checklist ou cahier des charges pour qualifier un plugin de valide par l'équipe officiel, je pense qu'aujourd'hui que cela devient plus que nécessaire.

Je vais aussi être moins présent sur le forum dans les mois à venir. J’espère que cette nouvelle mouture va raviver de l’intérêt et voir de nouveaux membres sur le forum.

bazooka07

Ok, j'ai vu.
Oui cela mérite de publier une release 5.8.10 pour ce petit bug. le dernier numéro (10) d'une version est fait pour fixer ces petits bugs.
Pour les choses à corriger, je les découvre au fur et à mesure. Difficile de fixer des objectifs
Et il n'y a pas grand monde pour "mettre les mains dans le cambouis".

gcyrillus-nomade

Et il n'y a pas grand monde pour "mettre les mains dans le cambouis".

Complétement d'accord et perso , je n'ai pas les compétences. Je continue à découvrir , apprendre et désapprendre.

En tout cas, il y a quand même dernièrement eu plusieurs personnes qui ont tester et remonter des trucs, ça finira par revenir

++

Sudwebdesign

Bonjour,

As tu vérifier que cela est vrai avec d'autre plugin tel que les plugins dit officiels et toute la palanquée de ceux utilisant exactement leur modèle d'insertion(vu comme officiel et recommandé depuis 2011->2024)

@gcyrillus-nomade Oui le pr803 fonctionne bien avec plxMyBetterUrl, plxMySearch et plxMyContact de ton dépôt github (et avec des plugins officieux) : si une autre url que celles réglés avec ceux-ci, il y a bien la page d'erreur avec le message "page non trouvé" qui s'affiche.

@bazooka07
il y a en fin du préchauffage le dernier else qui permet de dire au moteur de se mettre en mode erreur s'il ne reconnaît pas l'url.
Et celui de la fin de démarrage qui dit au moteur de se mettre en mode erreur par défaut sans que nous puissions rien y faire.

Déplacer le démarrageEnd d'adhesion, j'y ai pensé, mais réviser plus de 200 lignes qui tournent bien depuis + de 2ans avec PluXml 5.8.7 contre 10 (1 en réalité) le choix est vite fait, encore si les pages d'erreurs n'étaient point trouvées, mais là, c'est pas le cas.

@team
Pourriez-vous expliquer quel est le but d'appeler $this->error404(L_ERR_PAGE_NOT_FOUND); en fin de démarrage pour qu'il passe en mode erreur par défaut car là, je vois pas.

En toutes cordialités.

gcyrillus-nomade

@Sudwebdesign super et merci , je doit être fatigué a stresser pour rien. Heureusement les beaux jours reviennent

bazooka07

La dernière release candidate ( RC7 ) est téléchargeable avec le lien ci-dessous :
https://github.com/pluxml/PluXml/archive/refs/tags/5.9.0-rc7.zip
ou bien :
git clone https://github.com/pluxml/PluXml.git

Le cas ou un plugin installé sur votre site ne supporte pas PHP-8.x.x est maintenant géré

gcyrillus-nomade

Bonjour,

Une typo dans parametres-plugin.php ligne 41 :

} catchException(Exception $e) {
au lieu de } catch(Exception $e) {
cdt

gcyrillus-nomade

Bonsoir,

un autre défaut avec les pages statiques qui déclenche une erreur si un template n'a pas été enregistré au préalable (page statique créer et affichable mais pas encore éditée).

Possible fix ligne 225 de class.plx.motor.php :
$this->template = $this->aStats[$this->cible]['template'] == ''? 'static.php' :$this->aStats[$this->cible]['template'];
Au lieu de $this->template = $this->aStats[$this->cible]['template'] ; pour appliquer un template par défaut lorsque celui-ci n'est pas encore définie.

Pour reproduire le bug, il suffit de créer une page statique, la cocher active et l'afficher au menu , sans l'éditer. $template prend alors la valeur ./themes/default/ sans spécifier de template.

gcyrillus-nomade

suite à https://forum.pluxml.org/discussion/7626/titre-dune-page-statique-sans-le-titre-du-site-a-la-suite

Le code est presque prés pour opter de choisir d'afficher #title et #subtitle depuis la fonction pageTtile. (peut-être est ce un reliquat d'une fonctionnalité d'une vielle version de PluXml).

Dans class.plx.show.php ligne 261 , il est possible de remplacer

        } else  {       
            $format = '#title - #subtitle';
        }

par

        } elseif ($format =='') {       
            $format = '#title - #subtitle';
        }

et de modifier dans le thème (header.php)

<title><?php $plxShow->pageTitle(); ?></title>

par

<title><?php $plxShow->pageTitle($format="#title"); ?></title>

pour répondre à la problématique du topic https://forum.pluxml.org/discussion/7626/titre-dune-page-statique-sans-le-titre-du-site-a-la-suite , je crois que c'est le genre de question que j'ai déjà vue passée.

Sudwebdesign

@gcyrillus-nomade bien vu, c'est un bogue.
je mettrai

        $format = $format ? $format : '#title - #subtitle';

au lieu de

        } else {
            $format = '#title - #subtitle';
        }

(voir 5.8.9)

Et garderai le <title> tel qu'il est, c'est au créateur du site d'en décidé (ou pageTitle)

Cordialement

bazooka07

Bonsoir,
Pour éviter une injection de code malveillant, je ferai plutôt comme ceci :

$format = !empty($format) ? htmlspecialchars($format) : '#title - #subtitle';