Categories
Uncategorized

Structure générale de spip

SPIP est un CMS unique en son genre.

Au delà de son fonctionnement qu’on peut qualifier de “data driven”, à savoir piloté par les données (les fameuses BOUCLES), il a toujours fourni en première ligne les moyens de “customiser”, adapter son fonctionnement et sa présentation au goût et aux besoins propres au site.

C’était d’abord la possibilité de fournir ses propres “squelettes” (templates), d’adjoindre des fragments de php spécifiques et de surcharger les fonctions de base du core (les xxx_dist() que nous verrons plus loin).

La version 1.9 introduit un mécanisme complémentaire, les plugins. Ils sont issus de la volonté d’ouvrir spip à des fonctionnalités supplémentaires sans alourdir le noyau de SPIP (le core). La tendance actuelle est même d’alléger ce core en transférant les fonctionnalités optionnelles dans des plugins. SPIP 2.0 devrait être réduit et livré avec une collection de plugins “de base” que l’utilisateur activera selon ce qu’il utilise réellement. Par exemple, il est question que les brêves ne soient plus dans ce core mais dans un plugin optionnel. En effet, seule une partie des installations les utilisent et il est préférable de ne pas alourdir le système de base pour ceux qui n’en ont pas besoin.

Mais déjà, SPIP 1.9 a complètement réorganisé les répertoires qui le constituent afin de bien séparer les éléments selon leur durée de vie, le fait qu’il soient modifiables et leur appartenance à ce qui est propre ou spécifique au site ou au code de base. Un des autres objectifs visés ici est la possibilité de mutualiser le noyau : que plusieurs sites puissent partager une base de code commune.

Etudions d’abord cette nouvelle organisation des répertoires, de ce qui appartient à SPIP à ce qui est propre au site, de ce qui reste constant à ce qui bouge.


DISTRIBUTION


racine du site

La racine a été complètement vidée et ne contient pratiquement plus que index.php qui redirige sur spip.php, c’est maintenant l’unique point d’entrée de la partie publique du site.

inc-public.php3 est un fichier fantome pour assurer la compatibilite ascendante.

.htaccess optionnel pour l’url rewriting essentiellement.

win_png.htc et rien.gif pour assurer la transparence png avec MSIE

ecrire/

Ce dossier contient maintenant l’ensemble des fichiers interprétables côté serveur (PHP et MySQL) et ce, aussi bien pour le coté “public” (sous-dossier public/) que pour le coté “privé”.

Le nom de ce dossier est historique, c’était auparavant là où on trouvait le code permettant de modifier le contenu du site. Paradoxalement, c’est un dossier maintenant immuable, on “écrira” plus jamais dedans. Dans une installation normale, il ne contient que les scripts livrés par la distribution, il est quasi impératif de ne pas y faire de modification.

Son script index.php est le point d’entrée de ecrire/, la partie privée du site.

Voyons la documentation de spip.net pour le détail.

dist/

Il contient tous les fichiers livrés au client (HTML, Javascript, feuilles de style, images de différents formats) ainsi que les patrons de mise en page nommés squelettes. Ces squelettes sont interprétés coté serveur afin d’envoyer au client un texte purement MIME (la plupart du temps du HTML, mais aussi du RSS, du SVG … voire du JS).

Ce sont les modèles standards livrés avec SPIP, ils ne doivent eux aussi pas être modifiés mais remplacés en les copiant dans squelettes/

Détail dans la documentation de spip.net

oo/

Ce dossier fournit le mode “accessibilité” de spip (spip en mode texte), Il contient essentiellement un index qui renvoie dans le système standard.


ADAPTATION


config/

Ce dossier créé à l’installation contient le script de connection à la base de données, connect.php et le script fixant le mode des fichiers créés par le serveur, chmod.php.

C’est aussi ici qu’on place les options universelles du site, mes_options.php

IMG/

Il contient tous les documents originaux (taille réelle) du sites. Il est subdivisé en sous-dossiers par types de documents.

A l’installation, il ne contient que les documents de test pour la fabrication des images.

squelettes/

C’est ici qu’on dispose tous les fichiers scripts, images, formulaires … propres au site en suivant la même structure que ecrire/ ou dist/. Par exemple, pour redéfinir le sommaire du site, on y copie/adapte le sommaire.html de la dist/.

On met là notamment, le script mes_fonctions.php qui est chargé à chaque recalcul de page. A noter qu’il est possible de faire un xxx_fonctions.php qui sera chargé uniquement lorsque la page xxx sera demandée, exemple sommaire_fonctions.php

A l’installation, ce dossier n’existe pas, il faut le créer.

