Exec-PHP : mode d’emploi

Mise à jour le 6 juillet 2008

Cette page est la traduction de la documentation mise en ligne par le développeur du plugin. N’hésitez pas à nous faire part de vos remarques, notamment en cas d’erreur de traduction ou de fautes qui nous auraient échappé ;-)

Concernant le fonctionnement du plugin, je vous invite à poser vos questions sur le blog du développeur.

Que fait ce plugin ?

Le plugin Exec-PHP exécute du code<?php ?> dans vos billets, pages et widgets textes.

Faites vite ! Où puis-je le télécharger ?

Télécharger Exec-PHP 4.8 ici !

Pourquoi les explications ci-dessous sont-elles si longues ?

Parce que je hais les extensions qui sont mal documentées ! Même le plus petit bout de code a besoin de documentation. La documentation est plutôt exhaustive. Vous pouvez sauter les sections qui ne vous intéressent pas. Si vous avez une question au sujet de ce plugin, merci de vous assurer que vous utilisez bien la dernière version et que la réponse ne se trouve pas sur cette page ou dans les commentaires sur la page du plugin. Si vous vous en êtes bien assuré ! alors, vous pouvez poser une question ici.

Table des matières

  1. Introduction
    1. Motivation
    2. Fonctionnalités
    3. Concepts de Exec-PHP
    4. Différences avec les plugins similaires
      1. Sniplets
      2. RunPHP 0.2.2 (Mark Somerville)
      3. RunPHP 2.1.1 (James Van Lommel)
      4. PHP Exec 1.7
      5. EzStatic 3
      6. Autres plugins
  2. Installation
    1. Configuration requise
    2. Installer le plugin
    3. Mettre à jour depuis une version précédente
    4. Mettre à jour depuis la version 2.0 ou antérieure
    5. Passer à la version 4.2 ou ultérieure
    6. Désactiver le plugin
    7. Désinstaller le plugin
    8. Exec-PHP dans votre langue
    9. Traduire Exec-PHP
  3. Utilisation
    1. Exécuter du code PHP
    2. Configuration
    3. Mauvaise configuration
    4. Test de base
    5. Balises XHTML de WordPress
    6. Ecrire du code PHP avec l’éditeur WYSIWYG
    7. Autoriser l’écriture de code PHP dans les articles
    8. Autoriser l’exécution de code PHP dans les articles
    9. Autoriser le code PHP dans les widgets
    10. Vue générale des tâches et configuration nécessaire de WordPress
    11. Un mot sur la sécurité
    12. Failles de sécurité
  4. Problèmes
    1. Incompatibilité avec les autres plugins et thèmes
    2. Limitations
    3. Rapporter des bugs
    4. Tester les fonctionalités des plugins
    5. FAQ – Foire aux questions
      1. Pourquoi le plugin Exec-PHP plugin ne fonctionne-t-il pas comme décrit ici ?
      2. Pourquoi WordPress se trompe-t-il avec mes tags <?php ?> quand je sauvegarde un article ?
      3. Pourquoi le plugin provoque-t-il une erreur eval() lors de l’exécution du code ?
      4. Comment juste afficher le code PHP sans que celui-ci ne s’exécute ?
      5. Pourquoi mon flux rss contient-il des erreurs ?
      6. Pourquoi mon fichier PHP provoque-t-il des erreurs ?
      7. Le plugin fonctionne-t-il avec WordPress MU ?
  5. Passé, présent et futur
    1. Nouvelles versions
    2. Historique des anciennes versions
      1. Version 4.8 (05-07-2008)
      2. Version 4.7 (05-05-2008)
      3. Version 4.6 (06-04-2008)
      4. Version 4.5 (24-03-2008)
      5. Version 4.4 (29-01_2008)
      6. Version 4.3 (11-12-2007)
      7. Version 4.2 (03-11-2007)
      8. Version 4.1 (27-10-2007)
      9. Version 4.0 (25-10-2007)
      10. Version 3.4 (08-10-2007)
      11. Version 3.3 (11-08-2007)
      12. Version 3.2 (02-10-2007)
      13. Version 3.1 (09-02-2007)
      14. Version 3.0 (06-08-2006)
      15. Version 2.0 (22-12-2005)
      16. Version 1.2 (04-12-2005)
      17. Version 1.1 (19-08-2005)
      18. Version 1.0 (18-08-2005)
    3. Développement

Introduction

Motivation

En 2005, lorsque j’ai eu besoin d’un plugin PHP pour mon propre blog, je n’en ai trouvé aucun qui me permettait d’utiliser du code PHP comme je le souhaitais. Par exemple, certains plugins requerraient du code PHP, qui devait être encapsulé dans des tags XHTML comme <phpcode> </phpcode>. Je voulais simplement utiliser du code PHP <?php ?>. Certains des plugins que j’ai testés évaluaient le code une fois que WordPress avait appliqué certains filtres comme la « texturisation ». WordPress « texturisait » le code PHP et les plugins devaient les « détexturiser ». Pour du code complexe, ceci ne peut pas être effectué correctement et cela provoque des erreurs même si le code est correct.

Caractéristiques

Concepts de Exec-PHP

Techniquement Exec-PHP exécute le texte qui se trouve entre les balises <?php ?> et le conduit à l’exécution de la fonction eval(). Le plugin n’analyse pas votre code. Bien que le plugin intègre quelques mesures de sécurité, il est conseillé de ne permettre son emploi qu’à des utilisateurs de confiance.

Différences avec les plugins similaires

Il existe de nombreux plugins PHP qui offrent des fonctionnalités diverses. La liste suivante a été élaborée au début de 2007 ; elle est sans doute incomplète et probablement périmée, certains plugins ayant peut-être été mis à jour, avec de nouvelles caractéristiques. Sont cités les plugins avec leur numéro de version.

Sniplets

Le plugin Sniplets de John Godley est une bonne alternative à Exec-PHP. Bien qu’il soit plus difficile à configurer que Exec-PHP, vous pouvez gagner en sécurité en raison de la façon dont le plugin Sniplets fonctionne.

