• Ça fonctionne parfaitement quand je l'inclus dans le contenu d'une page statique.
• Par contre, ça ne fonctionne pas quand je l'inclus dans le contenu d'un article. Pas de message d'erreur, rien.

Un <?php echo 'coucou' ?> m'a permis de voir que php ne fonctionne pas du tout dans les articles. Et du coup, je ne me souviens pas si ça a déjà fonctionné. Je suis en train de télécharger mes anciens articles pour faire une recherche à "<?php" pour vérifier.

Edit:
Alors, j'ai trouvé quelques articles ou je testais des conditions sur le compte utilisateur avec php pour afficher telle ou telle chose. Mais du coup, je ne sais même pas si ça a déjà fonctionné

Est-il possible de faire fonctionner php dans le contenu d'un article ou pas du tout ?
Merci !

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

Afin de faciliter la navigation sur mon site, j'aimerai proposer une navigation "dynamique" en permettant de "fermer" l'article pour revenir à la page précédente.
Avez-vous une idée de comment faire cela avec PluXml ?

Merci d'avance.

Merci aux équipes, superbe surprise il est en 5.8.2 et il tourne bien.

Lorsque l'on édite un article, il y a une légère régression au niveau des bascules (toggles) pour Chapô et Mot-clés.

Dans les moutures précédentes (..., 5.6, 5.7) si le chapô a du texte, il s'affiche, maintenant (5.8.x) non, il sont toujours masqués (en fait depuis le 28 avril 2019, #207 Afficher/masquer le chapeau et les tags d'un article en CSS3).

Comme la remarqué Bazooka07 l'attribut unchecked est inexistant en html, les erreurs sont là*.

Solution pour que cela tombe en marche :

[fichier : core/admin/article.php]

Il suffit de remplacer les deux ' unchecked' :

<?php echo (empty($_GET['a']) || ! empty(trim($chapo))) ? ' unchecked' : ''; ?>

···

<?php echo (empty($_GET['a']) || ! empty(trim($tags))) ? ' unchecked' : ''; ?>  

par ' checked' :

<?php echo (empty($_GET['a']) || ! empty(trim($chapo))) ? ' checked' : ''; ?>

···

<?php echo (empty($_GET['a']) || ! empty(trim($tags))) ? ' checked' : ''; ?>

Voir le PR #384

Un grand merci @bazooka07 car; comme prévus par le sieur; (et avec les correctifs), le chapô est ouvert pour un nouvel article 🤩 et a l'ancienne lorsque le chapô est peuplé (idem pour les tags).

Ps : La méthode employé me rappelle beaucoup celle du menu admin en mode mobile.

Ps² : Mea-culpa, c'est passé a l'as à l'époque 😯

*L’attribut attendu ici est checked et comme il est absent; AMHA, remplacé par unchecked pour test; les élément censés être ouvert ne le sont pas, car pour qu'une case à cocher soit décoché il suffit d'omettre checked 😉