plugins/

Ce dossier qui est aussi à créer par soi-même reçoit les sous-dossiers de chaque plugin. Par exemple, le plugin crayons est placé dans plugins/crayons/.

C’est ce dossier qui fait l’objet de cette formation.


TEMPORAIRE


local/

Il contient tous les fichier (re-)calculables à partir des documents et données du site.

Il s’agit essentiellement des caches d’images réduites. On y trouve aussi les caches calculés par certains plugins comme coloration_code.

Ce dossier peut être vidé, cela ne coûtera que son recalcul.

tmp/

Ici sont stockés tous les fichiers temporaires comme les caches de squelettes, les sessions, les logs etc.

Il contient aussi le sous-réperoire dump/ où sont effectuées les sauvegardes de données.

Ce dossier peut être vidé à tout moment. Voir Étendre SPIP
et Contribuer au développement de SPIP

Categories
Uncategorized

Mecanismes de fabrication des pages publiques et privées

En version 1.9, le fonctionnement de SPIP a été rationalisé complètement. Il n’existe plus maintenant que 2 points d’entrée pour le site :

  • Public : index.php alias spip.php à la racine
  • Privé : ecrire/index.php

La page demandée est précisée dans un cas comme dans l’autre par les arguments GET ou POST associés à la requète. Nous verrons plus loin quels sont les principaux.

A de très rares exceptions près (a priori customisation), tous les autres scripts présents dans l’arborescence ne sont pas exécutables directement mais uniquement incluables. Ils sont d’ailleurs en général “protégés” par un test initial :

Ceci vérifie que la constante _ECRIRE_INC_VERSION est définie, ce qui ne sera pas le cas si le script est chargé directement.

Cette constante est définie par ecrire/inc_version.php qui constitue la clé de voute de l’architecture SPIP. Ce script est en effet inclus pratiquement en tout début par les index public ou privé.

Pour l’index public, cela passe par l’inclusion initiale de ecrire/public.php : mis à part cet include, on peut voir que cet index est pratiquement vide.

ecrire/inc_version.php

Ce script est commun à tous les composants de spip. C’est lui qui procède aux définitions, initialisations et inclusions de base qui déterminent le fonctionnement de tout le reste. Il initialise les constantes et les variables globales nécessaires au fonctionnement de SPIP, notamment celles assurant sa portabilité sur les différentes plates-formes.

Assez tôt lors de son chargement, il inclut les fichiers :

  • inc/utils.php, où figurent les fonctions indispensables à SPIP (voir plus loin)
  • le script optionnel hors distribution nommé mes_options.php qui permet de moduler cette initialisation sans avoir à modifier le fichier inc_version.php.

Déroulement du code :

  • définition de la constante “clé” _ECRIRE_INC_VERSION vue plus haut
  • définition des constantes représentant les répertoires de base de SPIP et en particulier _DIR_RACINE, racine du site, et _DIR_RESTREINT, répertoire ecrire/ sur lesquelles toutes les autres constantes de dossier seront basées, voir le détail dans le code.
  • recherche, sans encore l’inclure du script mes_options.php historiquement dans ecrire/ et dans une installation normalisée dans config/
  • initialisation de l’ensemble des globales de base de spip dont les variables de personalisation, voir index technique de spip.net
  • inclusion de inc/utils.php
  • inclusion de mes_options.php optionnel
  • appel de spip_initialisation() si mes_options ne l’a pas déjà fait (en particularisant éventuellement cette initialisation). Elle prend en paramètre les 4 répertoires de base de spip : config/, IMG/, tmp/ et local/ et :
    • définit à partir d’eux tous les répertoires nécessaires à spip et les droits qui leur sont affectés.
    • récupère et désinfecte tous les arguments de la requète : GET, POST, COOKIES et environnement serveur.
    • installe le module de lecture/écriture/suppression de fichiers nécessaire entre autres à tous les caches
    • commande le chargement des métas, la configuration de spip, depuis la base de donnée … et incidemment la connection à cette base.
  • charge les plugins à partir du cache tmp/charger_plugins_options.php en regénérant si nécessaire ce script.

Si l’on est en cours d’installation, inc_version.php a un fonctionnement particulier que nous n’aborderons pas ici.

inc/utils.php