RunPHP 0.2.2 (Mark Somerville)

Le plugin RunPHP de Mark Somerville utilise des balises XHTML pour se différencier du code HTML. Il effectue des conversions étranges pour « fixer » les articles « texturisés » et ne supporte pas les rôles et autorisations de WordPress.

RunPHP 2.1.1 (James Van Lommel)

Le plugin RunPHP de James Van Lommel produit des erreurs avec la plupart du code de test ci-dessous.

PHP Exec 1.7

Le plugin PHP Exec de Priyadi Iman Nurcahyo utilise des balises XHTML pour se différencier du code HTML. Il effectue des conversions étranges pour « fixer » les articles « texturisés ».

EzStatic 3

Le plugin EzStatic 3 de Owen Winkler n’exécute aucun test #16 (voir ci-dessous).

Autres plugins

Aujourd’hui, il existe de nombreux plugins similaires mais je suis trop paresseux pour continuer cette liste ! Si Exec-PHP ne dispose pas des fonctionnalités dont vous avez absolument besoin, vous pouvez consulter les plugins sur le site de WordPress ou poster une demande ici.

Installation

Configuration requise

Les logiciels suivants doivent être installés sur votre serveur web pour utiliser le plugin Exec-PHP :

Installer le plugin

Si vous avez déjà installé un plugin WordPress, l’installation ne vous posera pas de difficulté :

Et c’est tout ! Le reste va de soi ;-)

Mettre à jour depuis une version précédente

Si aucune mention n’est indiquée sur cette page, vous pouvez mettre à jour le plugin depuis une ancienne version en suivant les indications données au paragraphe Désinstaller le plugin puis suivez les instructions d’installation. Notez qu’une mise à jour peut nécessiter la migration de votre configuration depuis une ancienne version. Vous ne pourrez donc pas revenir à une ancienne version après avoir effectué la mise à jour du plugin.

Mettre à jour depuis la version 2.0 ou plus ancienne

L’arborescence des répertoires ayant changé, vous devrez supprimer manuellement l’ancien fichier exec-php.php du répertoire /wp-content/plugins/ puis suivre les instructions d’installation. Si vous avez utilisé les balises [?php ?] ou un ancien format de balises PHP < ?php ?> (notez l’espace) ou <? ?> vous devrez migrer ces anciens tags au format <?php ?>. Vous pouvez effectuer ces changements manuellement ou utiliser le plugin Search and Replace. Depuis la version 3.1, la migration automatique n’est plus supportée.

Mettre à jour depuis la version 4.2 ou supérieure

En fonction de l’installation précédente de Exec-PHP, vous pouvez voir s’afficher un message d’alerte de sécurité de Exec-PHP dans votre panneau d’administration. Reportez-vous à cette section pour résoudre ce problème.

Désactiver le plugin

La désactivation du plugin peut provoquer dans vos articles et widgets qui contiennent du code PHP un affichage bizarre ou rendre visible tout votre code PHP à vos lecteurs. Pour cette raison, votre code PHP ne devrait pas contenir de données sensibles, comme par exemple des mots de passe.

Désinstaller le plugin

Pour désinstaller le plugin, supprimez tout simplement le répertoire exec-php de votre dossier /wp-content/plugins/. Vous n’avez pas besoin de désactiver le plugin dans le panneau d’administration de WordPress. Lisez ce paragraphe si vous souhaitez savoir ce qui peut arriver à votre code PHP dans ce cas.

Exec-PHP dans votre langue

Le plugin est fourni avec les fichiers de langue anglais et allemand. Autres traductions disponibles :

  • Anglais (par défaut dans le fichier d’achives Exec-PHP)
  • Allemand (fourni dans le fichier d’archives Exec-PHP)
  • Français (merci à Lise)
  • Russe (merci à Dimox)
  • Espagnol (merci à Diego)

Traduire Exec-PHP

Si Exec-PHP n’est pas traduit dans votre langue, téléchargez le fichier d’archives Exec-PHP, utilisez un outil comme PoEdit pour traduire le fichier languages/exec-php.pot. Si vous êtes suffisamment courageux, vous pouvez aussi traduire cette documentation ;-). Si cela vous demande trop de travail, traduisez seulement le fichier readme-generic.html. Ecrivez ensuite un commentaire sur la page du plugin et votre nom sera mentionné parmi les contributeurs !

Utilisation

Exécuter du code PHP

Avec Exec-PHP, vous pouvez exécuter du code PHP dans les extraits, vos billets et vos pages (appelés ici articles) et aussi dans les widgets textes. Pour exécuter du code, saisissez du code PHP comme vous le feriez habituellement.

Ecrire du code dans les articles ou les widgets textes nécessite de configurer le blog et les droits des utilisateurs. Pour que le plugin fonctionne correctement avec du code PHP code dans les articles des utilisateurs :

Configuration

Les options du plugin sont disponibles depuis le panneau d’administration ‘Réglages > Exec-PHP’. Le menu de configuration de Exec-PHP est uniquement accessible aux utilisateurs qui disposent de l’autorisation ‘Editer les plugins’. Cette autorisation est en général attribuée au seul administrateur du blog. Si vous avez désactivé Javascript ou si vous utilisez Exec-PHP avec WordPress 2.0.x, vous ne verrez pas ou pas complètement le menu de configuration du plugin.

Le menu de configuration est divisé en deux parties, la section Configuration et la section Information. Dans la section Configuration vous pouvez ajuster les droits donnés aux utilisateurs à vos besoins et dans la section Information préciser quels utilisateurs sont autorisés à exécuter du code PHP selon différents scénarios.

Configuration du plugin

Mauvaise configuration

Si le blog ou les autorisations des utilisateurs sont mal configurés pour l’écriture de code PHP, un avertissement sera affiché lors de la rédaction d’un article ou de la configuration des widgets.

 Avertissement du mode WYSIWYG width=

