Tableau comparatif des méthodes d’inclusion de scripts PHP dans un article SPIP

GoUaRfIg ! , Michel Maillard, Jim WANDERSCHEID
<- ^ ->

Stephane Le Solliec
<- ^ ->

Créateurs de SPIP (...)
<- ^ ->

Sur SPIP Contrib pour l’article de fond ;
et sur le site de l’auteur pour le passage des paramètres.
<- ^ ->

Sur le site de l’auteur
<- ^ ->

Sur le site de SPIP
<- ^ ->

Implantation du passage de paramètres.
<- ^ ->

Implantation du passage de paramètres.
<- ^ ->

Aucune
<- ^ ->

• Mise au point de l’expression régulière.
• Prise en compte du caractère ’blanc’ introduit par SPIP version française précédant un point d’interrogation ’ ?’.
• Conversion de charset notamment pour les caractères ’ ?’ et ’&’.

<- ^ ->

• Mise au point de l’expression régulière.
• L’indispensabilité de la fonction my_include. En effet la fonction ’ob_start()’ ne supporte pas d’être dans une boucle. Je suppose que la fonction my_include créée et détruit l’objet ’buffer’ implicitement créé par ’ob_start()’ ce qui n’est pas le cas lorsqu’elle est placée dans la boucle principale du filtre ’recherche_php’.
• L’extrême difficulté de mesurer la longueur de la chaîne URL avec la fonction ’strlen’ notamment à cause de l’encodage des caractères des valeurs données aux paramètres passés (voir les ’posts’ du lien pour s’en convaincre). J’ai contourné le problème en récupérant la position (’strpos’) du caractère ’>’ de fin d’URL.
  <- ^ ->

• Synthèse difficile de la documentation officielle.
  <- ^ ->

Filtre appliqué à des balises.
En l’occurence la balise #TEXTE.
<- ^ ->

Filtre appliqué à des balises.
En l’occurence la balise #TEXTE.
<- ^ ->

Modèles avec la balise #ENV pour le passage des paramètres par variable d’environnement.
<- ^ ->

<php_cache_ma_fonction>
<- ^ ->

<ma_fonctionNNN>
NNN représente un nombre ici obligatoire.
<- ^ ->

<- ^ ->

<php_cache_ma_fonction|par1=XXX|par2=YYY>
par1 et par2 sont 2 paramètres passés à la fonction.
XXX et YYY sont respectivement les valeurs données à ces paramètres .
| et = sont nécessaires à la syntaxe.
<- ^ ->

<ma_fonctionNNN|par1=XXX|par2=YYY>
NNN représente un nombre ici facultatif.
par1 et par2 sont 2 paramètres passés à la fonction.
XXX et YYY sont respectivement les valeurs données à ces paramètres .
| et = sont nécessaires à la syntaxe.
<- ^ ->

• L’appel au niveau de la zone de saisie de l’article :

• L’aperçu dans l’espace privé (notez l’espace introduit par SPIP avant le point d’intérrogation ’ ?’. Il s’agit en principe d’une particularité de la langue française. Qu’en est-il pour les autres langues avec SPIP ?) une fois enregistrée la saisie :

• La source PHP de « bonjour.php » (notez que les fonctions de la librairie mbstring ne sont là que pour retranscrire les accents) montre l’utilisation des paramètres Param1 et Param2 passés au sein de la fonction via une URL et utilisés dans le script en faisant précéder ces noms de paramètres par le signe dollar ’$’ typique des variables PHP
  (ici $Param1 et $Param2 ) :

• Enfin le rendu :

<- ^ ->

• L’appel au niveau de la zone de saisie de l’article :

• L’aperçu dans l’espace privé est inexistant.

• La source PHP de « bonjour.php » (identique à la méthode précédente, localisé dans le même répertoire) montre l’utilisation des paramètres Param1 et Param2 passés au sein de la fonction comme pour un modèle SPIP (voir méthode suivante) et utilisés dans le script en faisant précéder ces noms de paramètres par le signe dollar ’$’ typique des variables PHP (ici $Param1 et $Param2) :

• Enfin le rendu :

<- ^ ->

• L’appel au niveau de la zone de saisie de l’article :

• L’aperçu dans l’espace privé montre déjà le résultat tel qu’il sera dans l’espace public :

• La source de « bonjour.html » (notez que les fonctions de la librairie mbstring ne sont plus nécessaires) montre l’utilisation des paramètres Param1 et Param2 passés au sein de la fonction en séparant les couples (variable = valeur) par des barres verticales de séparation | et utilisés dans le script en enveloppant ces noms de paramètres par une balise SPIP "#ENV{ }"
  (ici "#ENV{Param1}" et "#ENV{Param2}" ) :

• Enfin le rendu :

<- ^ ->

Précisé par la variable $dossier_inclus du filtre autoriser_php, il suffit d’indiquer le nom et le chemin du répertoire que vous aurez créé préalablement. En ce qui me concerne :

Il suffit d’uploader ensuite le script PHP à cet endroi.
<- ^ ->

Précisé par la variable $ScriptDir du filtre recherche_php, il suffit d’indiquer le nom et le chemin du répertoire que vous aurez créé préalablement. En ce qui me concerne :