Ce script ne réalise aucune action mais définit les fonctions utilitaires fondamentales de spip. Il y en a plus d’une cinquantaine ! Voici les plus importantes :

  • find_in_path() : afin de permettre la customisation du site, le plupart des fichiers, que ce soit script, squelettes ou fichiers servis comme les images, sont recherchés dans le “path”, dans l’ordre, les répertoires :
    • squelettes : ceux optionnellement définis dans $GLOBALS['dossier_squelettes'] et squelettes/
    • des plugins activés
    • ecrire/
    • dist/
    • racine du site
  • include_spip() : permet d’inclure un script php selon le schema précédent, donc de le surcharger en fournissant une alternative (communément appelée “fork”)
  • charger_fonction() : scenario identique mais adapté à une fonction, celle-ci pouvant être définie n’importe où. Le mécanisme cherche d’abord la fonction sous son nom() puis si pas trouvée, sous nom_dist() comme c’était fait historiquement (tous les fichiers de Spip sont chargés par ces deux dernières fonctions).
  • spip_log() : utilitaire permettant de faire des logs, typiquement dans tmp/spip.log, important pour la mise au point et le suivi d’un site. A noter qu’étant basée sur un var_export(), on peut lui passer tout type de paramètre à tracer.
  • spip_query() : toutes les requètes SQL doivent passer par cette fonction. Important, il faut préciser les noms des tables comme spip_nomtable, la fonction se chargeant de remplacer “spip_” par le véritable préfixe des tables de l’installation.
  • _q() : cette fonction protège les variables incluses dans une requète SQL (échappement). Il est fondamental de passer toute variable utilisée dans une requète SQL si on veut éviter des attaques par injection
  • _request() : permet de récupérer des variables argument de la requète, sans se préoccuper qu’elles viennent d’un GET, POST ou COOKIE et en étant assuré qu’elles sont “nettoyées” correctement.
  • spip_initialisation() vue plus haut

config/mes_options.php

Ce script optionnel permet de configurer les constantes, variables et fonctions de spip “à sa sauce”.

On peut :

  • y adapter les variables de personalisation (globales), par exemple les dossiers squelettes spécifiques ou le type d’url propre utilisé.
  • redéfinir des fonctions dépendant du mécanisme xxx_dist() ou plus généralement chargées par charger_fonction()
  • définir des “constantes” PHP : en effet, une fois définie, une constante PHP ne peut plus être changée dans la session

En particulier, il est possible dans ce fichier personnel d’invoquer la fonction spip_initialisation pour définir les répertoires de données et, par exemple, disposer ainsi de plusieurs sites sous SPIP utilisant une seule distribution (l’appel standard de cette fonction, plus loin dans inc_version.php, sera automatiquement neutralisé).

Argument de requète principal

Comme on l’a vu, les seuls accès à spip se font par index.php à la racine ou dans ecrire/. La page demandée est précisée par les arguments accompagnant cette requète. Ce peut être par GET ou POST. Ces arguments peuvent être explicites ou générés par l’url rewriting lorsqu’on utilise les urls propres.

Il s’agit de :

  • page : c’est l’unique argument pour l’espace publique. Il précise la page demandée comme sommaire (le défaut), article … Il est interprété par ecrire/public.php pour déterminer le fond principal (le squelette.html du même nom que l’argument page) à renvoyer après l’avoir “rempli” en fonction des autres paramètres de la requète comme id_article.
  • action : bien que ce paramètre soit aussi interprété par ecrire/public.php , il s’agit ici d’une requète effectuant (si tout va bien) une modification dans les données du serveur. SPIP fournit un mecanisme permettant de sécuriser une telle requète. Le script qui sera utilsé est action/xxx.php où xxx est la valeur de action
  • exec : c’est typiquement l’argument d’une url “privée”. Sa valeur xxx donne le script ecrire/exec/xxx.php qui sera utilisé.

Voir Étendre SPIP

Categories
Uncategorized

Installation de plugins

Categories
Uncategorized

Tour d’horizon des plugins courants, que peut fournir un plugin

Categories
Uncategorized

Présentation des urls libres

Unification et extension des urls propres 1.9.2
Disponible sous forme de plugin, mise en place immédiate

Le plugin urls libres prend en charge la génération et l’anlyse des urls en “texte clair” pour les relier aux références numériques des “objets” de spip. Il maintient la compatibilité avec les anciens urls propres et intègre les fonctionnalités de propres2, notamment vis à vis des robots référenceurs. Prémisses pour les 5 ans de spip

 

spip-1.9.2 : Etat des lieux

Assouplir les urls

Mise en service

Categories
Uncategorized

Listes imbriquées hétérogènes

Test pour spip 1.9.2

 

Des listes où on mélanges * et # comme -*#*

  • Your horse is :
    -
    -
    -
  • but my rabbit is
    • white :
      -
      -

Des listes où on ne mélange pas * et #

  • Your horse is :
    • chestnut ;
    • bay ;
    • black ;
  • but my rabbit is
    • white :
      • angora
      • or short-haired.

  1. first
  2. second
  3. third