L’avertissement du mode WYSIWYG peut être désactivé dans le menu ‘Profil de l’utilisateur’. Mais ceci n’est pas recommandé, car l’utilisation de l’éditeur visuel peut rendre le code PHP inutilisable de façon permanente.

Avertissement Exec-PHP dans votre profil

Avertissement Exec-PHP dans votre profil

Si vous avez désactivé Javascript ou si vous utilisez Exec-PHP avec WordPress 2.0.x, le message d’avertissement de Exec-PHP ne sera pas affiché, même si votre blog ou les autorisations des utilisateurs sont mal configurés.

Test de base

Pour vérifier que le plugin fonctionne correctement, connectez-vous à votre blog comme Administrateur, effectuez la configuration comme indiqué ci-dessus, écrivez un nouvel article et écrivez le texte suivant :

<?php echo "Ceci est le plugin Exec-PHP 'Bonjour le monde'"; ?>

Ce test doit toujours fonctionner. Lorsque vous affichez l’article et que tout est en ordre, vous devriez voir :

Ceci est le plugin Exec-PHP 'Bonjour le monde'

Balises XHTML de WordPress

En fonction du code PHP que vous utilisez, il peut être nécessaire de désactiver l’option ‘WordPress doit automatiquement corriger les balises XHTML non valides’. Ceci peut être fait dans le panneau d’administration dans le menu ‘Réglages > Ecriture’. Le mieux est de toujours désactiver cette option. Une alternative à la désactivation de cette option est d’installer le plugin Mime Type Plugin et d’utiliser le type mime text/html individuellement pour chaque article qui contient du code PHP.

Ecrire du code PHP avec l’éditeur visuel (WYSIWYG)

Pour écrire du code PHP dans un article, l’éditeur WYSIWYG doit être désactivé, depuis le panneau d’administration ‘Utilisateurs > Votre profil’. Il ne suffit pas d’utiliser l’onglet ‘HTML’ tout en laissant activée dans votre profil l’option ‘Utiliser l’éditeur visuel pour écrire’. Ceci rendrait tout votre code PHP inutilisable de façon permanente.

Au lieu de désactiver de façon permanente l’éditeur visuel dans votre profil, vous pouvez le désactiver temporairement lors de la rédaction de certains articles avec le plugin Deactivate Visual Editor. Je ne l’ai pas testé mais cela semble être une bonne alternative pour ceux qui souhaitent utiliser l’éditeur WYSIWYG.

Si vous souhaitez écrire du code PHP avec l’éditeur TinyMCE WYSIWYG, vous pouvez essayer certains plugins TinyMCE qui autorisent l’écriture de code PHP. Ces questions ne sont pas prises en compte par le plugin Exec-PHP. Pour ma part, j’estime qu’il existe des conflits entre l’écriture de code PHP et l’utilisation de l’éditeur visuel. Je n’envisage donc pas de modifier le plugin Exec-PHP pour prendre en compte l’utilisation de l’éditeur WYSIWYG lors des prochaines versions.

Autoriser l’écriture de code PHP dans les articles

Avant d’exécuter du code PHP, les utilisateurs doivent d’abord écrire un article. ;-) Les utilisateurs peuvent rencontrer des difficultés à écrire du code PHP, parce que WordPress modifiera le code (et donc entravera son exécution plus tard) lors de la sauvegarde de l’article. Ceci est dû à l’option ‘unfiltered_html’ pour laquelle les utilisateurs doivent avoir l’autorisation.

La configuration des autorisations et des rôles des utilisateurs n’est pas l’objet de cette documentation. Parce que WordPress ne dispose pas en standard d’un menu pour configurer les rôles et les autorisations, vous devez installer un plugin capable de le faire comme indiqué dans le paragraphe Configuration requise.

Autoriser l’exécution de code PHP dans les articles

Après l’installation du plugin, l’exécution de code PHP est limitée par défaut à l’Administrateur. Il faut donc donner aux utilisateurs l’autorisation d’employer ‘exec_php’, pour qu’ils puissent exécuter du code PHP dans leurs articles.

La configuration des autorisations et des rôles des utilisateurs n’est pas l’objet de cette documentation. Parce que WordPress ne dispose pas en standard d’un menu pour configurer les rôles et les autorisations, vous devez installer un plugin capable de le faire comme indiqué dans le paragraphe Configuration requise.

Autoriser l’exécution de code PHP dans les widgets textes

Par défaut l’exécution de code PHP dans les widgets est activée. Tout utilisateur disposant de l’autorisation ‘switch_themes’ (choix du thème) peut écrire et exécuter du code PHP dans les widgets textes. Parce que ceci peut constituer une faille de sécurité, vous pouvez désactiver l’exécution de code PHP dans les widgets depuis la page de configuration du plugin.

Vue générale des tâches et configuration nécessaire de WordPress

Le tableau suivant montre quelle configuration doit être appliquée pour effectuer certaines tâches avec le plugin :

Tâche Désactiver les balises XHTML Désactiver le mode WYSIWYG Autoriser ‘exec_php’ Autoriser ‘unfiltered_html’ Autoriser ‘switch_themes’
Ecrire/éditer du code PHP dans les articles X X X
Exécuter du code PHP dans les articles X
Ecrire/éditer du code PHP dans les extraits X
Exécuter du code PHP dans les extraits X
Ecrire/éditer du code PHP dans les widgets X X
Exécuter du code PHP dans les widgets X

Pour que les choses soient claires : si un utilisateur souhaite écrire un nouvel article et exécuter du code PHP à l’intérieur de celui-ci, il doit à la fois être autorisé à utiliser ‘exec_php’ et disposer de l’autorisation ‘unfiltered_html’. Sinon, le code PHP sera perdu lors de la sauvegarde de l’article et le code PHP lui même sera affiché au lieu d’être exécuté. Pour écrire et exécuter du code dans un extrait, l’utilisateur n’a besoin que de l’autorisation ‘unfiltered_html’.