J’ai délibérémment pris le même répertoire que pour la première méthode afin d’utiliser indifféremment la première ou la seconde méthode.
<- ^ ->

Le répertoire /modeles/ doit être créé à l’intérieur du répertoire ./squelettes/ s’il n’existe pas déjà. (Il faudrait étudier les variables intrinsèques de SPIP pour éventuellement changer la localisation des scripts).
Ces scripts PHP sont ’enveloppés’ dans un fichier HTML.
<- ^ ->

<- ^ ->

<- ^ ->

Le contenu peut être du pur PHP à l’exception des variables passées en paramètre.
<- ^ ->

• Le fichier mes_fonctions.php du répertoire ./squelettes/ est à modifier (ou à crééer de toutes pièces s’il n’existe pas). On y rajoute la fonction du filtre autoriser_php.

• Le fichier du squelette article.html est à copier de la distribution dans le répertoire ./squelettes/ s’il n’existe pas déjà avant de le modifier pour y appliquer le nouveau filtre à la balise #TEXTE.
  <- ^ ->

• Le fichier mes_fonctions.php du répertoire ./squelettes/ est à modifier (ou à crééer de toutes pièces s’il n’existe pas). On y rajoute la fonction du filtre recherche_php ainsi que la fonction my_include.

• Le fichier du squelette article.html est à copier de la distribution dans le répertoire ./squelettes/ s’il n’existe pas déjà avant de le modifier pour y appliquer le nouveau filtre à la balise #TEXTE.

<- ^ ->

Pas de modification de fichier de la distribution de SPIP.

Seul le script PHP est à déposer dans ./squelette/modeles/ en renommant l’extension du fichier de script PHP en HTML et en enveloppant les variables passées en paramètre par "#ENV{ }".
<- ^ ->

L’image ci-dessous correspond à une copie de l’espace privé de cet article.
Comme on peut le constater sur la copie d’écran ci-dessous on ne voit que l’appel dans l’espace privé. Et dans l’espace public l’heure est bien rendue.

Un examen de la source HTML de l’espace privé donne :

<- ^ ->

L’image ci-dessous correspond à une copie de l’espace privé de cet article.
Comme on peut le constater sur la copie d’écran ci-dessous on ne voit rien dans l’espace privé. Par contre dans l’espace public les graphes sont bien rendus.

Un examen de la source HTML de l’espace privé donne :

<- ^ ->

L’image ci-dessous correspond à une copie de l’espace privé de cet article.
Comme on peut le constater sur la copie d’écran ci-dessous on aperçoit bien l’heure dans l’espace privé de même que dans l’espace public. Seul diffère la police de caractères.

Un examen de la source HTML de l’espace privé donne :

Notez qu’il s’est écoulé 4mn entre la copie d’écran et la génération de la source HTML de la page privée !
<- ^ ->

Le squelette de la page privée doit être différent de celui de la page publique. Il n’a probablement pas reconnu le filtre appliqué : « autoriser_php » puisque l’on retrouve en clair « #INCLURE(heure.php) » dans cette page privée.
<- ^ ->

Le squelette de la page privée doit - là aussi - être différent de celui de la page publique. Il n’a probablement pas reconnu le filtre appliqué : « recherche_php » puisque l’on retrouve en clair « <php_cache_example0> » et un peu plus loin « <php_cache_example33> » dans cette page privée.
De plus lors du rendu de cette page privée, du fait de la présence des symboles : « < » et « > » ouvrant et fermant normalement une balise, le contenu situé entre ces symboles n’a pas été reconnu comme une balise standard HTML. Si bien qu’il a été ignoré et rien n’est affiché.

<- ^ ->

Un modèle SPIP est par définition un mini squelette, il a donc été inclu dans le squelette de la page privée (pas besoin de reconnaissance), il a donc rendu tout naturellement un résultat au script PHP contenu dans ce modèle.

<- ^ ->

Voir le paragraphe consacré sur le site du contributeur.
<- ^ ->

Voir le paragraphe consacré sur le site du contributeur.
<- ^ ->

ATTENTION  contrairement aux 2 autres méthodes il faut s’assurer que votre répertoire /modeles/ soit protégé par un fichier .htaccess.
Ce contenu suffit :

sauf si le code doit écrire des fichiers sur le serveur web !
quant au fichier .htaccess je l’ai mis dans le répertoire /modeles/

En effet si on essaye d’accéder au script directement en pointant son adresse http avec votre navigateur on peut récupérer la source de ce script dans la source de la page html rendue !
Du style :

Très génant si votre script contient un mot de passe pour se connecter à votre base de données par exemple !

Le fait que le script soit enveloppé dans un fichier html, si ce script génère une erreur (il attend par exemple des paramètres non passés) la page pointée est quand même rendue avec du PHP en clair dans la source !
Avec les 2 premières méthodes, je n’ai pas observé ce problème.

<- ^ ->

1.9.2d et 1.9.2h
<- ^ ->

1.9.2d et 1.9.2h
<- ^ ->

1.9.2d et 1.9.2h
<- ^ ->

• Génération d’un SiteMap Google

<- ^ ->

• Inclusion de fichier HTML sans iframe dans un article SPIP

<- ^ ->

• Affichage de courbes JpGraph

<- ^ ->