- simple
- si simple
- vraiement

Categories
Uncategorized

Widgets

Le plugin widgets dynamise l’espace public en permettant des mises à jour directes des articles et autres sans passer par l’espace privé, par le biais d’applets insérées par jQuery dans la page.

Le paramétrage coté squelettes est des plus simples, il suffit d’ajoindre 2 classes aux éléments qu’on veut rendre modifiables.

 

Transféré sur contrib
Categories
Uncategorized

test echappe_html

Comparaisons des ressources utilisées part les différentes solutions , voir http://trac.rezo.net/trac/spip-zone…

 

5.1.6 Spip : Usage Ressources

test avec hervé

simple imbriqué (ok)

Ressources actuel recursif nouveau essais
time 0.053353071212769 0.067670106887817 0.078830003738403 0.085078001022339
utime 0.056004 0.064004 0.076004 0.088006
stime 0 0 0 0
pagereclaim 6 0 7 0
pagefaults 0 0 0 0
swap 0 0 0 0
vcsw 0 0 0 0
ivcsw 5 8 3 2

complexe imbriqué (ok)

Ressources actuel recursif nouveau essais
time 0.23963189125061 0.34207797050476 0.32029509544373 0.2912700176239
utime 0.240015 0.340021 0.32002 0.292018
stime 0 0 0 0
pagereclaim 0 0 7 0
pagefaults 0 0 0 0
swap 0 0 0 0
vcsw 0 0 0 0
ivcsw 3 5 2 7

unicode sans rien (ok)

Ressources actuel recursif nouveau essais
time 0.013925075531006 0.015367984771729 0.022572994232178 0.023957014083862
utime 0.016001 0.016001 0.020002 0.020001
stime 0 0 0 0
pagereclaim 0 0 0 0
pagefaults 0 0 0 0
swap 0 0 0 0
vcsw 0 0 0 0
ivcsw 0 0 2 8

sans rien (ok)

Ressources actuel recursif nouveau essais
time 0.015764951705933 0.017358064651489 0.022033929824829 0.0171959400177
utime 0.016001 0.020001 0.020001 0.020002
stime 0 0 0 0
pagereclaim 0 0 0 0
pagefaults 0 0 0 0
swap 0 0 0 0
vcsw 0 0 0 0
ivcsw 0 1 0 0

code sans imbrication (ok)

Ressources actuel recursif nouveau essais
time 0.065425157546997 0.088914155960083 0.08191704750061 0.068562030792236
utime 0.064004 0.084005 0.084005 0.068004
stime 0 0 0 0
pagereclaim 0 0 0 0
pagefaults 0 0 0 0
swap 0 0 0 0
vcsw 0 0 0 0
ivcsw 0 8 8 3

pourriture (ok)

Ressources actuel recursif nouveau essais
time 0.72444415092468 581.25098991394 0.60448622703552 4.6587698459625
utime 0.724045 578.712167 0.60003800000004 4.472279
stime 0 0.424027 0 0.004
pagereclaim 0 0 0 0
pagefaults 0 0 0 0
swap 0 0 0 0
vcsw 0 0 0 0
ivcsw 14 6775 32 331

4.4.4 Spip : Usage Ressources

simple imbriqué (ok)

Ressources actuel recursif nouveau essais
time 0.092036008834839 0.077789068222046 0.11046314239502 0.12436008453369
utime 0.088006 0.080005 0.108007 0.128008
stime 0 0 0 0
pagereclaim 2 0 3 0
pagefaults 0 0 0 0
swap 0 0 0 0
vcsw 0 0 0 0
ivcsw 8 1 0 1

complexe imbriqué (ok)

Ressources actuel recursif nouveau essais
time 0.29609489440918 0.43756699562073 0.42828798294067 0.36025595664978
utime 0.296018 0.436027 0.428027 0.364023
stime 0 0 0 0
pagereclaim 0 0 6 0
pagefaults 0 0 0 0
swap 0 0 0 0
vcsw 0 0 0 0
ivcsw 1 0 0 0
Categories
Uncategorized

code dans code

voir le test sur toggg.info

Ici , le plugin inclut le patch correctif définitif :

Pour insérer du code coloré, il suffit de rajouter {class=”xxx”} au tag code de spip:
<code class=”php”>
// mon morceau de php
$variable = “blah”;
// …

et le tour est joué

Et voilà !

Arrggghhhh….. Ca marche pas ici … php 4.2.2 ?

Finalement si en SPIP 1.9.2 alpha 2 SVN 7714

Categories
Uncategorized

2 images

 

JPGJPG