Si un utilisateur souhaite écrire du code PHP dans un widget texte, il n’a besoin que de l’autorisation ‘unfiltered_html’. L’exécution de code PHP dans les widgets n’est pas limitée à une quelconque autorisation. Cela signifie que chaque utilisateur de votre blog pouvant écrire des widgets – ce qui est limité à ceux qui disposent de l’autorisation ‘switch_themes’ – peut exécuter du code PHP.

Un mot au sujet de la sécurité

Avec ce plugin, un utilisateur dispose de toutes les possibilités offertes par le codage en PHP et l’interface de WordPress. Il n’existe aucune restriction à l’exécution d’un ensemble de fonctionnalités. Autoriser les utilisateurs à écrire et exécuter du code PHP exposera votre installation WordPress en particulier et votre serveur de manière générale. Un utilisateur pourrait facilement prendre la main sur votre blog, votre serveur ou lancer des actions répréhensibles sur le réseau Internet. Dans le doute, n’autorisez pas l’exécution de code PHP. Votre configuration peut-être facilement adaptée à chaque utilisateur.

Failles de sécurité

En fonction de votre configuration, un message d’alerte de sécurité peut s’afficher en vous renvoyant vers la section d’information sur les failles de sécurité dans le menu de configuration du plugin. Ceci se produit typiquement quand certains de vos utilisateurs (appelés Editeurs), sont autorisés à éditer les articles des autres utilisateurs. Si l’éditeur n’est pas autorisé à exécuter du code PHP mais s’il peut éditer les articles d’autres utilisateurs, il peut ajouter du code malicieux à leur article.

Pour éviter ce problème, le plugin Exec-PHP introduit l’autorisation ‘edit_others_php’ (éditer le code PHP des autres auteurs). Il est conseillé soit d’ajouter les deux autorisations ‘exec_php’ et ‘edit_others_php’ ou de n’en donner aucune à vos éditeurs. Vous voudrez probablement créer deux rôles d’éditeurs différents, l’un autorisé à exécuter et éditer le code PHP des autres, et le second qui ne l’est pas.

Problèmes

Incompatibilités avec les autres plugins ou thèmes

Aucune incompatibilité avec les autres plugins ou thèmes n’est connue.

Limitations

En dehors des limitations d’utilisation de l’éditeur visuel (WYSIWYG) mentionné précédemment, aucun autre problème n’est connu.

Rapporter des bugs

Vous pouvez rapporter les bugs en écrivant un commentaire. Avant de le faire, soyez certain que votre script PHP s’exécute correctement dans un fichier autre que sur votre blog. S’il s’exécute normalement, assurez-vous d’avoir bien relu la « FAQ ». Si vous êtes bien sûr qu’il s’agit d’un bug, gardez présent à l’esprit que les commentaires de WordPress ne sont pas conçus pour écrire du code, convertissez-le en XHTML correct avant d’envoyer votre commentaire, faites un lien externe vers le code incriminé ou utilisez le formulaire pour contacter l’auteur du plugin.

Tests de vérification du fonctionnement du plugin

Ci-dessous se trouve une liste de tests pour vérifier le fonctionnement du plugin. Dans la colonne de gauche se trouve, le code PHP directement saisi comme indiqué, dans la colonne de droite, le texte tel qu’affiché grâce au plugin Exec-PHP, si celui-ci fonctionne correctement. Si vous visualisez cette page comme une page HTML statique, le code PHP ne sera évidemment pas exécuté et l’affichage ne sera pas correct. En raison du contenu de ce test, cette page n’est pas vérifiée en tant que XHTML. Si vous pensez que votre plugin favori fonctionne mieux, testez les lignes suivantes et vérifiez leur affichage !

# Code saisi Affichage
1
<?php ?>
2
<?php echo "a?>1"; ?>
a?>1
3
<?php echo 'b?>1'; ?>
b?>1
4
<?php echo "a?>2"; ?>
a?>2
5
<?php echo 'b?>2'; ?>
b?>2
6
<?php?>
7
<?php echo"a?>3"; ?>
a?>3
8
<?php echo'b?>3'; ?>
b?>3
9
<?php echo"a?>4"; ?>
a?>4
10
<?php echo'b>4'; ?>
b?>4
11
<?php echo "c"; ?>1";?>
c1″;?>
12
<?php echo 'd'; ?>1';?>
d1′;?>
13
<?php echo "c'; ?>2";? >
c’;?>2
14
<?php echo 'd";?>3'; ?>
d »;?>3
15
<?php
echo "impressionnant\n '";
echo 'cha&icirc;ne\' "';
echo "\n\ttraitement\"";
?>
impressionnant
‘chaîne’  »
traitement »
16
<?php if (1) { ?>
<b>Traite CECI !</b>
<?php } else { ?>
<i>Traite CELA !</i>
<?php } ?>
Traite CECI !

FAQ – Foire aux questions

Pourquoi le plugin Exec-PHP plugin ne fonctionne-t-il pas comme décrit ici ?

Si le plugin ne fonctionne pas comme indiqué ici, bien que vous ayez configuré correctement votre blog et les autorisations des utilisateurs, il est vraisemblable qu’un autre plugin interfère avec les fonctionnalités de Exec-PHP. Pour en être sûr, désactivez tous les autres plugins sauf Exec-PHP et vérifiez si les dysfonctionnements sont encore présents.

Pourquoi WordPress se trompe-t-il avec mes tags <?php ?> quand je sauvegarde un article ?

RTFM. Lisez ceci.

Pourquoi le plugin provoque-t-il une erreur eval() lors de l’exécution du code ?

Si un message comme celui-ci s’affiche : ‘Some error in /home/minime/htdocs/blog/wp-content/plugins/exec-php/runtime.php(41) : eval()’d code on line 4′, il est temps de réparer votre code PHP. Si vous ne trouvez pas votre erreur, faites tourner votre code dans un fichier séparé pour supprimer tous les bugs, puis copiez le code dans votre article ou widget. Pour réduire le nombre de commentaires de la page du plugin, je supprimerai tous les billets relatifs à ce sujet.

Comment juste afficher le code PHP sans que celui-ci ne s’exécute ?

