Cmixml 1.1.0 / PluXml 5.7
Bonjour,
Depuis un peu plus d'un an j'utilise PluXml, initialement en version 5.6 et depuis décembre 2018 la version 5.7.
Voulant changer d'éditeur WYSISIG, j'ai installé Cmixml en version 1.1.0.
J'ai bien réussi à l'activer et à le configurer mais par contre il n'apparaît pas quand je crée ou quand je rédige un article.
Pour information, j'utilise Ngnix avec PHP 7.3.
Auriez-vous début de piste pour résoudre ce problème ?
Vous remerciant pour vos retours.
Très bonne journée à tous.
Eivan
Mots clés:
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Salut Eivan,
Est-ce que tu as désactivé l'autre éditeur que tu utilisais avant ? Nettoyé le cache de ton navigateur ?
Essaye de modifier l'ordre dans lequel les plugins s'activent ?
Sinon faudra attendre que Sudwebdesign repasse dans le coin
Bonjour,
@kowalsky : Merci pour pour ta réponse. J'ai effectivement supprimé l'ancien éditeur, désactivé tous les autres plugins, cache de mon navigateur nettoyé, mais rien n'y fait.
Sur les conseils de mon Frangin ;), j'ai réinstallé une version propre de PluXml sur une Debian 10 avec PHP 7.3 et Nginx 1.14.2. J'ai repris mes datas et installé seulement Cmixml, sans changer le moindre fichier de configuration (de Nginx et de PHP) et là ça fonctionne. Sur mon serveur j'ai réinstallé une version 5.7 de PluXml avec mes datas et seulement Cmixml et là de nouveau le même problème.
Un indice, sur mon serveur (avec Cmixml qui ne s'affiche pas) quand je vais dans sa page de configuration elle n'est pas présentée de la même manière que sur ma Debian (cf. image ci-dessous) avec un gros logo PHP. Sur ma Debian, les options articles, catégories... sont présentées en colonnes alors que sur mon serveur catégories est sous articles, pages statiques sous catégories et ainsi de suite... Peut-être que j'ai un problème dans ma configuration PHP ?
Je suis en train de regarder mes fichiers de configurations Nginx et PHP, mais pour l'instant toujours pas de Cmixml qui s'affiche :-(
Bonne journée,
Eivan
Bonjour,
J'ai résolu mon problème.
NB : Les notes ci-dessous pourront servir au(x) développeur(s) de cmixml que je remercie pour son/leur travail, cmixml rend l'édition d'article beaucoup plus facile ;)
Après avoir testé avec une version à partir de zéro de PluXml, la réinstallation de PHP sur mon serveur, le dernier test à faire était au niveau de Nginx. Cela venait d'une option trop restrictive au niveau de la configuration de mon serveur web.
J'avais l'option suivante :
add_header Content-Security-Policy "default-src https://mondomaine.fr:443";
Cela engendrait les erreurs suivantes sur la page de configuration de cmixml :
Content Security Policy: Les paramètres de la page ont empêché le chargement d’une ressource à inline (« default-src »). parametres_plugin.php
Content Security Policy: Les paramètres de la page ont empêché le chargement d’une ressource à inline (« default-src »). parametres_plugin.php:61:1
Content Security Policy: Les paramètres de la page ont empêché le chargement d’une ressource à data:image/png;base64,iVBORw0KGgoAAAANSU… (« default-src »).
Content Security Policy: Les paramètres de la page ont empêché le chargement d’une ressource à inline (« default-src »).
et les erreurs suivantes sur la page d'un article où cmixml n'apparaissait pas :
Content Security Policy: Les paramètres de la page ont empêché le chargement d’une ressource à inline (« default-src »). 3 article.php
Content Security Policy: Les paramètres de la page ont empêché le chargement d’une ressource à inline (« default-src »). article.php:1:1
Content Security Policy: Les paramètres de la page ont empêché le chargement d’une ressource à inline (« default-src »). 2 article.php
Content Security Policy: Les paramètres de la page ont empêché le chargement d’une ressource à inline (« default-src »). article.php:17:1
Content Security Policy: Les paramètres de la page ont empêché le chargement d’une ressource à inline (« default-src »). article.php
Content Security Policy: Les paramètres de la page ont empêché le chargement d’une ressource à inline (« default-src »). article.php:65:1
Content Security Policy: Les paramètres de la page ont empêché le chargement d’une ressource à inline (« default-src »). 66 article.php
Content Security Policy: Les paramètres de la page ont empêché le chargement d’une ressource à inline (« default-src »). article.php:293:1
Content Security Policy: Les paramètres de la page ont empêché le chargement d’une ressource à inline (« default-src »). article.php:509:1
Content Security Policy: Les paramètres de la page ont empêché le chargement d’une ressource à data:image/png;base64,iVBORw0KGgoAAAANSU… (« default-src »).
J'ai donc modifié l'option par la ligne ci-dessous et cela fonctionne :
add_header Content-Security-Policy "default-src https://mondomaine.fr:443; script-src https: 'unsafe-inline'; style-src https: 'unsafe-inline'";
Bonne journée à tous,
Eivan
Tu as ainsi levé une sécurité liée au javascript...
Ce header est fait pour s'assurer que ce que tu charges avec tes scripts provient bien de ton server (que tu maîtrises a priori) et pas d'un serveur tiers (qui peut t'envoyer n'importe quoi n'importe quand). En faisant sauter cette sécurité, c'est comme si tu avais une porte blindée sur une cloison de plâtre...