(#VALEUR\|unique)
[(#VALEUR\|sinon{' '})]

SPIP - Documentation technique : construction des pages

Teddy Payet — 2013-12-02T11:06:17Z

Nous avons vu dans le précédent article la nomenclature pour constituer notre documentation technique. Dans le présent article, nous allons voir comment améliorer un peu les choses.

Rappel

Nous avons construis une page ?exec=vins_doc qui affichera sous forme de tableau notre documentation. La page peut être longue, très longue.
Les chaînes de langue étant construites (n'est ce pas ?), nous allons améliorer un peu l'affichage.

Amélioration

Il serait intéressant de mettre une table des matières sur cette page.

Pour cela, nous allons utiliser le zoning que nous offre les squelettes du back office de SPIP 3. Pour notre page ?exec=vins_doc, nous avons créé prive/squelettes/contenu/vins_doc.html ce qui sous-entend que nous nous sommes occupé de la zone de contenu de notre page. La structure du BO de SPIP fournit une zone d'extra et une autre de navigation.
La table des matières est un "extra" alors créons le fichier adéquate : prive/squelettes/extra/vins_doc.html
On reste sur le nom "vins_doc.html" selon la règle de SPIP.
Voici le code à y insérer :

#SET{tables, #LISTE{'vin','vins_producteur'}}  [(#BOITE_OUVRIR{<:vins:sommaire:>})]  #SET{spip_table,#VAL{'spip_'}|concat{#VALEUR,'s'}}    [(#_tables:GET{spip_table}|replace{'spip_',''}|ucfirst)]    #CLE
  
  
 
    [(#BOITE_FERMER)]

Bien, une liste est construite mais elle ne servira à rien si nous ne nous occupons pas des identifiants du contenu.

Allons dans prive/squelettes/contenu/vins_doc.html
Recherchons et remplaçons le par
Nous aurons ainsi quelques choses comme
Ça, c'est cool. Mais il faut aussi faire la même chose pour le nom de la table.
Recherchons et remplaçons le par

Voilà ! C'est nettement mieux.

Et une version texte ?

Cette page en tableau est très pratique à la lecture mais on peut avoir le besoin de créer un fichier word avec du texte au kilomètre.
Nous avons la structure de code qu'il faut pour cela. On ne va pas réinventer la roue. Il suffit de renommer la structure html.

Nous n'allons pas perdre le code que nous avons déjà réalisé. Transformons-le en inclure et affichons conditionnellement le type d'affichage désiré.

Coupons-collons le code suivant de notre page contenu/vins_doc.html dans prive/squelettes/inclure/vins_doc_tableau.html

  #SET{spip_table,#VAL{'spip_'}|concat{#VALEUR,'s'}}      #_tables:GET{spip_table}  [(#VAL{#GET{prefixe}}|concat{':nom_du_champ'}|_T)]  [(#VAL{#GET{prefixe}}|concat{':definition_mysql'}|_T)]  [(#VAL{#GET{prefixe}}|concat{':label_label'}|_T)]  [(#VAL{#GET{prefixe}}|concat{':documentation'}|_T)]  
  #CLE  #VALEUR  [(#VAL{#_tables:VALEUR}|concat{':label_',#CLE}|_T)]  [[(#VAL{#GET{prefixe}}|concat{':aide_a_la_saisie'}|_T)]
 (#VAL{#_tables:VALEUR}|concat{':label_',#CLE,'_explication'}|_T)
] [[(#VAL{#GET{prefixe}}|concat{':documentation'}|_T)]
 (#VAL{#_tables:VALEUR}|concat{':label_',#CLE,'_documentation''}|_T)]

#_tables:GET{spip_table}
[(#VAL{#GET{prefixe}}\|concat{':nom_du_champ'}\|_T)]	[(#VAL{#GET{prefixe}}\|concat{':definition_mysql'}\|_T)]	[(#VAL{#GET{prefixe}}\|concat{':label_label'}\|_T)]	[(#VAL{#GET{prefixe}}\|concat{':documentation'}\|_T)]
#CLE	#VALEUR	[(#VAL{#_tables:VALEUR}\|concat{':label_',#CLE}\|_T)]	[[(#VAL{#GET{prefixe}}\|concat{':aide_a_la_saisie'}\|_T)] (#VAL{#_tables:VALEUR}\|concat{':label_',#CLE,'_explication'}\|_T) ] [[(#VAL{#GET{prefixe}}\|concat{':documentation'}\|_T)] (#VAL{#_tables:VALEUR}\|concat{':label_',#CLE,'_documentation''}\|_T)]

Transformons les #GET{prefixe} en #ENV{prefixe} et le #GET{tables} en #ENV{tables}
Dans contenu/vins_doc.html, faisons l'appel à l'inclure vins_doc_tableau.html :

Simple, non ?

Nous avions parlé d'un texte au kilomètre, alors créons sur le même modèle le fichier inclure/vins_doc_texte.html en dupliquant inclure/vins_doc_tableau.html et apportons-y quelques modifications.

Remplaçons

par

Remplaçons

Supprimons les maintenant.
Le ... qui ne sont plus nécessaires.
Normalement, nous ne rencontrons pas de difficultés particulières ici. Ce n'est que du code html. Notre inclure est prêt.

Revenons sur la page contenu/vins_doc.html pour y apporter quelques améliorations. Nous pourrions ajouter un autre inclure pour notre texte pour l'avoir sur la même page. Mais avoir la même information en doublon ne sert à rien. Alors nous allons faire un petit formulaire qui indiquera quel type d'affichage prendre en compte.
Voici le code :

	
 [(#SELF|parametre_url{affichage,''}|form_hidden)]  <:vins:affichage:>

A partir de là, nous modifions l'inclure dans contenu/vins_doc.html :

Avec ce code, SPIP ira chercher l'inclure « tableau » si nous n'avons pas dans l'url le paramètre affichage.

Et voilà, on peut changer l'affichage de notre documentation en 2 coups de cuillère à pot.

Conclusion

Avec cette méthode, il est simple de faire une documentation. Cela ne nous dispense pas de son écriture bien entendu. Mais cela permet d'avoir la documentation directement dans le plugin. Ces différents squelettes et chaînes de langue ne sont que du texte, ce qui ne va pas alourdir à outrance le poids des fichiers du plugin.
On peut même étoffer la documentation annexe avec des inclure pour des éléments qui ne sont pas issus des tables en elles-mêmes mais de fonctions, d'interface, etc.
Je n'ai plus qu'une dernière à vous dire : Bonne documentation ! :-P

Vous pouvez lire aussi :
– SPIP - Documentation technique : nomenclature
– SPIP - Documentation technique : construction des pages
– SPIP - Documentation technique : mise en conformité

SPIP - Documentation technique : nomenclature

Teddy Payet — 2013-12-02T07:02:42Z

Lorsque nous avons l'utilité d'un nouvel objet (éditorial) dans SPIP, il est plus simple et même conseillé de passer par la création d'un plugin.
A force de créer des plugins, je me suis créé une nomenclature d'écriture des fichiers. En fait, je n'ai rien inventé de particulier. La base des fichiers est créée par le plugin "La Fabrique" (merci marcimat !).

Préambule

Malgré un titre "racoleur", cet article ne va pas traiter de la nomenclature d'écriture des fichiers de SPIP mais d'une nomenclature que j'ai mis en place personnellement.
Si vous désirez avoir des informations particulières sur la nomenclature de SPIP (ses API, etc.), je vous conseille quelques sites :
– Programmer avec SPIP ;
– Documentation du code de SPIP ;
– Autodoc de SPIP : une zone particulière de code.spip.net. Il est autoalimenté par le PHPDoc inséré dans le code source de SPIP.
– SPIP-Contrib ;
– L'annuaire des plugins de SPIP.

De plus, je ne traitera pas non plus de l'utilisation du plugin La Fabrique. Sa page de documentation est très complète.

Contexte

Pour l'expression de cette nomenclature, je prendrai pour ligne de conduite la création d'un objet "vins". Cela sera plus parlant. Je me réfèrerai, sauf mention contraire, toujours à cet objet éditorial.
Le but de cet article n'est pas la création d'un plugin mais la méthodologie pour une bonne nomination des fichiers et des chaines de langue associées.
De ce fait, nous partons de zéro pour arriver à la fin de ce cycle à la réalisation de l'affichage de la documentation technique.

Vif du sujet

La Fabrique crée les bons fichiers selon les API de SPIP. Au départ c'est un "clicodrome". Mais il ne nous dispense strictement pas de penser, au préalable, notre structure de données. On ne fonce pas tête baissée dans un projet.

Dans le formulaire "Ajouter un objet éditorial", nous pouvons rajouter tous les champs nécessaires :

nom
millésime
id_producteur
id_couleur
id_appellation
id_region
etc.

Une des premières choses à laquelle je fais attention autant que possible est le respect de "id_objet". La Fabrique créera la table spip_vins (au pluriel) associé à mon objet "vin". De là, il crée un ID : id_vin (mon équivalent à "id_objet" cité en début de paragraphe.)
Surtout, ne modifions pas cela même si la Fabrique nous le permet. Vous comprendrez pourquoi un peu plus loin.

Ici, ce n'est pas tellement le nom et/ou le nombre de champs qui m'intéresse dans "ma" nomenclature. Le but de cette dernière est de générer semi-automatiquement une information technique sur la table et ses champs grâce aux fichiers de langue.

La Fabrique adopte donc la philosophie des API de SPIP. Lorsque nous respectons "id_vin" pour l'objet "vin", la Fabrique créera les fichiers :
– lang/vin_fr.php : toutes les langues liées à l'objet "vin" ;
– lang/vins_fr.php : toutes les chaînes liées au plugin ayant le préfixe "vins" ;
– lang/paquet-vins_fr.php : les chaînes de langues généralement utilisées dans paquet.xml.

Si nous n'avions pas utilisé "id_vin" mais par exemple "ref_vin", la Fabrique aurait créé le fichier lang/ref_vin_fr.php… ce qui ne nous aurait pas arrangé pour la suite. J'ai rencontré ce cas récemment.

Un objet, deux objets, etc.

Pour aller un peu plus loin, nous allons créer une table pour les producteurs de vins. Nous nommerons cette table spip_vins_producteurs, l'objet associé sera "vins_producteur". Laissez-le tel quel.
Lorsque nous serons dans l'espace privé de SPIP sur la fiche d'un producteur, nous aurons une URL de type ?exec=vins_producteur&id_vins_producteur=XX

Remarque

J'aurai pu créer la table spip_producteurs. Mais le soucis est que ce nom est trop générique et pourrait se télescoper avec une autre table qui n'a rien à voir avec notre plugin.

Vous aurez compris que l'ID du producteur est sous la forme "id_vins_producteur". La Fabrique a enlevé le "s" final à producteur.

Normalement, vous m'avez suivi sans trop de soucis jusqu'à maintenant sans pour autant savoir où je voulais en venir. Pas vrai ? ;-)
Alors, continuons :

Pour la chaîne de langue de l'objet "vins_producteur", la Fabrique va créer lang/vins_producteur_fr.php.
Ça ne vous rappelle rien ? Je vous aide un peu : lang/vin_fr.php… lang/objet_fr.php

C'est la règle d'écriture adoptée par la Fabrique.

Rappel

Dans mes précédents articles, je vous avez montré (grâce à b_b, denisb et kent1) comment reconstruire une chaîne de langue pour l'afficher sur notre page :
[(#VAL{#GET{prefixe}}|concat{':nom_du_champ'}|_T)]

On ne change pas une équipe qui gagne.

Créer les chaînes de langue

Nous allons utiliser cette même règle pour construire notre documentation technique. Une sorte de PHPdoc "linguistique" à la SPIP.

Remarque

Mon but dans cette nomenclature n'est pas de documenter des fonctions (au sens PHP) car il existe des méthodes robustes aujourd'hui. SPIP a adopté, sous l'impulsion de Marcimat, PHPDoc pour cette documentation.

Dans ma documentation technique, en fait, je désire afficher 4 choses dans un tableau :

le nom du champ ;
son label ;
sa définition MySQL ;
son aide à la saisie (explication) ;
et sa documentation.

Pour cela, on va prendre l'habitude d'écrire nos chaînes de langue sous la forme :

label_champ
label_champ_explication
label_champ_documentation
La définition MySQL du champ est directement issu des variables globales de SPIP ce qui rend inutile de créer une chaîne de langue pour elle. Nous aurons alors 3 chaînes de langue par champ.

Donc, soit pour notre objet vin, nous aurons :

label_id_vin
label_id_vin_documentation
label_id_vin_explication
label_nom
label_nom_documentation
label_nom_explication
label_millesime
label_millesime_documentation
label_millesime_explication
etc.

Dans les fichiers de langues adéquates, nous devons y renseigner ce dont nous avons besoin.

Afficher le contenu sur la page de documentation

Bon, tout est prêt maintenant pour construire notre page, y compris le contenu. Nous devons maintenant créer un fichier "prive/squelettes/contenu/vins_doc.html". Voici le code à y insérer :

[(#SET{prefixe,'vins'})]
<h1>[(#VAL{#GET{prefixe}}|concat{':documentation_technique'}|_T)]</h1>
#SET{tables, #LISTE{'vin','vins_producteur'}} <B_tables>
<BOUCLE_tables(DATA) {source table, #GET{tables}} {si #SESSION{webmestre}|=={oui}}>
#SET{spip_table,#VAL{'spip_'}|concat{#VALEUR,'s'}}
<B_info_table>
<table>
<BOUCLE_info_table(DATA) {source table, #EVAL{$GLOBALS['tables_principales'][#GET{spip_table}]}}{cle==field}> <caption>#_tables:GET{spip_table}</caption>
<thead> <th>[(#VAL{#GET{prefixe}}|concat{':nom_du_champ'}|_T)]</th> <th>[(#VAL{#GET{prefixe}}|concat{':definition_mysql'}|_T)]</th> <th>[(#VAL{#GET{prefixe}}|concat{':label_label'}|_T)]</th> <th>[(#VAL{#GET{prefixe}}|concat{':documentation'}|_T)]</th>
</thead>
<B_label>
<BOUCLE_label(DATA) {source table, #VALEUR}>
<tr>
<td><strong>#CLE</strong></td>
<td><em>#VALEUR</em></td>
<td>[(#VAL{#_tables:VALEUR}|concat{':label_',#CLE}|_T)]</td>
<td>[<strong>[(#VAL{#GET{prefixe}}|concat{':aide_a_la_saisie'}|_T)]</strong><br/>
(#VAL{#_tables:VALEUR}|concat{':label_',#CLE,'_explication'}|_T)<br/>]
[<strong>[(#VAL{#GET{prefixe}}|concat{':documentation'}|_T)]</strong><br/>
(#VAL{#_tables:VALEUR}|concat{':label_',#CLE,'_documentation''}|_T)]</td>
</tr>
</BOUCLE_label>
</B_label>
</BOUCLE_info_table>
</table>
</B_info_table>
</BOUCLE_tables>
</B_tables>

Ce code va construire le tableau comme prévu.
Sur cette page, on peut voir que parfois la chaîne de langue ne s'affiche pas. En tout cas, pas son contenu mais bel et bien la chaîne en elle même sans les underscores. Exemple : label id vin, label id vin documentation, label id vin explication.
La raison en est très simple : nous n'avons pas encore renseigné cette chaîne de langue.
Mais parfois, nous n'avons rien à dire de particulier sur un champ. Il parle de lui même. Alors l'astuce est de créer tout de même cette chaîne de langue dans le bon fichier et de mettre un espace blanc/vide, soit 'label_id_vin_documentation' => ' '.

Astuce

Pour ceux qui ont lu le code ci dessus, vous avez pu voir un [(#SET{prefixe,'vins'})]. En fait, ceci est pour nous simplifier la tâche si on désire mettre ce bout de code dans un autre plugin. Il nous suffira de mettre le préfixe de notre nouveau plugin ici pour que la chaîne de langue se construise.

Remarque

Denisb nous a rappelé l'existence depuis SPIP 3.0.13 d'une nouvelle écriture de construction d'une chaîne de langue. Vous pouvez voir son commentaire ici et ici.

La page étant construite, il nous faut maintenant compléter nos différentes chaînes de langue. Alors à vos claviers et rendez-vous dans mon prochain article.

Vous pouvez lire aussi :
– SPIP - Documentation technique : nomenclature
– SPIP - Documentation technique : construction des pages
– SPIP - Documentation technique : mise en conformité

Afficher les champs d'un objet #SPIP v2

Teddy Payet — 2013-11-26T08:00:00Z

Dans la même trempe que Afficher les champs d'un objet #SPIP, je vais prendre le même principe mais l'étendre en affichant une chaîne de langue… Tout un programme.
J'ai réussi cette performance grâce au code que m'a donné kent1. Merci à lui pour ce code.

L'utilité de cette boucle est de lister les différents champs d'un objet sur sa page de vue. Exemple : ?exec=projet_site&id_site=XX

L'espace privé de SPIP 3 étant géré par des squelettes, il suffit de créer un fichier /prive/squelettes/extra/projet_site.html avec le code suivant :

[(#BOITE_OUVRIR{[(#VAL{#ENV{exec}}|concat{':label_',#ENV{exec},'_champs'}|_T)],'info','titrem'})]
[(#ENV{singulier}|=={oui}|non)
[(#SET{valeurs,#VAL{#ENV{exec}}|concat{'s'}|description_table|table_valeur{field}|array_keys|print})]
][(#ENV{singulier}|=={oui}|oui)
[(#SET{valeurs,#VAL{#ENV{exec}}|description_table|table_valeur{field}|array_keys|print})]
]
[(#SET{tableau,#GET{valeurs}|explode{', '}})]



#VALEUR : [
(#VAL{#ENV{exec}}|concat{':label_',#VALEUR}|_T)]



[(#BOITE_FERMER)]

Structure à respecter

En premier lieu, il faut avoir le fichier de langue nommer sous cette forme : lang/projet_site_fr.php. Puis chaque champ doit avoir son label : label_champ, soit label_id_site, label_logiciel_nom, label_logiciel_version, etc.
Après cela, tout roule !

L'astuce magique de kent1

Je vous avais dit que kent1 m'avait communiqué un code qui permettait de reconstruire une chaîne de langue. Voici ce bout de code :
[(#VAL{#ENV{exec}}|concat{':label_',#VALEUR}|_T)]
L'application du filtre |_T permet de transformer notre variable en chaîne de langue. Magique !

Afficher les globals tout en boucle SPIP

Teddy Payet — 2013-11-15T17:11:41Z

Lorsqu'on fait un développement PHP, on a besoin parfois de savoir ce qu'on a dans nos $GLOBALS. Il en va de même lorsqu'on est en développement avec SPIP. Voici un bout de code qui peut dépanner.

Préambule

Il existe des solutions plus poussées comme les logiciels IDE qui permettent de voir les fonctions appellées dans la page. Malheureusement, on n'a pas toujours la possibilité de coder avec ces logiciels dans l'infrastructure où nous sommes.
Dans SPIP, on peut même utiliser le plugin Test Builder pour créer... nos tests. C'est super pratique quand on a pris le coup de main.

Mais voilà... Ca, c'est dans le meilleur des mondes. Parfois, tout cela n'est pas possible ou on a juste besoin d'une information sans avoir à utiliser un couteau Suisse(c) là où un cure-dent suffirait.

Le code

Pour faire illustrer notre exemple, on va créer dans notre répertoire squelettes l'arborescence suivante :

squelettes/
- prive/
  - squelettes/
    - contenu/
      - globals.html

Le fichier globals.html contiendra, soyons originaux, l'affichage de nos globals. Tout se fera par cette page.

Pour l'appeller, aller à l'adresse ecrire/?exec=globals. Comme le fichier est vide, vous devriez peut-être avoir une erreur ou au mieux une page "blanche".

Voici le code à insérer dans la page globals.html :

 
  #SET{global,$GLOBALS[#ENV{index}]}  #SET{global,$GLOBALS}    Index des $GLOBALS
 
 [(#SELF|parametre_url{'index',''}|parametre_url{'affichage',''}|form_hidden)]     
  [(#SET{nom_index,#VAL{"'"}|concat{#ENV{index},"'"}})] #SET{datatype,$GLOBALS[#GET{nom_index}]} [(#ENV{index}|non) $GLOBALS [ 
(#EVAL{$GLOBALS}|gettype)] 
 ] [(#ENV{index}|oui) [(#GET{datatype}) [ 
(#EVAL{#GET{datatype}}|gettype)] 
] ] [(#ENV{affichage}|=={var_dump}|oui) [(#EVAL{#GET{global}}|print|sinon{'vide'})
] ] [(#ENV{affichage}|=={cles}|oui) [(#EVAL{#GET{global}}|array_keys|foreach|sinon{'vide'})
] ] [(#ENV{affichage}|non) [(#EVAL{#GET{global}}|array_keys|foreach|sinon{'vide'})
] ]

Explications

La boucle "index"
Elle va tout simplement regarder si on a passé un paramètre index dans notre URL. Si oui, on affichera le contenu de $GLOBALS[#ENV{index}]. Sinon, on prend $GLOBALS.

La boucle "form"
Elle va créer un formulaire avec 2 champs select. Le premier select listera tous les "index" de notre super variable PHP $GLOBALS.
Le deuxième select se charge d'indiquer quel type d'affichage désire-t-on avoir pour notre variable :
– var_dump : pour les utilisateurs PHP, cela parle de source : "affiche les informations structurées d'une variable, y compris son type et sa valeur." Sauf que dans notre cas, on n'a pas le type :-P
– cles : affiche le tableau associatif des clés de notre variable.

Les ENV
Les #ENV après notre boucle "form" vérifie la présence du paramètre "affichage" dans notre url. Selon sa valeur, on affichera d'une certaine façon le contenu de notre variable.

Le javascript
Le javascript en fin de page va juste changer la sélection du deuxième select selon le type de variable qu'on aura. Si notre variable est de type array, le select affichage sera "cles". Tous les autres types (Object, string, etc.) auront un affichage "var_dump".

Fini...

Ce code vous permet donc depuis l'espace privé d'avoir les globals. Mais il vous suffit de faire une page accessible sur la partie publique de votre site avec exactement le même code pour avoir les globals dans cet environnement.

Encore une fois, ce n'est qu'une astuce parmis d'autres. Si vous en avez aussi, elles sont les bienvenues en commentaires !
Cela permettra d'avoir d'autres pratiques de développeurs SPIP/PHP.

Une boucle DATA pour avoir les dernières versions de SPIP

Teddy Payet — 2013-09-24T15:00:00Z

Avec SPIP 3, nous avons nativement la boucle DATA issue du plugin Itérateur réalisé par Fil. Cette boucle nous permet de parser presque tout ce que l'on veut ! C'est purement magique !

Un xml

Voici un exemple d'utilisation de la boucle DATA à partir d'un xml obtenu de la page http://files.spip.org/spip/archives/

    [(#VALEUR{0})]

Explications

– l'url spécifiée est fournis par la console de YQL : http://developer.yahoo.com/yql/cons... (Cliquez sur "Test" pour voir le rendu)
Le résultat de cette première boucle DATA est un tableau qui contient uniquement les liens vers les archives de SPIP. Il nous suffit de le passer en critère à une seconde boucle DATA.
– grâce au critère {cle==a}, on récupère uniquement les clés contenant 'a' (équivalent à la balise html ).
– #VALEUR{href} : récupération de l'attribut href de la balise .
– #VALEUR{0} : récupération du contenu de la balise .

Et voilà. Nous avons sur la page toutes nos versions officielles de SPIP.

J'étofferai un peu plus tard cet article avec une boucle DATA avec une source YQL.

par un
en gardant le id.
Le premier
devient un et nous lui appliquons aussi le id issu de
de la définition mysql devient un Le	de l'aide de saisie et de la documentation devient un . Devant `#CLE` de la boucle `info_table`, mettons `[(#VAL{#ENV{prefixe}}\|concat{':nom_du_champ'}\|_T) : ]`. Devant `#VALEUR` de la boucle `info_table`, mettons `[(#VAL{#ENV{prefixe}}\|concat{':definition_mysql'}\|_T) : ]`. Tout cela fait, on peut supprimer les lignes

Teddy Payet

SPIP - Lister toutes les tables et leurs entrées

Liste des tables et leurs valeurs

(#GRAND_TOTAL) enregistrement(s) pour #ENV{table}

Explications

Encore plus beau

SPIP - Documentation technique : construction des pages

Rappel

Amélioration

Et une version texte ?

Conclusion

SPIP - Documentation technique : nomenclature

Préambule

Contexte

Vif du sujet

Un objet, deux objets, etc.

Remarque

Rappel

Créer les chaînes de langue

Remarque

Afficher le contenu sur la page de documentation

Astuce

Remarque

Afficher les champs d'un objet #SPIP v2

Structure à respecter

L'astuce magique de kent1

Afficher les globals tout en boucle SPIP

Préambule

Le code

Index des $GLOBALS

$GLOBALS [
(#EVAL{$GLOBALS}|gettype)]

(#GET{datatype}) [
(#EVAL{#GET{datatype}}|gettype)]

Explications

Fini...

Une boucle DATA pour avoir les dernières versions de SPIP

Un xml

Explications

en gardant le id.
Le premier

et nous lui appliquons aussi le id issu de

Teddy Payet

SPIP - Lister toutes les tables et leurs entrées

Liste des tables et leurs valeurs

(#GRAND_TOTAL) enregistrement(s) pour #ENV{table}

Explications

Encore plus beau

SPIP - Documentation technique : construction des pages

Rappel

Amélioration

Et une version texte ?

en gardant le id. Le premier

et nous lui appliquons aussi le id issu de

Conclusion

SPIP - Documentation technique : nomenclature

Préambule

Contexte

Vif du sujet

Un objet, deux objets, etc.

Remarque

Rappel

Créer les chaînes de langue

Remarque

Afficher le contenu sur la page de documentation

Astuce

Remarque

Afficher les champs d'un objet #SPIP v2

Structure à respecter

L'astuce magique de kent1

Afficher les globals tout en boucle SPIP

Préambule

Le code

Index des $GLOBALS

$GLOBALS [ (#EVAL{$GLOBALS}|gettype)]

(#GET{datatype}) [ (#EVAL{#GET{datatype}}|gettype)]

Explications

Fini...

Une boucle DATA pour avoir les dernières versions de SPIP

Un xml

Explications

en gardant le id.
Le premier

$GLOBALS [
(#EVAL{$GLOBALS}|gettype)]

(#GET{datatype}) [
(#EVAL{#GET{datatype}}|gettype)]