Si vous souhaitez juste afficher du code sans que celui-ci ne s’exécute, e.g. comme sur cette page, vous devez être sûr de convertir correctement votre code en XHTML. Vous devez alors convertir au moins les balises :

< en &lt; 
> en &gt; 
et & en &amp;

Vous pouvez automatiser un peu cette conversion en utilisant le plugin WP-Simplecode.

Pourquoi mon flux rss contient-il des erreurs ?

Posons l’hypothèse que votre code fonctionne en dehors d’un article. Le parser PHP peut générer des erreurs dans votre flux RSS même pas si vous visualisez votre article et que tout vous semble correct. Ceci peut se produire si vous avez défini vos propres fonctions, classes, etc. Pour la lecture des flux RSS, WordPress lit le contenu de chaque article deux fois (une pour le sommaire, une pour l’article entier), le code PHP est donc exécuté deux fois. Dans l’exemple suivant, le code pourra fonctionner dans votre article si vous le visualisez dans une page web mais pourra provoquer une erreur dans votre flux RSS.

Article :

<?php
function hello()
{
  echo 'Bonjour le monde';
}
hello();
?>

Comme règle générale, je conseillerais d’isoler toutes les définitions dans un fichier et d’appeler celui-ci avec la fonction require_once(). Dans l’exemple ci-dessus, le code serait en deux parties, l’une dans votre article, l’autre dans un fichier.

Article :

<?php
require_once(get_option('home'). '/fichier.php');
hello();
?>

Fichier (ici fichier.php) :

<?php
function hello()
{
  echo 'Bonjour le monde';
}
?>

Veuillez noter que require_once() utilise un chemin complet. Ceci est obligatoire parce qu’un chemin relatif pourrait pointer vers un autre fichier pour visualiser la page principale de votre blog, un simple article, le flux RSS, etc.

Pourquoi mon fichier PHP provoque-t-il des erreurs ?

Posons comme hypothèse que votre code fonctionne en dehors d’un article et que le chemin jusqu’à ce fichier soit correct. Le parser PHP peut générer des erreurs même si tout semble correct. Ceci peut se produire si votre fichier est exécuté à un niveau global et n’utilise pas le mot clé global pour déclarer ses variables globales. A titre d’exemple, créez un nouvel article avec le code suivant :

Article :

<?php require_once(get_option('home'). '/fichier.php'); ?>

Puis copiez le code suivant dans un nouveau fichier nommé fichier.php et placer celui-ci à la racine de votre site :

Fichier (ici fichier.php) :

<?php
$g_text = 'Bonjour le monde';
function hello()
{
  global $g_text;
  echo $g_text;
}
hello();
?>

Bien que le fichier fichier.php s’exécute correctement si vous y accédez directement, ce test se terminera de façon inattendue parce qu’une valeur sera assignée à la variable $g_text sans prendre en compte la portée globale qu’utilise WordPress pour exécuter votre code. Ceci est dû à la façon dont WordPress fonctionne et il n’y a pas moyen de résoudre cette question avec ce plugin. Vous pouvez vous en sortir en ajoutant le code PHP suivant dans votre article avant d’inclure le traitement que vous désirez ou dans le fichier que vous souhaitez utiliser au tout début :

global $g_text;

Je n’ai pas besoin de vous dire, qu’il vous faudra faire de la sorte pour chaque variable globale, si cela n’a pas déjà été réalisé par le programmeur d’origine. Un autre moyen serait de contacter le programmeur et de lui demander gentiment de modifier son code !

Le plugin fonctionne-t-il avec WordPress MU ?

WordPress n’est pas WordPress MU. Ce plugin a été écrit pour WordPress. Si vous souhaitez écrire un patch pour qu’il fonctionne avec WordPress MU, je serais heureux de l’inclure dans une prochaine version !

Passé, présent et futur

Nouvelles versions

De nouvelles versions seront publiées de temps en temps pour inclure de nouvelles fonctionnalités ou corriger des bugs. Vous pouvez être tenu(e) au courant du développement du plugin en vérifiant manuellement sur le blog du développeur ou en vous abonnant aux commentaires. Depuis la version 2.3 de WordPress, vous serez également informé(e) depuis le menu « Extensions » de WordPress.

Les nouvelles versions seront toujours documentées et incrémentées. Néanmoins, l’archive téléchargeable pourra être modifiée de temps en temps sans que le numéro de version ne soit incrémenté. Cela pourra se produire si la documentation est mise à jour. Dans ce cas, aucune information ne sera donnée ici, parce que cela peut arriver fréquemment.

Historique des anciennes versions (paragraphe partiellement traduit)

Version 4.8 (2008-07-05)
Version 4.7 (2008-05-05)
  • Téléchargez : le plugin (traduction anglaise et allemande)
  • Téléchargez : la traduction française
  • Téléchargez : la traduction russe
  • Téléchargez : la traduction espagnole
  • Nécessite : WordPress 2.0 ou supérieure
  • Correction de bug : For PHP4 the cache instance wasn’t a reference, which was a bug but did not cause any known issues
  • Correction de bug : Now Javascript works with single quotes for translated text
  • Nouvelle fonctionnalité : Increased performance for AJAX call
  • Nouvelle fonctionnalité : Better localization support inside of the plugin and the readme
Version 4.6 (2008-04-06)
Version 4.5 (2008-03-24)
  • Téléchargez : le plugin (traduction anglaise et allemande)
  • Téléchargez : la traduction française
  • Téléchargez : la traduction russe
  • Téléchargez : la traduction espagnole
  • Nécessite : WordPress 2.0 ou supérieure
  • Correction de bug : Fixing WordPress 2.1.x compatibility
  • Correction de bug : WYSIWYG Conversion Warning now displays correctly for pages, too
  • Modification : Performance optimization during plugin initialization
  • Modification : Nonintrusive AJAX error display
  • Nouvelle fonctionnalité : le plugin interface support for WordPress 2.5
