En éditant les fichiers CSS du théme en cours , j'ai découvert que tout mes Unicode étaient nettoyé de leur backslash.

J'ai donc ajouté devant un caractère d’échappement pour les préservés, ce qui équivaut a transformé tout les "\" en "\\". Aprés quelques éditions, c'est juste agaçant.

Ce petit plugin vous évite une prise de tête inutile. https://github.com/gcyrillus/PLX-cssBackSlash

MAJ 02-22
MAJ 10-23 voir la réponse suivante pour les détails qui ne concerne que le js. Adresse repo inchangé mais branche v2.0

js

(function () {
    window.onload = function() {
        let txtA = document.querySelectorAll('[name="title"],[name="chapo"],[name="content"]');

        for (i=0;i<txtA.length;i++){  
          if(txtA[i].tagName == 'INPUT'){
            let content = txtA[i].value;
            txtA[i].value=  escapeRegex(content); 
          }
          else {  let content = txtA[i].innerHTML;
            txtA[i].innerHTML=  escapeRegex(content); 
          }                 
        }
        function escapeRegex(string) {  
            return string.replace(/[\\]/g, '\\$&');
        }
    }

})();

et les hooks utilisés (edition feuille de style, page statique et article )

#Ajoute un caractére d'échappement devant chaque \ trouvé dans une feuille de style
public function AdminSettingsEdittplFoot() {
echo self::BEGIN_CODE;
?>
$plgPlugin = $plxAdmin->plxPlugins->aPlugins['<?= __CLASS__ ?>'];
if(substr($tpl, strrpos($tpl, '.') + 1) =='css')    echo  '<script src="'.PLX_PLUGINS . '<?= __CLASS__ ?>/js/<?= __CLASS__ ?>.js"></script>';
<?php
echo self::END_CODE;
 }

        #Ajoute un caractére d'échappement devant chaque \ trouvé dans une page static
        public function AdminStaticFoot() {
            echo self::BEGIN_CODE;
?>
$plgPlugin = $plxAdmin->plxPlugins->aPlugins['<?= __CLASS__ ?>'];
echo  '<script src="'.PLX_PLUGINS . '<?= __CLASS__ ?>/js/<?= __CLASS__ ?>.js"></script>';
<?php
            echo self::END_CODE;
        }

        #Ajoute un caractére d'échappement devant chaque \ trouvé dans une page article
        public function AdminArticleFoot() {
            echo self::BEGIN_CODE;
?>
$plgPlugin = $plxAdmin->plxPlugins->aPlugins['<?= __CLASS__ ?>'];
echo  '<script src="'.PLX_PLUGINS . '<?= __CLASS__ ?>/js/<?= __CLASS__ ?>.js"></script>';
<?php
            echo self::END_CODE;
        }

cdt,
GC

je viens de remarqué un bogue lorsque l'on ajoute une catégorie a partir de la page d'édition d'un article, celle-ci peut remplacer une catégorie existante.

Pour reproduire ce bug.

• réorganiser le sens d'affichage des catégories sans mettre la dernière catégorie en dernier (a partir de la page catégorie.php).
• édité ou crée un article sans l'enregistrer,mais ajouter une nouvelle catégorie (à partir de la page article.php).

Cette nouvelle catégorie prendra invariablement le N° + 1 de la dernière catégorie affiché dans le tableau catégorie , si cette dernière de votre liste est la numéro 3 et que vous avez 5 catégories, vous aurez toujours 5 catégorie et la numéro quatre aura été simplement éditer.

si ce bug est déjà connu et documenter, merci de me rediriger vers le(s) sujet(s) le mentionnant.

Pour Infos, défaut logique provenant de

    /**
     *  Méthode qui retourne le prochain id d'une catégorie
     *
     * @return  string  id d'un nouvel article sous la forme 001
     * @author  Stephane F.
     **/
    public function nextIdCategory() {
        if(is_array($this->aCats)) {
            $idx = key(array_slice($this->aCats, -1, 1, true));
            return str_pad($idx+1,3, '0', STR_PAD_LEFT);
        } else {
            return '001';
        }
    }

dans class.plx.admin.php , sans hook, impossible d'effectuer une correction au bon endroit sans toucher aux entrailles de PluXml.

Le premier hook dispo plxAdminEditCategoriesNew est déjà trop loin dans le deroulé du script où un

$cat_id = str_pad(count(array_column($this->aCats, null))+1,3, '0', STR_PAD_LEFT);

aurait pu être efficace à la place du

$cat_id = $this->nextIdCategory();

Cdt

Edit: Je me demande si finalement cette fonction est utile car utilisée uniquement dans ce cas .

j'essaie d'ajouter les balises manquantes aux articles générés et en particulier celle de la date de création de l'article.

Cette info manquante génère un message d'erreur de class.plx.date.php date2Array($date) dans l’édition de l'article.

Malgré mes tentatives, celle-ci reste invariablement vide alors que je peut remplir les autres (thumbnail par exemple).

Un truc m’échappe, car même en rentrant une date au format requis(me semble t-il) dans class.plx.generator.php, par exemple $art['date_creation']='202104071114'; cela n'a aucun effet sur l'enregistrement au moment de la création des articles, cette valeur reste vide.

(le plugin LesFables génère le même message d'erreur: date_creation vide )

Ces deux plugins sont fonctionnels.

Cdt

Aujourd'hui, en voulant éditer un de mes propres commentaire (en tant qu'admin) j'ai été confronté à un comportement que je ne comprends pas et qui me bloque:

En cliquant sur le lien "éditer" depuis l'espace d'admin dans la partie gestion des commentaires, je me retrouve sur une page sans le commentaire en question et qui renvoie à mon tout premier article.

En plus j'ai un lien lié à mon pseudo, et ça aussi je voudrais le changer, sauf que je ne vois plus du tout cette option dans mon profil...

M'enfin, bref je suis un peu perdu

Merci à celui ou celle qui viendra s'intéresser à ce petit désagrément