Merci !

j’ai installé EXEC-PHP, et après quelques heures d’installation (à devoir jouer avec les différents droits, et autres paramètres de admin), tout fonctionnaient.
Aujourd’hui, j’ouvre un article contenant du code d’un plugin, et le code a disparu, cependant, le plugin fonctionne sur la page enligne. Cependant, après avoir mis à jour l’article, le plugin ne fonctionne plus (logique car le code n’est plus présent).
Alors je refais la même manoeuvre du départ, mais cela ne fonctionne plus.

Comment cela se fait-il que :
- Le code ait disparu de l’article
- Comment puis-je faire fonctionner correctement exec-php

Merci beaucoup !!

Lorsqu’on rédige un article, on travaille en local dans le navigateur avec du javascript exécuté en local dans le navigateur. Lors d’une sauvegarde ou d’une publication, à ce moment là, oui le navigateur appelle le serveur qui travaille un peu (en php, pas en javascript).

Alors en effet, tout code qui s’exécute sur le serveur peut ouvrir une faille… Et le javascript ne s’exécute pas sur le serveur mais bien dans le navigateur donc pour moi, cela n’ouvre pas de faille (cqfd? )
Ce qui ouvre une faille c’est de croire que le javascript qu’on a écrit peut nous protéger des failles serveur.
Exemple: si on veut se protéger des injections sql avec un code javascript qui va vérifier que l’utilisateur n’a pas entré du code suspect dans un formulaire, cela ne sert absolument à rien du tout, c’est au niveau php qui faut valider l’entrée utilisateur avant d’interagir avec la base de données. Par défaut, il faut toujours considérer que les données qu’on reçoit d’un formulaire ont pu être altérée. Que ce soit par un plugin genre Firebug ou par ce qu’on appelle le « cross site scripting » par exemple.

Pour comprendre les nuances : http://fr.wikipedia.org/wiki/Architecture_trois_tiers

Bon, je suis peut-être un peu trop dans le technique là…

Je souhaite pouvoir continuer à utiliser l’éditeur en permanence par facilité

J’utilise en permanence l’onglet code, et franchement, çe n’est pas plus compliqué que ça

Cela ne ralenti donc en rien le blog. Au pire l’éditeur mais bon, avec la puissance des machines actuelle je pense que peu de gens ont à s’en tracasser…

D’une part, tout le monde n’a pas de machine puissante d’autre part ce n’est pas en local que le ralentissement se produit, puisque lorsqu’on rédige un article, on travaille directement sur le serveur !

Niveau sécurité, je ne vois pas comment du javascript pourrait amener une faille!?

Tout code qui s’exécute sur le serveur ouvre une faille de sécurité !

(Si c’est le cas, je veux bien qu’on m’explique car j’aimerais pouvoir m’en prémunir…)

Il suffit de saisir dans un moteur de recherche « sécurité et javascript », il y autant d’explications qu’on souhaite sur le sujet.

Encore une fois, c’est une question de choix pour ma part, c’est aussi simple d’utiliser ExexPHP qu’un plugin qui utilise du javascipt

De toutes façons pour PHP Execution, il faut quand même passer dans l’onglet html pour ajouter le code PHP, cela ne me dérange pas non plus.

En ce qui concerne le javascript supplémentaire, il n’est intégré qu’à l’éditeur wysiwyg. Le but est justement de ne pas devoir se tracasser de désactiver l’éditeur wysiwyg. Cela ne ralenti donc en rien le blog. Au pire l’éditeur mais bon, avec la puissance des machines actuelle je pense que peu de gens ont à s’en tracasser…

Niveau sécurité, je ne vois pas comment du javascript pourrait amener une faille!? (Si c’est le cas, je veux bien qu’on m’explique car j’aimerais pouvoir m’en prémunir…)
C’est exécuté côté client et avec des plugins comme Firebug les visiteurs font virtuellement ce qu’ils veulent du javascript… ce sera toujours du côté serveur (php donc) que l’attention sur la sécurité devra être portée, mais c’est une règle générale ca.