Version 4.4 (2008-01-29)
  • Téléchargez : le plugin (traduction anglaise et allemande)
  • Téléchargez : la traduction française
  • Téléchargez : la traduction russe
  • Nécessite : WordPress 2.0 ou supérieure
  • Correction de bug : Incompatibilites with WP-Shopping-Cart because of Javascript global variable clash
  • Modification : New directory structure
Version 4.3 (2007-12-11)
  • Téléchargez : le plugin (traduction anglaise et allemande)
  • Téléchargez : la traduction française
  • Téléchargez : la traduction russe
  • Nécessite : WordPress 2.0 ou supérieure
  • Correction de bug : Requirements lowered to WordPress 2.0 ou supérieure
  • Correction de bug : Delay loading of text translations to support language switching plugins
  • Nouvelle fonctionnalité : The WYSIWYG Conversion Warning can now be turned off through the Profile menu of the user
Version 4.2 (2007-11-03)
  • Téléchargez : le plugin (traduction anglaise et allemande)
  • Téléchargez : la traduction française
  • Nécessite : WordPress 2.2 ou supérieure
  • Modification : Remodeling the Information section of the plugin configuration menu
  • Nouvelle fonctionnalité : Showing security alarms in the Information section of the plugin configuration menu
  • Nouvelle fonctionnalité : A warning will be printed on the ‘Write’ and the ‘Widgets’ menu in case blog or user settings will screw up written PHP code during saving the article or widgets
Version 4.1 (2007-10-27)
  • Téléchargez : le plugin (traduction anglaise et allemande)
  • Téléchargez : la traduction française
  • Nécessite : WordPress 2.2 ou supérieure
  • Correction de bug : Display of the Exec-PHP configuration menu was restricted by an inappropriate capability
  • Correction de bug : Making Exec-PHP configuration menu valid XHTML
  • Nouvelle fonctionnalité : The Exec-PHP configuration menu now displays which user is allowed to write and execute PHP. Display of this list is executed with AJAX. Therefore even for large WordPress installations with many users, the time to load the Exec-PHP configuration menu will still be satisfiying
Version 4.0 (2007-10-25)
  • Téléchargez : le plugin
  • Nécessite : WordPress 2.0 ou supérieure
  • Correction de bug : When the blog administrator removes the ‘exec_php’ capability from all roles, the plugin will not reassign the capability to the Administrator and Editor roles
  • Modification : For new plugin installations only the Administrator role will be eligable to execute PHP code
  • Nouvelle fonctionnalité : Configurable execution of PHP code in text widgets through the Exec-PHP configuration menu. This will only work with native widgets support introduced in WordPress 2.2 ou supérieure
Version 3.4 (2007-10-08)
  • Téléchargez : le plugin
  • Nécessite : WordPress 2.0 ou supérieure
  • Nouvelle fonctionnalité : Now supports execution of code in text widgets
  • Nouvelle fonctionnalité : Now supports plugin upgrade notification through the ‘le plugins’ menu of WordPress by listing it in the official WordPress plugin repository
Version 3.3 (2007-08-11)
  • Téléchargez : le plugin
  • Correction de bug : Removing spaces around PHP code
  • Correction de bug : Removing obsolete plugin hooks for WordPress 1.x
Version 3.2 (2007-02-10)
  • Téléchargez : le plugin
  • Correction de bug : Removing obsolete config interface hooks
Version 3.1 (2007-02-09)
  • Téléchargez : le plugin
  • Correction de bug : Removing tag style converter because a) it caused a serious slow down in the WordPress admin interface and b) PCRE proved to be very buggy and unreliable. Note for myself: Never use PCRE again!
  • Nouvelle fonctionnalité : Adding internationalization (just to be complete)
  • Nouvelle fonctionnalité : Now works in RSS feeds
Version 3.0 (2006-08-06)
  • Téléchargez : le plugin
  • Nouvelle fonctionnalité : Removing all alternative PHP tag styles like [?php ?] and < ?php ?>, because regex was buggy and to tough to support
  • Nouvelle fonctionnalité : Removing support for WordPress 1.x, because regex was buggy and to tough to support
  • Nouvelle fonctionnalité : Moving plugin files to plugins subdirectory
  • Nouvelle fonctionnalité : Adding tag style converter
  • Nouvelle fonctionnalité : Adding support for excerpt field
  • Correction de bug : Because of changes to PHP tag handling, the bug reported in comment 84 is fixed
Version 2.0 (2005-12-22)
  • Téléchargez : le plugin
  • Nouvelle fonctionnalité : For WordPress 2.0 execution of PHP is now restricted to Administrators or Editors
  • Nouvelle fonctionnalité : Supporting alternative PHP tags [?php ?]
