Geekographie Maïeulesque

Succession d'articles avec A2A

2012-09-13T19:16:57Z

La nouvelle version du plugins A2A permet de typer les relations entre articles. Je m'en sert sur ce site pour créer des succession d'articles, par exemple ma série d'articles sur les stemma.

Comment fais-je ?

Configuration du plugin

Je crée un nouveau type de relation, dont la clef est « Suivant » et le titre est « Article suivant ».

Chaque article de la chaîne, sauf le dernier, est relié à l'article suivant selon ce type.

Voilà pour l'espace privé.

Côté squelettes

Je souhaite afficher l'ensemble des articles de la chaîne dans laquelle se situe l'article courant mais :

En ne mettant pas de lien sur l'article courant.
En mettant un attribut rel=prev ou rel=next pour le liens vers l'article immédiatement précédent/suivant.

Voici comme je procéde, les commentaires suivent.

(ARTICLES){id_article}>
#SET{precedent,''}
#SET{suivant,''}
#SET{succession,#LISTE{#ID_ARTICLE}}
(ARTICLES_LIES){id_article_lie=#ID_ARTICLE}{type_liaison=suivant}>
#SET{succession,#LISTE{#ID_ARTICLE}|push{#GET{succession}}}
[(#ID_ARTICLE_LIE|=={#_article:ID_ARTICLE}|oui)
#SET{precedent,#ID_ARTICLE}
]
(Boucle_precedent) />
(ARTICLES_LIES){id_article=#ID_ARTICLE}{type_liaison=suivant}>
#SET{succession,#GET{succession}|push{#ID_ARTICLE_LIE}}
#SET{suivant,#ID_ARTICLE_LIE}
(ARTICLES_LIES){id_article=#ID_ARTICLE_LIE}{type_liaison=suivant}>
#SET{succession,#GET{succession}|push{#ID_ARTICLE_LIE}}
(BOUCLE_suivants) />
<:geek:succession_article:> :
(ARTICLES){id_article IN #GET{succession}}{si #GET{succession}|count|>{1}}>
[ class='(#EXPOSE)']>
[(#EXPOSE|non)#URL_ARTICLE"[ rel="next"(#ID_ARTICLE|=={#GET{suivant}}|oui)][ rel="prev"(#ID_ARTICLE|=={#GET{precedent}}|oui)]>]

#TITRE

[(#EXPOSE|non)]

Télécharger

l. 1 : la boucle englobante du squelette, je masque ici les autres contenus.
l. 2-3 : deux variables dans lesquelles on stockera les numéros de l'article précédent et de l'article suivant.
l. 4 : liste dans laquelle on va stocker les id de chaque article de la chaîne. On initialise la liste avec le numéro de l'article courant.
l. 5 et 11 : on cherche l'article précédent.
l. 6 : on ajoute l'article précédent à la liste des articles de la chaîne, en début de liste.
l. 9 : on indique l'id de l'article immédiatement précédent dans la variable precedent. Notez le test qui permet de jouer avec la récursion de la l. 10 sans changer à chaque fois precedent.
l. 13 à 20 : la même chose que l. 5 à 11, mais pour les articles qui suivent dans la chaîne. Notez qu'on étend la liste vers la fin, et non pas vers le début, comme précédement.
l. 23 à 38 : boucle (ARTICLES) classique, mais on choisit comme < code>id_article ceux listés dans le tableau. Notez que {id_article IN …}. On notera :
- l. 24 : l'utilisation de #EXPOSE pour styler différemment l'article courant, de même l. 25 et 27 pour n'afficher le liens que sur les articles différent de l'article courant.
- l. 25 [ rel="next"(#ID_ARTICLE|=={#GET{suivant}}|oui)] et son comparse [ rel="prev"(#ID_ARTICLE|=={#GET{precedent}}|oui)] qui permet d'ajouter l'attribut rel à la balise , si besoin.

Jouons un peu avec |image_masque

2012-08-13T18:04:23Z

Les lecteurs réguliers de ce site auront remarqué, outre le changement de style, que désormais les logos des articles possèdent une petite images dans le coin inférieur droit.

L'image principale correspond au logiciel dont il est question en priorité : par exemple SPIP. L'image secondaire correspond à la rubrique principale de l'article. Ainsi pour notre article, il s'agit de la rubrique Images. Enfin, dans certains cas, une image est mise dans le coin supérieur gauche : il s'agit de l'image correspondante au logiciel utilisé de manière secondaire dans l'article. Par exemple l'article « Gérer beaucoup de sites SPIP en local sous MacOsX » parle d'abord du logiciel SPIP, et ensuite du logiciel SVN. On a donc le logo de SVN en petit dans le coin supérieur gauche.

La composition de ces images est effectuée automatiquement par SPIP à partir des logos des différentes rubriques, grâce au filtre |image_masque. Cependant ce filtre manque de documentation, et j'ai du fouiller le code pour le comprendre. En attendant une documentation plus complète, voici déjà un tutoriel expliquant comment j'ai procédé dans le cas présent.

Principe

Il n'y a pas de logo sur les articles.
Les logos d'articles sont calculés à l'aide de l'arborescence de l'article :
- Le logo principal correspond au logo du secteur.
- Le logo en bas à droite correspond au logo de la rubrique
- Le logo en haut à gauche correspond au logo du premier secteur secondaire configuré avec le plugin polyhierarchie.
Comme il s'agit d'un logo, je n'ai pas jugé utile d'ajouter une balise alt autre que vide.
Nous allons faire un squelette inclure/logo-rubriques que nous appellerons via la balise #INCLURE. Ce squelette calculera le logo, pour l'afficher, sans le réduire
Le logo sera réduit au cas par cas en filtrant #INCLURE grâce à image_reduire.

Mise en œuvre

Dans notre boucle ARTICLES, à l'endroit où nous souhaitons afficher notre logo, nous mettons :

[(#INCLURE{fond=inclure/logo-rubriques,id_article}|image_reduire{xxx})]

en remplaçant xxx par la taille souhaité du logo au final.

Maintenant, il nous reste à créer notre squelette inclure/logo-rubriques.html.

Dans ce squelette, nous procéderons ainsi :

Extraction des différents logos de rubriques, et stockage dans des variables.
Calcul de la taille des logos secondaires.
Fabrication de l'image finale.

Il ne faut pas oublier de mettre une boucle englobante dans le squelette :

(ARTICLES){id_article}>

Télécharger

Tout le code qui va suivre devra se mettre dans cette rubrique. Donc, première étape :

{id_rubrique}>
#SET{rubrique,#LOGO_RUBRIQUE}
{id_secteur}{racine}>
#SET{secteur,#LOGO_RUBRIQUE}
{parents_indirects}>
{id_rubrique}{racine}>
#SET{autre_secteur,#LOGO_RUBRIQUE}

Télécharger

Commentaires :

L. 1-3 : On sélectionne le logo de la rubrique de l'article (celui qui sera affiché en bas à droite) et on le stocke dans rubrique.
L. 5-7 : On sélectionne le logo du secteur de l'article (celui qui sera affiché en gros) et on le stocke dans secteur.
L. 9-13 : On sélectionne le logo du second secteur de l'article (celui qui sera affiché en haut à gauche), et on le stocke dans autre_secteur. L'imbrication des boucles s'expliques par le fait qu'il n'est pas possible de combiner {racine} et parents_directs.

Maintenant, nous sommes prêts pour la seconde étape : calculer les hauteurs et largeurs maximales de nos logos secondaires. En ce qui concerne la hauteur, j'ai opté pour 1/3 de l'image principale ; en ce qui concerne la largeur, j'ai opté pour 1/2.

On utilise pour cela les filtres |hauteur, |largeur pour déterminer la hauteur et la largeur de l'image principale, |div pour procéder à une division, et |floor pour arrondir à l'entier inférieur.

Cela donne donc :

#SET{largeur,#GET{secteur}|largeur|div{2}|round}

Il ne nous reste plus qu'à fabrique nos images finales. Pour ce faire nous utiliserons les filtres suivants :

|==, |non et |oui, pour vérifier la présence des différents logos.
|image_reduire qu'on ne présente plus.
|image_masque, qui peut recevoir beaucoup de paramètres en troisième argument, que la documentation ne détaille pas. Ces paramètres sont à séparer par des virgules. Dans le cas présent, ceux qui nous intéressent sont :
- mode=normal pour que l'image du dessus masque totalement l'image du dessous.
- text-align pour le positionnement horizontal.
- vertical-align pour le positionnement vertical.

Au niveau des possibilités de combinaison, nous en avons quatre possibilités :

L'article ne se trouve pas directement dans un secteur. Dans ce cas il nous faut tester s'il dispose d'un secteur secondaire :
- S'il ne dispose pas de secteur secondaire, le logo final correspond au logo du secteur sur lequel on ajoute en bas à droite le logo de la rubrique (cas 1).
- S'il dispose d'un secteur secondaire, le logo final correspond au logo du secteur sur lequel on superpose (cas 2) :
  - Le logo de la rubrique en bas à droite.
  - Le logo du secteur en haut à gauche.
L'article se trouve directement dans un secteur. Dans ce cas, nous testons s'il dispose d'un secteur secondaire :
- S'il n'en dispose pas, alors le logo correspond tout simplement au logo du secteur (cas 3).
- S'il en dispose, alors le logo correspond au logo du secteur, sur lequel on superpose le logo du secteur secondaire (cas 4).

Au final, cela donne :

[(#GET{rubrique}|=={#GET{secteur}}|non)
[(#GET{autre_secteur}|non) [(#REM)]
[(#GET{secteur}|image_masque{
#GET{rubrique}|image_reduire{#GET{largeur},#GET{hauteur}},
mode=normal,
text-align=right,
vertical-align=bottom})]
]
[(#GET{autre_secteur}|oui) [(#REM)]
[(#GET{secteur}|image_masque{
#GET{rubrique}|image_reduire{#GET{largeur},#GET{hauteur}},
mode=normal,
text-align=right,
vertical-align=bottom
}|image_masque{
#GET{autre_secteur}|image_reduire{#GET{largeur},#GET{hauteur}},
mode=normal,
text-align=left,
vertical-align=top})]
]
]
[(#GET{rubrique}|=={#GET{secteur}}|oui)
[(#GET{autre_secteur}|non) [(#REM)]
#GET{secteur}
]
[(#GET{autre_secteur}|oui) [(#REM)]
[(#GET{secteur}|image_masque{
#GET{autre_secteur}|image_reduire{#GET{largeur},
#GET{hauteur}},
mode=normal,
text-align=left,
vertical-align=top})]
]
]

Télécharger

Et donc notre squelette inclure/logos-rubriques final est :

(ARTICLES){id_article}>
[(#REM)]
(RUBRIQUES){id_rubrique}>
#SET{rubrique,#LOGO_RUBRIQUE}

(RUBRIQUES){id_secteur}{racine}>
#SET{secteur,#LOGO_RUBRIQUE}

(RUBRIQUES){parents_indirects}>
(RUBRIQUES){id_rubrique}{racine}>
#SET{autre_secteur,#LOGO_RUBRIQUE}

[(#REM)]
#SET{hauteur,#GET{secteur}|hauteur|div{3}|round}
#SET{largeur,#GET{secteur}|largeur|div{2}|round}
[(#REM)]
[(#REM)]
[(#GET{rubrique}|=={#GET{secteur}}|non)
[(#GET{autre_secteur}|non) [(#REM)]
[(#GET{secteur}|image_masque{
#GET{rubrique}|image_reduire{#GET{largeur},#GET{hauteur}},
mode=normal,
text-align=right,
vertical-align=bottom})]
]
[(#GET{autre_secteur}|oui) [(#REM)]
[(#GET{secteur}|image_masque{
#GET{rubrique}|image_reduire{#GET{largeur},#GET{hauteur}},
mode=normal,
text-align=right,
vertical-align=bottom
}|image_masque{
#GET{autre_secteur}|image_reduire{#GET{largeur},#GET{hauteur}},
mode=normal,
text-align=left,
vertical-align=top})]
]
]
[(#GET{rubrique}|=={#GET{secteur}}|oui)
[(#GET{autre_secteur}|non) [(#REM)]
#GET{secteur}
]
[(#GET{autre_secteur}|oui) [(#REM)]
[(#GET{secteur}|image_masque{
#GET{autre_secteur}|image_reduire{#GET{largeur},
#GET{hauteur}},
mode=normal,
text-align=left,
vertical-align=top})]
]
]

Télécharger

Gérer le statut des articles directement depuis le site public sous SPIP 3

2012-08-12T19:43:32Z

J'avais publié il y a plus d'un an et demi un article sur la manière de gérer directement le statut des articles depuis le site public.

Voici son adaptation pour SPIP 3. Comme vous pourrez le voir, le code est beaucoup plus simple.

Il suffit en effet de mettre dans son squelette, dans la boucle (ARTICLES) :

[(#AUTORISER{publier,article,#ID_ARTICLE}|oui)
#FORMULAIRE_INSTITUER_OBJET{article,#ID_ARTICLE,#SELF|parametre_url{var_mode,preview}}
]

Télécharger

L. 1 et 3 : On vérifie que la personne connectée à bien le droit de publier l'article en question. Voir la documentation sur #AUTORISER.
L. 2 : appel du formulaire permettant de changer le statut d'un objet. Ici on précise que l'on veut pouvoir modifier le statut d'un article, dont l'identifiant est #ID_ARTICLE Le troisième argument SELF|parametre_url{var_mode,preview} sert à ne pas tomber sur une erreur 404 si on dépublie l'article : il indique qu'après l'exécution du formulaire on retourne sur la même page, en mode previsualisation [1].

[1] Attention, cela ne fonctionne pas si l'on passe le statut à « refusé » ou « à la poubelle ».

Jeux de squelettes sous forme de plugin pour SPIP 3

2012-07-23T15:29:48Z

Dans un précédent article, j'expliquais pourquoi et comment distribuer un jeu de squelettes sous forme de plugin. Cet article est une simple adaptation pour SPIP 3.

Les raisons de distribuer un jeux de squelette sous forme de plugin n'ont pas changé : je ne les répète donc pas. En revanche, le passage à SPIP 3 a introduit la transformation de plugin.xml à paquet.xml. Ces changements sont liés à la volonté d'avoir un formalisme plus important et plus propre. Voici donc un fichier paquet.xml minimal pour proposer un jeu de squelettes sous forme de paquet.xml. On lira les spécifications du paquet.xml pour aller plus loins.

prefix='prefix'
categorie='squelette'
version='x.y.z'
etat='dev/test/stable'
compatibilite="compatibilité de version SPIP"
>
>Nom du plugin>
lien="siteweb" mail="auteur@domaine.tld">Nom de l'auteur>
lien="siteweb">Licence>
nom="prefixplugin" compatibilite="une compatibilite" />
>

Télécharger

Selon la documentation officielle, la compatibilité prend l'une des formes suivantes :

[v1 ;v2] qui correspond à v1 <= SPIP <= v2
[v1 ;[ qui correspond à SPIP >= v1
[ ;v2[ qui correspond à SPIP < v2

et toutes les autres combinaisons avec inclusion ou pas des bornes.

Ainsi pour indiquer une compatibilité sur toute la branche SPIP 3, mettre :

prefix='prefix'
categorie='squelette'
version='x.y.z'
etat='dev/test/stable'
compatibilite="[3.0.0;3.0.*]"
>

Télécharger

À noter que ni la balise auteur ni la balise licence ne sont obligatoires, et leurs attributs sont facultatifs. En outre, on doit mettre une balise auteur par auteur.

Vous devez choisir entre l'un des trois états du squelette : dev, test, ou stable. Le prefix du squelette doit être parlant mais court. Vous pouvez préciser dans les attributs documentation et demonstration de la balise paquet l'url de la documentation et du site de démonstration.

En ce qui concerne la balise necessite, il faut en mettre une par plugin nécessaire, en mettant comme valeur de l'attribut nom le préfixe du plugin demandé.

Vous pouvez aussi préciser les versions compatibles de ces plugins, via l'attribut compatibilite, ayant la même syntaxe que pour la balise paquet.xml.

Il ne faut pas mettre de numéro de version dans le prefix ni dans le titre : l'attribut version sert à cela. Cette attribut doit avoir la forme x.y.z :
Un changement de X indique un changement majeure (rupture de compatibilité, réorganisation totale du code).
Un changement de Y indique un changement mineure (nouvelle fonctionalité).
Un changement de Z indique une correction de bug.

Il est très fortement demandée de mettre les trois chiffres pour une version d'un squelette.

Le fichier de langue

Avec paquet.xml certains éléments doivent être indiqués dans des fichiers de langue. Ces fichiers doivent être situés dans le dossier lang du plugin, et avoir un nom sous la forme : paquet-{préfixe_du_plugin}_{code_de_langue}.php. Par exemple, pour un jeux de squelette dont le prefix est toto, les chaînes de langues de descriptions du squelette seront à placer dans lang/paquet-toto_fr.php.

Il existe deux chaînes de langues quasi-obligatoires :

$GLOBALS[$GLOBALS['idx_lang']] = array(
'prefix_description' => 'Description aussi succincte que possible du plugin, pas une documentation.',
'prefix_slogan' => 'Slogan du plugin'
);
?>

Télécharger

Et le fichier `options.php` ?

Dans la précédente version de cet article, je présentais rapidement un fichier options.php recommandés. Ce fichier n'a plus de sens pour une distribution minimale d'un jeu de squelette, puisque SPIP 3 s'occupe automatiquement de supprimer les numéros devant les titres.

Cependant, pour une jeu de squelette propre à votre organisation et non générique, vous pouvez mettre un fichier prefix_options.php afin d'augmenter le quotat de cache, en mettant les lignes suivantes (pour augmenter à 100 Mo le quota de cache :

$GLOBALS['quota_cache'] = 100;
?>

Télécharger

Vérifier son paquet.xml

On pourra utiliser l'outil de vérification en ligne pour s'assurer de la conformité du fichier paquet.xml.

Les différents modes d'inclusion de SPIP

2012-01-26T10:25:35Z

Suite à une remarque de Tetue après mon article sur les pratiques de développements avec SPIP et à une question d'un théologien sur twitter, je fais ici un point sur les deux modes d'inclusion de squelettes dans SPIP.

Rappel : principe de l'inclusion

Inclure un squelette A dans un squelette B, c'est dire à B de reprendre le contenu du squelette A à l'endroit de l'inclusion.

L'interêt d'une telle pratique est de mettre en commun des morceaux de codes utilisés par plusieurs squelettes. Le cas le plus classique étant l'affichage du menu, mais plus le temps passe, plus le devellopeur SPIP aguerri aura tendance à multiplier les inclusions, voyant qu'il utilise beaucoup de code en commun.

Le principe des squelettes Z pousse à l'extrême cette idée d'inclusion / mutualisation du code.

Mais attention : il ne faut pas croire qu'on imite ainsi un « copier-coller » de B dans A.

Ainsi si je met dans le squelette A :

XXX{fond=B}>XXX

et dans le squelette B

YYY

Cela ne revient pas au même que mettre dans A :

XXXYYYXXX

Pourquoi ? Parce qu'il faut considérer que le contexte de chaque squelette est indépendant. Par contexte, j'entend l'ensemble des paramètres techniques qui lui sont passés, par exemple un numéro d'article. Ce contexte est récupérable via la balise #ENV et sert à l'interprétation des critères de boucles de premier niveaux. J'explique plus en détails cette notion de contexte dans un article sur contrib.

ou `#INCLURE` ?

Il existe deux modes principaux d'inclusion :

#INCLURE{fond=B}

Historiquement, le premier modèle est apparu d'abord. Quelle est la différence technique entre les deux ? Soit un squelette A appelant un squelette B.

Dans le cas d'une inclusion avec INCLURE le squelette B possède son propre cache. Lorsque le squelette A est appelé, il produit son cache à lui. Le résultat du cache de A est retourné au navigateur, et c'est à ce moment là que le cache du squelette B est inséré.
Dans le cas d'une inclusion avec #INCLURE, il n'existe pas de cache du squelette B. Le morceau de PHP / HTML lié à l'interprétation par SPIP du squelette B est mis directement dans le cache du squelette A.

Puisqu'il paraît qu'il faut mettre des schémas, voici un schéma qui tente d'expliquer cette différence [1].


ou #INCLURE ?: Inclusion statique ou inclusion dynamique ?

Conséquences techniques

Du point de vue de la taille des caches :
1. produit plus de fichiers de cache, mais moins gros.
2. #INCLURE produit des fichiers de cache plus gros, mais en moindre quantité.
Du point de vue de la durée des caches :
1. permet d'avoir un squelette fils n'ayant pas la même durée de cache que le squelette père.
2. #INCLURE ne permet pas cela, puisque le squelette fils n'a pas vraiment de cache propre.
Du point de vue des techniques SPIP applicables :
1. On peut pas filtre le résultat d'une inclusion par [2].
2. Par contre avec #INCLURE on peut appliquer un filtre [(#INCLURE{fond=B}|filtre)].
3. Dans tout les cas on peut utiliser AJAX.
Du point de vue de la performance j'avoue ne pas trop savoir. Avoir un cache propre () permet d'avoir une vrai mutualisation des caches, dont un gain en terme de requête SQL, en revanche on a une perte de temps au moment où le cache de B est « reinjecté » dans le fichier A renvoyé à l'internaute. C'est donc au développeur de juger au cas par cas, mais il me semble que dans 90 % des cas, il vaut mieux utiliser .

`Et #MODELE`


On peut aussi utiliser #MODELE. Pour ce faire, il faut que le fichier inclu se situe dans le dossier modeles.
 Techniquement, faire
 #MODELE{B}
 revient, à peu de chose près, à la même chose que faire #INCLURE{fond=modeles/B}. Une différence toutefois : dans le cas de #MODELE l'identifiant de l'objet courant est automatiquement passé en paramètre.
 Exemple, j'ai un squelette modeles/B.html :
(ARTICLES){id_article}>

#ID_ARTICLE #TITRE

 Télécharger
Dans mon squelette A, je cherche à appeler ce squelette pour tout les articles d'une rubrique.
 Je peux faire soit :
(ARTICLES){id_rubrique}>

#MODELE{B}

 Télécharger
soit :
(ARTICLES){id_rubrique}>

#INCLURE{fond=modeles/B,id_article}

 Télécharger
Personnellement je n'aime pas trop #MODELE, je trouve qu'il induit une confusion. Le seul cas où l'emploi de modèle est justifiable, c'est lorsque l'on souhaite permettre à un auteur d'inclure un tel morceau dans son article, en utilisant :

Par exemple le plugin Gravatar propose un modèle gravatar, que l'on peut appeler :
 soit dans un squelette #MODELE{gravatar}{id_auteur}.
 soit dans un article .
On consultera la documentation sur les modèles pour plus de détails.


		
		
[1] Toute suggestion d'amélioration est la bienvenue.

[2] Une solution pour contourner ce problème est de mettre #FILTRE{nom du filtre} dans le squelette inclus.

		Pour aider à y voir plus clair dans les différents squelettes inclus, on utilisera la fonction var_mode=inclure.



Gérer beaucoup de sites SPIP en local sous MacOsX
2012-01-11T15:38:18Z
Cet article ne s'adresse pas aux SPIPeurs débutants qui souhaiteraient créer un site web en local sous Mac. Un article existe déjà sur le sujet. Non, cet article s'adresse aux personnes qui souhaitent gérer beaucoup de site web en local en n'ayant qu'une installation de SPIP par version, autrement dit en mutualisant le noyau de SPIP.
 J'y détaille ma pratique, que j'utilise depuis trois ans, donc que j'estime mûre.
		Principe
Je développe en local 30 sites. Chaque site que je développe possède une adresse réelle, par exemple http://maieul.net [1], correspondant à la version cours de production, et une adresse locale, correspondante à la version en cours de développement.
 Par principe, chaque adresse d'un site local termine par .dev. Par exemple maieul.dev, geek.dev, maman.dev etc. Pourquoi .dev ? Parce que cette extension n'existe pas, donc je suis certain que lorsque j'utilise .dev je suis en version locale.
 Je vais dire à mon ordinateur, via la modification d'un fichier caché, d'orienter mes adresses en .dev vers l'IP 127.0.0.1, autrement dit vers mon propre ordinateur.
 Conséquent : lorsque dans mon navigateur je frapperais http://maieul.dev, celui-ci me redirigera vers 127.0.0.1. La mon serveur local, MAMP, me renverra vers mon SPIP, que j'aurais organisé selon le principe de la mutualisation facile, c'est à dire à que j'aurais réglé pour avoir un seul noyau SPIP pour plusieurs sites (par exemple maman.dev, papa.dev etc.)
 Par ailleurs, un site fera exception localhost : ce site sert de brouillon pour toutes les expériences.
 De plus, je souhaite pouvoir disposer de différentes branches de SPIP : je souhaite pouvoir orienter vers la branche 2.0.z ou vers la branche 2.1.z ou vers la branche 3.0.z selon le cas. En revanche, je souhaite pouvoir facilement mettre à jour une branche.
 Je vais donc créer un dossier par branches, avec dans chaque dossier une mutualisation. Je configurerais mon serveur Apache local (installé via MAMP) pour qu'il me renvoi sur l'un ou l'autre des dossiers selon l'URL du site.
 Bon, tout ceci c'était la théorie, passons à la pratique.
 Cette pratique nécessite d'utiliser les Terminal, pour frapper quelques commandes.
Préparer les versions de SPIP
Dans le terminal, rendons-nous dans le dossier sites du répertoire de départ :
cd ~/sites
Puis récupérons les dernieres versions stables des différentes branches de SPIP. Ces versions sont situées dans le dossier tags du serveur SVN de SPIP.
svn co svn://trac.rezo.net/spip/tags/spip-2.0.9 SPIP 20

svn co svn://trac.rezo.net/spip/tags/spip-2.1.12 SPIP21
 Télécharger
Et soyons fous, prenons même la dernière version de dev de SPIP, instable (pour le moment c'est SPIP 3)
svn co svn://trac.rezo.net/spip/spip SPIPdev
Je me retrouve donc dans mon dossier sites avec trois dossiers : SPIP20 SPIP21 et SPIPdev.
 Par défaut mes sites pointeront vers SPIP21. Les autres sites seront des exceptions.
Préparer la mutualisation
Maintenant rendons-nous dans le dossier SPIP21 pour préparer le chemin à la mutualisation des sites SPIP.
cd ~/SPIP21
D'abord il faut récupérer le plugin mutualisation facile :
svn://zone.spip.org/spip-zone/_plugins_/mutualisation
Ensuite il me faut copier le fichier mes_options.php dans le dossier config.
cp mutualisation mes_options.php.txt mes_options.php
Puis ouvrir le fichier config/mes_options.php avec le logiciel de mon choix.
 Il va falloir régler pour indiquer les réglages MySQL de Mamp.
 Voici le contenu de ce fichier

 /*
 * Inscrire ici le nom du site d'administration du tableau de bord
 * de la mutualisation (ou plusieurs, separes par des virgules)
 * (dans cet exemple, 'scriibe.net' est le top level domain, TLD)
 * pour autoriser tous les sites, ne pas definir la constante ;
 * Si le site maitre n'est pas dans sites/ mais a la racine, mettre ''
 * et ajouter 'mutualisation' dans $dossier_squelettes
 */
 define ('_SITES_ADMIN_MUTUALISATION', 'scriibe.net');
 if (!defined("_ECRIRE_INC_VERSION")) return;
 if (!is_readable (_DIR_RACINE.'mutualisation/mutualiser.php')) {
 echo _L("Fichier 'mutualisation/mutualiser.php' manquant dans la racine " . _DIR_RACINE);
 exit;
 }
 require _DIR_RACINE.'mutualisation/mutualiser.php';
 /* placer dans ce tableau les sites ou l'on ne veut pas la redirection canonique */ 
 $www = array();
 
 $site = str_replace('www.', '', $_SERVER['HTTP_HOST']);
 if ($site != $_SERVER['HTTP_HOST'] AND !in_array($site, $www)) {
 include_spip('inc/headers');
 $req = isset($_SERVER['REQUEST_URI']) ? $_SERVER['REQUEST_URI'] : '/';
 if (isset($_SERVER['HTTPS']) 
 AND test_valeur_serveur($_SERVER['HTTPS']))
 $protocole = 'https';
 elseif (!isset($_SERVER["SCRIPT_URI"]) OR !($p = strpos($_SERVER["SCRIPT_URI"], '://')))
 $protocole = 'http';
 else $protocole = substr($_SERVER["SCRIPT_URI"],0,$p);
 redirige_par_entete($protocole . '://' . $site . $req);
 }
 // Compatibilite avec le ":" de $dossier_squelettes
 // Si l'url indique explicitement un port (grace a ":")
 // tout eliminer s'il s'agit du port 80
 // et remplacer ":" par _ pour les autres ports
 if (strpos($site, ':')) {
 if (preg_match('/:80$/', $site)) $site = substr($site,-3);
 else $site = str_replace(':', '_', $site);
 }
 define ('_INSTALL_SITE_PREF', prefixe_mutualisation($site));
 define ('_INSTALL_NAME_DB', 'mu_'. _INSTALL_SITE_PREF);
 define ('_INSTALL_SERVER_DB', 'mysql'); 
 define ('_INSTALL_HOST_DB', 'localhost'); 
 define ('_INSTALL_USER_DB', 'loginsql'); 
 define ('_INSTALL_PASS_DB', '123456HDJ'); 
 
 /* mettre en commentaire la ligne suivante si vous utilisez l'option table_prefixe plus bas dans la config */ 
 define ('_INSTALL_TABLE_PREFIX', 'spip');
 /* 
 * Si le nom du serveur est different du nom dns, 
 * ca peut parfois poser probleme
 * il faut alors le definir ici
 */
 # define ('_INSTALL_HOST_DB_LOCALNAME', 'nom_serveur');
 
 /* 
 * Si le serveur n'est pas mysql, il faut le preciser obligatoirement.
 * # define ('_INSTALL_SERVER_DB', 'pg'); // mysql|pg|sqlite2|sqlite3
 * 
 * /!\ En PG, il est conseille d'utiliser la creation d'utilisateur SQL
 */
 
 /*
 * Creer automatiquement les users SQL (pg|mysql)
 * 
 * Cela permet 
 * - d'avoir un utilisateur root possedant les droits 
 * de creation de bases (cet utilisateur possedant obligatoirement 
 * une base a son nom en PG - PG ne se connecte pas sans donner un nom de bdd)
 * - de creer des utilisateurs sql automatiquement 
 * ne possedant que les droits d'administation 
 * de leur base de donnee qui sera creee
 * 
 * Il faut remplacer alors 
 * _INSTALL_(USER|PASS)_DB par _INSTALL_(USER|PASS)_DB_ROOT
 * 
 * et ajouter dans demarrer_site l'option
 * 'creer_user_base' => true
 */ 
 # define ('_INSTALL_USER_DB_ROOT', 'mon_root');
 # define ('_INSTALL_PASS_DB_ROOT', '********');
 
 /*
 * Creer les bases de donnees via un ping sur une URL (methode AlternC)
 *
 * Il suffit de renseigner l'option url_creer_base, en lui passant les bons parametres :
 * 'url_creer_base' => 'https://bureau.tld/admin/sql_doadd.php?username=USER&password=PASS&dbn='.prefixe_mutualisation($site)
 */
 
 
 /*
 * Transformer sur les pages publiques les url des images
 * /sites/mon_site/IMG/* -> /IMG/*
 * /sites/mon_site/local/* -> /local/*
 * 
 * - Necessite le mod_rewrite (reecriture d'url) d'apache
 * - Ne fonctionne qu'avec des mutualisations de nom de domaine 
 * ('http_host' : http://mon_site_mutu.tld)
 * (donc pas avec une mutualisation de repertoire - http://site/mon_spip_mutu/)
 * 
 * et ajouter dans demarrer_site l'option
 * 'url_img_courtes' => true
 * 
 * Il est possible de regenerer les fichiers .htaccess 
 * crees automatiquement dans /IMG et /local
 * grace a ?var_mode=creer_htaccess_img
 * 
 */
 
 demarrer_site($site,
 array(
 'creer_site' => true, // Creer ou non le site s'il n'existe pas (defaut: false) 
 'creer_base' => true, // Creer ou non la base de donnee si elle n'existe pas (false) 
 'creer_user_base' => false, // Creer ou non un utilisateur pour la nouvelle base de donnee (false)
 'mail' => '', // Adresse mail pour recevoir un mail lors d'une creation de site mutualise ('') 
 'code' => 'ecureuil', // Code d'activation ('ecureuil') 
 'table_prefix' => false, // Definir automatiquement le prefixe de table (false) ... mettre true si tous les sites dans la meme base 
 'cookie_prefix' => true, // Definir automatiquement le prefixe de cookie (false)
 'repertoire' => 'sites', // Nom du repertoire contenant les sites mutualises ('sites')
 'url_img_courtes' => true, // Utiliser la redirection des URL d'images courtes dans la partie publique (false)
 // /!\ il faut qu'apache ait le droit d'ecrire dans les dossiers IMG/ et local/ a la racine du site !
 // C'est la que la mutualisation va ecrire les regles de redirection automatiques pour les images de chaque site
 # 'utiliser_panel' => false, // Utiliser une table externe pour recuperer des identifiants ... (code, user, pass) permettant a un utilisateur d'installer le site (false) 
 # 'annonce' => 'Un service proposé par la communauté SPIP
', // Texte a afficher en bas du formulaire d'activation de la mutualisation
 'url_creer_base' => '' // Creer la base de donnees via une URL (methode AlternC)
 )
 );
 /*
 * Notes concernant SQLite
 * 
 * 1) creer_base = false
 * Avec SQLite, il est inutile de mettre creer_base a true.
 * Si creer_base est true, une base sera cree (par l'outil de mutualisation)
 * dans le repertoire defini par la constante _DIR_DB.
 * 
 * Si cette constante n'est pas renseignee, elle vaudra
 * _DIR_ETC/bases/ soit : config/bases/, ce qui ne correspond pas
 * a l'emplacement du futur site : sites/X/config/bases.
 * 
 * En laissant l'option a false, SPIP creera la base de donnee
 * au moment de l'installation (exec=install) et a ce moment
 * la, _DIR_ETC vaudra 'sites/X/config' donc la base sera stockee
 * ou il faut si _DIR_DB n'est pas defini.
 * 
 * 2) creer_user_base = false
 * SQLite ne gerant pas de droits d'utilisateurs,
 * (les droits sont ceux du fichier .sqlite)
 * mettre true provoquera des erreurs (je suppose)
 * 
 * 3) constantes a definir :
 * define ('_INSTALL_SERVER_DB', 'sqlite3'); // sqlite2 ou sqlite3
 * define ('_INSTALL_NAME_DB', 'mu_'.prefixe_mutualisation($site));
 * 
 * les constantes _INSTALL_(HOST|PASS|USER)_DB sont inutiles.
 */
 
 /*
 * Notes concernant MySQL
 * 
 * - Pour la creation d'utilisateurs MYSQL
 * (creer_base+creer_user_base)
 * il est possible de definir les droits de ces utilisateurs avec la constante 
 * _PRIVILEGES_MYSQL_USER_BASE (ici avec les valeurs utilisees par defaut) :
 * 
 * define('_PRIVILEGES_MYSQL_USER_BASE','Alter, Select, Insert, Update, Delete, Create, Drop');
 *
 */
?>
 Télécharger
Les lignes à changer sont les lignes en mettant 44 et 45 :
 define ('_INSTALL_USER_DB', 'root'); 
 define ('_INSTALL_PASS_DB', 'root');
 Télécharger
Il nous reste ensuite à créer un répertoire sites :
mkdir sites
Affinage
Comme je suis sur un site local, donc de dev, je ne veux pas de cache. Je met donc dans le fichier mes_options.php la ligne suivante :
define('_NO_CACHE',-1);
Dans le dossier extensions, je peux mettre tout les plugins que je souhaite actifs automatiquement pour l'ensemble des sites. Dans le dossier plugins, je met les plugins qui ne sont pas automatiquement actif.
Répétition pour les autres versions de SPIP
Il me faut installer la mutualisation dans chaque dossier correspondant à chaque version de SPIP.
Installation et Configuration de Mamp
Tout d'abord, vérifier dans les Préférences Système que le partage web n'est pas activé.
Puis télécharger MAMP et l'installer.
 Ouvrir MAMP dans le dossier MAMP du dossier Application.
 Dans les réglages, aller dans ports, et mettre le port Apache sur 80.
 Ensuite comme je ne désire pas renvoyer mes sites systématiquement vers le même dossier, il va falloir faire une intervention à la main dans les fichiers de MAMP.
 Ouvrir le dossier /Applications/MAMP/conf/Apache et faire une copie de sécurité du fichier httpd.conf.
 Puis l'ouvrir avec un éditeur de texte.
 Chercher les lignes où il est écrit :
# MAMP DOCUMENT_ROOT !! Don't remove this line !!

DocumentRoot "/Applications/MAMP/htdocs"
Et faire exactement ce qu'il est dit de ne pas faire, en remplacant DocumentRoot "/Applications/MAMP/htdocs" par Include /Applications/MAMP/conf/Apache/vhost.conf
 Par cela, je signale que je veux que la gestion des dossiers se fasse dans un fichier vhost.conf du dossier /Applications/MAMP/conf/Apache/.
 Je crée ce fichier. Voici ce que j'y met :


DocumentRoot "/Users/maieul/Sites/SPIP21"

 
Évidemment, il faut remplacer maieul par le nom de votre dossier de départ.
 Cela indique que par défaut, mes sites locaux correspondent au dossier /Users/maieul/Sites/SPIP21 de mon ordinateur. Donc mes sites sont créés par défaut avec SPIP 2.1
 En revanche, si je souhaite que le site toto.dev soit en SPIP 2.0, je met en dessous de ces lignes :


DocumentRoot "/Users/maieul/Sites/SPIP20"

ServerName toto.dev


Et ainsi de suite pour chaque site ne fonctionnant pas avec SPIP 2.1.
Rediriger le site bidule.dev vers 127.0.0.1
Bon, maintenant je peux lancer mon site bidule.dev
Pour ce faire, je vais modifier le fichier /etc/hosts, qui indique les redirections des adresses web, propres à mon ordinateur.
Pour ce faire, dans le terminal je frappe :
sudo pico /etc/hosts
Après la saisie de mon mot de passe administrateur, avec le clavier je me rend sur juste avant la ligne 255.255.255.255 broadcasthost, et j'insére la ligne suivante :
127.0.0.1 toto.dev
J'enregistre en frappant ctrl + X
À chaque fois que je voudrais créer un nouveau site local, je ferais de même.
Lancement du site
Aller, on y va ! Dans la barre d'adresse du navigateur, j'écris http://toto.dev.
 Je me retrouve alors sur la page me demandant le mot de passe de la mutualisation.
 Comme je ne l'ai pas modifié, c'est facile : ecureuil. Je le rentre donc, et je clique sur ok.
 Je passe ensuite les étapes suivantes, qui sont automatiques.
 












 Vient ensuite l'habituel formulaire de création des comptes sur SPIP, que je remplis comme d'habitude :
 
 Et voilà mon site lancé.
 

Particularité de la mutualisation
Chaque sites possèdent un dossier propre dans le dossier sites. Dans chaque dossier de sites se trouvent les habituelles dossiers config ; IMG ; local ;tmp et éventuellement squelettes.
Mise à jour mineure de SPIP
Imaginons que la version 2.1.13 de SPIP sorte.
 Pour faire ma mise à jour en local, c'est simple.
 1. D'abord se rendre dans le dossier avec le terminal
cd ~/sites/SPIP21
2. Ensuite mettre à jour
svn switch svn://trac.rezo.net/spip/tags/spip-2.1.12 
		
		
[1] Je sais, c'est un peu narcissique, mais que voulez-vous…

		Comme d'habitude, j'attends les réactions des SPIPeurs.
 Voici quelques liens utiles :

 initiation au terminal

 le fichier hosts

 la mutualisation facile avec SPIP

 les Virtualhost d'Apache

 Deux articles d'Alexandra qui expliquent comment ouvrir sur l'exterieur son Mac et comment envoyer des mails avec SPIP en local 
 La même problématique, mais sous Windows.


Sept bonnes pratiques de développement avec SPIP
2012-01-05T00:39:57Z
Je travaille en ce moment sur un squelette qui n'est pas de moi. Il semble que la personne qui l'a créé n'était pas au courant des bonnes pratiques de développement sous SPIP. Il est vrai que ces bonnes pratiques ne sont pas nécessairement accessibles aux premiers abords de la documentation webmaster de SPIP.
 Voici sept règles que je juge indispensables
		1. Ne pas mettre de PHP dans les squelettes
Le but de SPIP était de permettre de ne pas avoir à connaître le PHP pour concevoir un site. Tout un système spécifique a été prévu, pour faire des requêtes SQL, mais aussi des tests. C'est parfois perturbant pour les utilisateurs venant du monde PHP.
 Mais pour autant, c'est une très bonne pratique de ne jamais mettre de PHP dans un squelette. En réalité, c'est une mauvaise pratique d'en mettre.
2. Ne rien mettre dans le dossier IMG
Le dossier IMG ne doit contenir que les images et documents ajoutés par l'utilisateur depuis l'interface privé. En aucun cas il ne doit contenir des images propres aux squelettes, qui doivent se trouver dans le même dossier que les squelettes.
 Choisir de mettre les images dans IMG (comme je l'ai vu dans ce squelette), c'est compliquer les réutilisations des squelettes, et mélanger les couches utilisateurs et webmestres de SPIP.
3. Utiliser #CHEMIN
La balise #CHEMIN est une balise indispensable de SPIP. Elle permet d'indiquer l'adresse d'un fichier sans se préoccuper du nom du dossier parent. En effet, SPIP va cherche le fichier passé en argument dans l'ordre suivant [1] :
  squelettes

 plugin B dépendant du plugin A

 plugin A

 squelettes-dist

 prive

 ecrire
 Exemple : j'ai une image dans le dossier squelettes, je ne fais pas :

mais bien
#CHEMIN{toto.png}' />
mieux, je met mon image toto.png dans le dossier img du dossier squelettes.
 Je peux alors faire :
#CHEMIN{img/toto.png}' />
L'avantage d'un tel système est évident : permettre d'avoir un dossier squelettes qui ne s'appelle pas squelettes, par exemple lorsqu'on utilise ma sixième recommandation : les squelettes sous forme de plugins. Mais aussi permettre à SPIP de gérer correctement les URLS arborescentes (le cas échéant).
4. Utiliser |balise_img
Il est recommandé lorsqu'on insère une balise  de lui mettre des attributs height et with pour améliorer les performances du navigateur lors de l'affichage de la page.
 On peut bien sûr indiquer cela manuellement :
#CHEMIN{toto.png}' width='largeur' height='hauteur' />
Mais supposons que je réduise la taille de toto.png : je dois dans ce cas modifier les attributs height et width à chaque fois que je l'utilise.
 Pour éviter cela, SPIP prévoit le filtre |balise_img qui, lorsqu'il est appliqué au chemin d'un fichier image, crée automatiquement la balise , avec la hauteur et la largeur du fichier. Ainsi, pas besoin de corriger si on réduit la taille du fichier.
 Le filtre s'utilise de manière très simple :
[(#CHEMIN{toto.png}|balise_img)]
On peut même mettre en argument le contenu de l'attribut alt
[(#CHEMIN{toto.png}|balise_img{0+0})]
Voir en deuxième argument la valeur de l'attribut class :
[(#CHEMIN{toto.png}|balise_img{0+0,blague_pour_enfants})]
Ce code au final me produit :
5. Utiliser les chaînes de langues
Bien que cela puisse paraître inutile et fastidieux pour un site monolingue, utiliser les chaînes de langue est quand même utile pour trois raisons :

 on ne sait jamais : si le site devient multilingue, c'est toujours cela de fait.

 il est plus facile d'uniformiser les textes.

 il est plus facile de corriger en cas de faute ou de changement d'avis.
6. Utiliser 
C'est un principe de base de l'informatique : dès qu'une séquence d'instructions est utilisée plusieurs fois, il faut non pas la dupliquer, mais la mettre dans un morceau qu'on appelle plusieurs fois.
 En SPIP ce morceau, c'est un fichier inclus.
 Typiquement supposons que j'affiche sur toutes les pages de mon site les sites amis.
 Au lieux de copier-coller le code suivant dans les squelettes :




(SITES){par titre}>
 #NOM






 Télécharger
Je le met dans un fichier sites-amis.html, situé dans un dossier inclure du dossier contenant les squelettes.
 Et je met le code suivant là où je souhaite afficher les sites amis :
{fond=inclure/sites-amis}>
Cela me permet si je dois modifier les critères de cette liste de ne les modifier qu'à un endroit [2].
 La logique est donc : diviser son site en briques réutilisables. Chaque brique correspondant à fichier et à un morceau logique de page. Ensuite assembler ces briques dans des fichiers plus globaux [3].
 Le modèle de squelettes Z pousse à l'extrême cette logique des inclusions. Je conseille de le suivre : on gagne largement en maintenance ce qu'on perd en temps d'apprentissage initial.
 Une règle importante dans les inclusions : les balises html qui s'ouvrent dans un fichier doivent se fermer dans le même fichier. Il est très mauvais d'ouvrir une balise dans un fichier puis de la fermer dans un autre : on y est perd en lisibilité du code, et donc en maintenance [4].
 
7. Mettre ses squelettes sous formes de plugins
Cela peut paraître un luxe ou coquetterie, mais cela facilite énormément le déploiement d'un même squelette sur plusieurs sites ou le déménagement depuis la version locale vers la version en ligne :

 en indiquant les dépendances aux plugins.

 en incluant le fichier mes_options.php dans le même dossier.

 en permettant même le cas échéant d'ajouter automatiquement un contenu pré-défini.
 Un précédent article détaille comment fabriquer ces squelettes-plugins.
		
		
[1] Liste tirée du site Programmer avec SPIP.

[2] En outre, cela diminue les requêtes SQL et donc la charge du serveur SQL, mais la contrepartie est de multiplier les fichiers de caches ainsi que les inclusions PHP.

[3] Pour comprendre comment passer des paramètres lors de ces inclusions, pour par exemple connaître l'article courant, je renvoie à mon article sur la balise #ENV. Cet article devrais être mis à jour pour parler des dernières nouveautés. Mais l'essentiel est là.

[4] J'ai crû à un moment qu'une structure html était incorrecte du fait qu'un fichier avait plus de 
 ouvrantes que fermantes. En réalité, le dernier 
 manquant se trouvait ailleurs.

		Amis SPIPeurs, j'attends vos remarques et ajouts !


Archivage avec redirection
2011-06-24T13:15:24Z
Sur ce site, certains articles sont considérés comme « obsolètes » parce que j'ai trouvé une meilleure méthode pour obtenir le même résultat.
 Je souhaitais que google n'indexe plus ces articles, mais soit redirigé vers leurs remplaçants respectifs. En même temps, je souhaitais qu'une personne qui s'amuse à fouiller dans les archives de ce site puisse le cas échéant retrouver l'article.
 Voici la manière dont j'ai procédé. Je remercie xdjuj pour m'avoir fourni l'idée de départ.
		Principe
Pour arriver à mes fins, j'utilise le plugin A2A qui me permet d'indiquer quel est l'article remplaçant d'un article obsolète.
 En interne, les liens vers les articles archivés portent la variable GET archive=oui. Par exemple Un index des sources primaires (1).
 Si une personne arrive sur une page archivée sans passer la variable archive=oui alors elle est redirigée vers la nouvelle version, par une redirection HTTP 301 (redirection permanente).
 En revanche si la variable est passée, il reste sur cette page, mais celle-ci possède une meta-donnée qui indique de ne pas l'indexer.
 Ceci permet donc d'accéder aux archives du site via la navigation interne de ce site, tout en réorientant les liens externes, dont ceux des moteurs de recherches.
La méthode : la modification des liens
Il existe deux types de liens internes pointant éventuellement vers des archives : ceux générés avec #URL_ARTICLE dans un squelette et ceux générés avec des raccourcis de la forme [texte->xx] ou [texte->artxx] ou [texte->articlexx], dans le texte d'un article.
 Comment faire pour ajouter des arguments à ces liens seulement si l'article de destination est un article « obsolète » ?
 Dans les squelettes
 Pour les liens dans les squelettes, c'est relativement simple :
 [(#URL_ARTICLE|parametre_url{archive,oui})] me rajoute ma variable. Sauf que cela le fait sur tous les articles.
 Il va donc falloir conditionner. Pour ce faire je crée un squelette inclure/obsolete.html. Celui-ci renvoie 1 si un article est lié à l'article passé en argument, donc si cet article est « obsolète ». Il ne renvoie rien dans le cas contraire.
 Voici le code de ce squelette
(ARTICLES_LIES){id_article}{par rang}{0,1}>1
Je remplace dans mes squelettes toutes les références à #URL_ARTICLE par :
[(#INCLURE{fond=inclure/obsolete}{id_article}|?{#URL_ARTICLE|parametre_url{archive,oui},#URL_ARTICLE})]
Ce qui en gros veut dire : on utilise le squelette inclure/obsolete en lui donnant l'id_article courant comme valeur. Si ce squelette retourne quelque chose, alors on renvoie #URL_ARTICLE|parametre_url{archive,oui}, sinon on renvoie simplement #URL_ARTICLE.
 À noter qu'ici je filtre un squelette appelé via #INCLURE, ce que je ne peux faire avec .
 Pour les raccourcis typographiques
 Il faut qu'avant que SPIP interprète les raccourcis typographique, je modifie, si cela est pertinent, les formes [texte->artxx] par [texte->artxx?archive=oui]. SPIP s'occupera ensuite de la question des urls propres.
 Pour faire cela, j'utilise la pipeline pre_liens, que je déclare dans mon fichier plugin.xml
>
 >pre_liens>
 >geek_maieul.php>

>
 Télécharger
Sur la pipeline pre_liens, je renvoie à l'article de Marcimat.
 Je la déclare dans mon fichier geek_maieul.php.
function geek_maieul_pre_liens($texte){
 $match = array();
 if (!preg_match("#->(?:art)?(?:article)?([0-9]+)\]#",$texte,$match)){ //trouer les liens vers les articles, sans rien derrière
 return $texte;
 }
 
 $obsolete = sql_getfetsel('id_article_lie','spip_articles_lies','id_article='.$match[1]); // y a-t-il un article lié ?
 if ($obsolete){
 $texte = str_replace($match[1].']',$match[1].'?archive=oui]',$texte); // on 
 }
 return $texte;
 
}
 Télécharger
Commentaires :

 ligne 1 : nom de la fonction / pipeline.

 ligne 2 à 5 : je teste si mon lien interne est bien un lien de type article. Si jamais ce n'est pas le cas, je ne modifie rien et renvoie le lien comme il était avant. Sinon je stocke le numéro de l'article dans le tableau $match, dans l'entrée 1. Pour ce faire, j'utilise une expression régulière.

 ligne 7 : je regarde si mon article a un article lié. J'utilise pour cela la fonction de SPIP sql_getfetsel()

 ligne 8 et 9 : si mon article a un article lié, je modifie le lien, en ajoutant ?archive=oui.

 ligne 11 : je renvoie le tout.
Redirection
Dans mon fichier article.html, je teste si mon article a un article lié, et si c'est le cas, j'appelle filtre sur l'URL de l'article lié :
(ARTICLES_LIES){id_article}{par rang}{0,1}>

[(#URL_ARTICLE{#ID_ARTICLE_LIE}|redirect301)]

 Télécharger
Le filtre |redirect301 est écrit par moi. C'est une fonction php relativement simple
function redirect301($url){
 if (_request('archive')!='oui'){
 header("Status: 301 Moved Permanently", false, 301);
 header("Location:$url");
 exit(); 
 }

}
 Télécharger
Avant de faire une redirection, je vérifie que je n'ai pas la valeur archive=oui passée dans l'url [1]
 Si c'est le cas, je procède à la redirection.
Méta donnée pour indiquer de ne pas indexer
Dans l'entête de mon squelette d'article, je met
[(#INCLURE{fond=inclure/obsolete}{id_article}|oui)]
.
 Ce qui a pour conséquent de placer la balise  si mon article est obsolète, afin que les moteurs de recherches ne l'indexent plus.
		
		
[1] J'utilise la fonction SPIP _request().

		Il est évident que si je fais pointer l'article A vers l'article B et l'article B vers l'article A je risque d'avoir des problèmes de renvois mutuels. Mais comme je suis le seul rédacteur sur ce site, le risque est minimum.


Vous pouvez utiliser (C)Keditor
2011-02-20T12:50:17Z
Il y a quelque temps, j'avais posté un message extrêmement critique vis à vis de de (F)CKeditor. Je révise ici mon jugement, suite au dernier article publié sur Contrib.
		Je continue à penser que (F)Ckeditor est une mauvaise idée parce qu'il incite à penser forme et non sens. Je continuer à penser que l'apprentissage des raccourcis typographiques de SPIP a plus de sens, même si cela peut prendre un peu plus de temps (et encore).
 Pour autant, la dernière contribution enlève une de mes critiques majeures, en fait ma critique majeure, à savoir que (F)Ckeditor produit du HTML et non pas du code SPIP.
 En effet, il est désormais possible de dire à (F)Ckeditor de produire du SPIP et non pas du HTML.
Ce qui à l'avantage :

 de permettre une conversion plus simple vers d'autres formats.

 de permettre de se passer de CKeditor le cas échéant.

 de pouvoir utiliser les crayons.
		Je n'ai pas testé, mais je fais confiance à l'auteur de l'article. Reste à savoir comment nettoyer une base qui a été salie par les anciennes versions du plugin.


Site internet : attention aux arnaques !
2011-02-05T10:36:29Z
Beaucoup de boîtes vendent des sites internet en utilisant des méthodes commerciales plus que douteuses. Cela s'appelle de l'arnaque. Extrait
		

Service maximum proposition site internet "gratuit"
envoyé par adcapi. - L'info video en direct.
 Voici quelques règles de base pour ne pas se faire avoir :
 Se méfier des « partenariats » : un site internet prend du temps à être développé, ce n'est pas un partenariat, mais une vente.
 Regarder si la boîte vend un site qui utilise un produit connu (type SPIP, Joomla, Drupal). Demander la solution logicielle retenue. Si c'est une solution « maison », méfiance : vous deviendrez dépendant de la boîte. Si c'est une solution non-maison, un produit connu, passer sur les réseaux de la communautés, et demander si la boîte y est impliquée. Par exemple, vous pourrez savoir que je suis impliqué dans la communauté SPIP, ce qui garanti en général une certaine déontologie.
 Bien vérifier que les interventions de contenu sur le site sont entre vos mains. Il n'y a pas à passer par une agence pour modifier le titre d'une page, un texte, une photo.
 Surtout, ne pas utiliser un paiement par mois. Il faut un prix annoncé « brut », éventuellement payable en plusieurs mensualités. Mais pas un site à xxx euros par mois : cela revient à avoir une location, donc à ne pas être propriétaire du site.
 S'assurer que l'hébergeur (la personne qui stocke le site sur internet) ne soit pas la même société que celle qui conçoit. Si c'est le concepteur qui paie l'hébergeur pour vous, demander à avoir un certificat que vous êtes bien en réalité le client.
		Je rappelle que je vends moi même des sites internet.

Geekographie Maïeulesque

Succession d'articles avec A2A

Configuration du plugin

Côté squelettes

Jouons un peu avec |image_masque

Principe

Mise en œuvre

Gérer le statut des articles directement depuis le site public sous SPIP 3

Jeux de squelettes sous forme de plugin pour SPIP 3

Le fichier de langue

Et le fichier options.php ?

Vérifier son paquet.xml

Les différents modes d'inclusion de SPIP

Rappel : principe de l'inclusion

ou #INCLURE ?

Conséquences techniques

Et #MODELE

Gérer beaucoup de sites SPIP en local sous MacOsX

Principe

Préparer les versions de SPIP

Préparer la mutualisation

Affinage

Répétition pour les autres versions de SPIP

Installation et Configuration de Mamp

Rediriger le site bidule.dev vers 127.0.0.1

Lancement du site

Particularité de la mutualisation

Mise à jour mineure de SPIP

Sept bonnes pratiques de développement avec SPIP

1. Ne pas mettre de PHP dans les squelettes

2. Ne rien mettre dans le dossier IMG

3. Utiliser #CHEMIN

4. Utiliser |balise_img

5. Utiliser les chaînes de langues

6. Utiliser

7. Mettre ses squelettes sous formes de plugins

Archivage avec redirection

Principe

La méthode : la modification des liens

Redirection

Méta donnée pour indiquer de ne pas indexer

Vous pouvez utiliser (C)Keditor

Site internet : attention aux arnaques !

Et le fichier `options.php` ?

ou `#INCLURE` ?

`Et #MODELE`

3. Utiliser `#CHEMIN`

4. Utiliser `|balise_img`