Version 1.2 (2005-12-04)
  • Téléchargez : le plugin
  • Correction de bug : Reparing issue with reopening PHP tags (Test #16)
Version 1.1 (2005-08-19)
  • Téléchargez : le plugin
  • Correction de bug : Escaped string delimiters in PHP strings are now parsed correctly
Version 1.0 (2005-08-18)
  • Téléchargez : le plugin
  • Nouvelle fonctionnalité : Allows <?php ?> tags inside your articles to execute the code inside of it

Développement

Pour le moment, il n’est pas prévu d’inclure de nouvelles fonctionnalités mais vous pouvez en proposer sur la page des commentaires.

Concernant le fonctionnement du plugin, je vous invite à poser vos questions sur le blog du développeur.


Ecrit par Lise - Site

Mot(s)-clé(s) ,

31 commentaires

Ecrire un commentaire»
  1. Merci pour ce superbe travail de traduction, sans aucun problème rencontré pour l’utilisation de ce plugin.

    Alain

  2. Sacré boulot ! Au début de mon utilisation WP, je n’arrivais pas à le faire fonctionner en widget et je m’étais rabattu sur Samsarin php widget qui a l’avantage de pouvoir nettoyer le contenu d’un widget si le code n’est plus valide (genre une fonction qui n’existe plus). Mais du coup, ça me donne envie de vérifier si php Exe ne fonctionne pas mieux depuis que j’ai changé d’hébergeur :-)

  3. Yerbouti

    Bonjour,
    Petite faute de traduction ?

    Paragraphe : Balises XHTML de WordPress

    [...] Une alternative pour désactiver cette option est d’installer le plugin Mime Type Plugin [...]
    Une alternative à la désactivation de cette option

  4. Sans doute, le « à » serait-il plus approprié.
    Je corrige…
    Merci de m’avoir signalé cette erreur.

  5. Mike

    Bonjour Lise,
    J’ai téléchargé et dézipper le fichier ; en résulte alors l’obtention de répertoires diverses (css, doc, include, images, includes, js, language) ainsi que les fichiers exec.php; readme, et screenshots.
    Dois je créer un répertoire dans « wp_content/pluggin » pour y transférer CES répertoires et fichiers ou uniquement transférer LE fichier exec.php tel quel dans le répertoire « wp_content/pluggin » ??

    Merci pour ton aide et surtout merci pour la traduction..

    1. Normalement, en décompressant le fichier zip, tu devrais avoir un dossier exec-php. Si celui-ci n’existe pas, il faut le créer et y mettre tous les fichiers et répertoires sauf les « screenshots » qui sont des copies d’écran. Il faut ensuite télécharger ce répertoire exec-php dans le répertoire wp-content/plugins.
      Dans le répertoire wp-content/plugins/exec-php/languages, il faut placer les fichiers de langue.

  6. Mike

    Merci Lise, ça a l’air de fontionner… J’aurais sûrement d’autres questions.
    A bientôt donc… ;)

  7. Pitou

    Bonjour Lise,
    J’ai bien activé le plugin, j’ai créé un article juste avec «  »
    et lorsque je demande l’affichage de l’article il ressort le même code et non pas juste « This is the Exec-PHP ‘Hello World  » comme si l’ensemble est pris pour du texte et non pas pour du code PHP.
    Merci de me dire si j’ai oublié un paramètre quelque part.
    Il me semble pourtant que j’ai bien suivi toutes les explications et j ne vois pas où ça ne va pas:
    1) Le plugin est activé,
    2) Les réglages sont faits
    3) WordPress doit automatiquement corriger les balises XHTML non valides est désactivé
    4) Disable WYSIWYG Conversion est inactif

    Merci de m’éclairer.

  8. Exec-php n’est pas compatible Wp 2.9.2 et il se peut qu’il ne fonctionne pas sur certaines installations (certains s’en sont plaint). Vous pouvez peut-être vous tourner vers d’autres plugins autorisant le php.

  9. Pitou

    Je crains qu’il ne s’agisse pas d’un problème de version de WordPress, j’ai la version avant la 9.2, car quel que soit le plugin que j’essaie (PHP Exec, PHP Execution, Exec-PHP ou encore WP Include File) tous considèrent le code PHP comme du texte dans la page Worpress et le code PHP n’est pas interprété.
    Avez-vous une idée de la raison qui provoque ce problème, est-ce un paramètre dans PHP de Wamp server?
    Exemple d’exécution:

    Previous Post Edit

    11 mai 2010
    TEST PHP EXEC

    Publie par Pitou

    Test de PHPEXEC

    <?php
    echo ‘Hello World!’;
    echo ‘FIN’;

    ?>

    FIN TEST PHPEXEC

    ou bien y a-t-il un problème avec les quotes, doubles quotes etc…..
    La même page fonctionne en Localhost sous wamp server mais pas dans la page générée de Worpress.
    Merci de me dire ce que vous en pensez.

    1. Il ne s’agit pas d’ un problème de version de WordPress puisque j’utilise la dernière et que dans le tableau ci-dessus le code est bien interprété. Même depuis mon iPhone je peux le visualiser ;-)
      Peut-être s’agit-il d’ une incompatibilité avec d’ autres plugins ou d’ une installation du serveur de votre hébergeur. Je pencherais plutôt pour cette raison si le plugin fonctionne sur votre installation en local.

    2. ou bien y a-t-il un problème avec les quotes, doubles quotes etc…..

      Je suppose que vous avez essayé avec des simples quotes, des doubles quotes ?
      et également uniquement avec une ligne, sans retour charriot ?

      1. Pitou

        J’ai essayé sur simple ou double ligne, avec double ou simple quote, rien n’y fait, c’est pareil.
        Ça ne vient pas de là.
        Je suis toujours en local avec Wamp Server.
        Quand j’exécute le PHP en localhost ça fonctionne, il y a donc une relation sous WordPress, à mon avis ça ne viendrait pas du serveur mais du fait que le code PHP (ou du moins les balises qui encadrent les instructions) ne sont pas reconnues et WP prend cela comme du texte.
        Comme je l’ai dit ceci est vrai pour tous les plugins.

  10. Pitou

    Dans tous les cas je suis en local, pas sur un hébergeur, donc je ne sais pas où se situe l’incompatibilité.
    Il n’ y a pas d’autres plugin activé, lorsque j lance par exemple EXEC PHP.

  11. Pour moi c’est un peu mystérieux. Je crois que sur le même hébergement j’ai un blog bourré de plugins où php-exec fonctionne bien et un second beaucoup plus léger où il n’a pas voulu tourner.

  12. Pitou

    Bonjour à tous,
    Meaculpa, mon paramétrage était incorrect, je n’avais pas désactivé le WISIWIG dans le User/Profile « Désactiver l’éditeur visuel pour écrire ».
    Maintenant ça fonctionne pour EXEC PHP, le code est bien interprété.
    J’ai essayé les autres PHP Plugin, il en est de même.

  13. Bonjour,
    Mon premier post ici alors : bravo pour ce site qui m’aide bien alors que je débute en wordpress!

    Ensuite, j’ai trouvé la solution de exec PHP vraiment pénalisante. D’une part l’installation ne se fait pas en un click (même si ceux qui ont l’usage de ce genre d’extension ne devraient pas souffrir de ce fait), mais surtout désactiver l’éditeur wysiwyg est vraiment « a pain in the @## »…

    J’ai donc cherché et trouvé une autre solution que j’ai décidé de partager ici: PHP Execution http://wordpress.org/extend/plugins/php-execution-plugin/

    Les avantages :
    - Cela s’installe en un click
    - Intégration parfaite de l’éditeur wysiwyg => en mode « visuel » le logo « php » s’affiche en lieu et place du code php!
    - Gestion de la sécurité prise en charge (avec vérification automatique qu’une personne n’ayant pas les droits d’exécuter du php ne puisse pas éditer un post d’une autre personne qui elle a les droits!)

    Inconvénients :
    - Pas oublier de vider son cache car du javascript est ajouté pour gérer l’éditeur wysiwyg et cela donne des frayeurs lorsqu’on ne l’a pas fait ;-) (code php remplacé par un code illisible)
    - J’espère qu’il n’y en n’a pas d’autre que je n’ai pas encore découvert ;-)

    1. Merci pour cette info.
      Pour ma part, je partage assez ce qu’écrit le développeur du plugin ExecPHP. A partir du moment où on commence à « mettre les mains dans le cambouis » avec du code PHP, l’utilisation de l’éditeur html au lieu du wysiwyg se conçoit. Je l’utilise quotidiennement ici, ce n’est pas si rébarbatif que ça ;-) l’éditeur html de WordPress offre une barre de menu, dont les boutons permettent de sélectionner gras, italique, insertion de liens, insertion d’images, puces, etc.
      Chacun sa solution ;-) mais l’exécution de code PHP constituant déjà une faille de sécurité si on ne le maîtrise pas bien, pourquoi ajouter du javascript, autre code, qui risque d’une part de ralentir le blog, d’autre part d’ouvrir une faille supplémentaire ?

      1. Tout dépend de l’utilisation que l’on en fait.
        Pour ma part ce n’est qu’occasionnellement que je veux pouvoir y mettre du PHP.
        Je souhaites pouvoir continuer à utiliser l’éditeur en permanence par facilité et ne pas devoir penser à le désactiver si je veux éditer du contenu avec du PHP.

        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.

  14. Je suis assez d’accord avec Lise surtout que le WYSWYG est inutilisable dès qu’on gère de nombreuses images :-)

    1. Pas encore eu le cas ;-)

  15. 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 ;-)

    1. Comme j’ai dit le code ne me fait pas peur, je suis programmeur… depuis 10 ans…

      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à… ;-)

  16. rarabou

    Bonjour,

    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 !!

    1. Je ne peux évidemment pas vous répondre pourquoi cela fonctionnait à un moment et pourquoi cela ne fonctionne plus maintenant !
      Avez-vous désactivé le mode WYSIWYG ?
      Peut-être y a-t-il incompatibilité avec d’autres plugins ? dans ce cas, essayez de désactiver tous les plugins, pour voir si EXEC-PHP fonctionne.
      Peut-être faut-il supprimer le plugin et le réinstaller ?

  17. Merci, ça fonctionne très bien.
    Par contre pour vérifier si ça fonctionnait, je passais de l’éditeur html au Visuel et je voyais le script disparaître. Après j’ai réinséré le script php dans l’éditeur html et mis directement « publier ». C’est passé.

  18. Il est bien précisé qu’il ne faut JAMAIS repasser en mode visuel pour utiliser ce plugin. D’autres plugins proposent des shortcodes pour gérer le php dans les billets.

  19. JN

    Merci Lise pour toutes ces infos…
    Par contre, personne n’aurait une alternative à exec PHP et PHP execution ? Parce qu’avec ma version WP 3.2, chez moi ça bug…
    Et le shortcode, ce n’est pas très pratique dès qu’on gère beaucoup de PHP…

    Merci !

  20. sme

    Bonjour,

    Merci pour cet article qui met en garde l’utilisation de ce plugin.

    Je l’ai récupéré pour mon blog et j’ai le message suivant quand je veux créer un nouvel article : « Exec-PHP WYSIWYG Conversion Warning. Saving this article will render all contained PHP code permanently unuseful. Even if you are saving this article through the Code editor. You can turn off this warning in your user profile. Ignore this warning in case this article does not contain PHP code. Read the Exec-PHP documentation if you are unsure what to do next. »

    Vous dites dans votre article : « L’avertissement du mode WYSIWYG peut être désactivé dans le menu ‘Profil de l’utilisateur’. Mais ceci n’est pas recommandé, car l’utilisation de l’éditeur visuel peut rendre le code PHP inutilisable de façon permanente. »

    Je n’ai pas très bien compris comment faire disparaitre ce message sachant que je souhaite utiliser du code PHP dans les articles seulement ponctuellement.

    Merci d’avance,

  21. Désolée pur la réponse tardive…

    Effectivement la phrase n’est pas très claire.
    Vous pouvez désactiver l’avertissement du mode WYSIWYG, mais si vous conservez ce mode, ce n’est pas conseillé car vous n’aurez aucun avertissement.
    Si vous souhaitez saisir du code PHP, par précaution, il faut désactiver le mode WYSIWYG (et pas seulement l’avertissement).
    J’espère avoir été plus claire ;-)

  22. Bonjour,

    J’apprécie le travail de traduction fourni de ta doc ! Je rencontre actuellement une collision du plugin exec-php avec Evermore, aurais-tu entendu parler de ça ?

Laisser un commentaire

Votre adresse mail ne sera jamais rendue publique ni utilisée.

*Si vous écrivez un commentaire ici pour la première fois, celui-ci ne sera publié qu'après validation par un administrateur du blog. Ne l'envoyez pas plusieurs fois !
*Bien sûr, tout commentaire injurieux, publicitaire ou spam sera supprimé.
*C'est à vous maintenant !

(obligatoire)
(obligatoire)

Laisser ces deux champs tels quels :

Protégé par Invisible Defender.


  • Mentions légales
    Les différents éléments du Blog de Lise restent la propriété de leur(s) auteur(s) respectifs.


Connexion à WordPress protégée par Clef