Sept bonnes pratiques de développement avec SPIP

jeudi 5 janvier 2012, mise à jour lundi 9 février 2015, par Maïeul
Suivre la vie du site RSS 2.0 Forum

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 quasiment-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 :

<img src='squelettes/toto.png' />

mais bien

<img src='#CHEMIN{toto.png}' />

mieux, je met mon image toto.png dans le dossier img du dossier squelettes.

Je peux alors faire :

<img src='#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 <img> 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 :

<img src='#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 <img>, 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 :

<img src='squelettes/toto.png' width='largeur_du_fichier_toto.png' height='hauteur_du_fichier_toto.png' alt='0+0' class='blague_pour_enfants' />

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

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 :

<B>
<ul>
<BOUCLE_sites(SITES){par titre}>
    <li><a href='#URL_SITE'>#NOM</a></li>
</BOUCLE>
</ul>
</B>

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 :

<INCLURE{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.

P.-S.

Amis SPIPeurs, j’attends vos remarques et ajouts !

Notes

[2En 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.

[3Pour 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à.

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

Vos commentaires

  • Le 5 janvier 2012 à 04:45, par Pascal En réponse à : Sept bonnes pratiques de développement avec SPIP

    Bonjour,

    Article intéressant, c’est toujours bon un petit rappel et je découvre |balise_img . Merci

    Le lien « comment fabriquer ces squelettes-plugins » qui est http://geekographie.maieul.net/spip.php?page=article&id_article=136 ne fonctionne pas :-( et petite faute de frappe « ces » n’est-ce pas « ses »

    Mais j’ai quand même trouvé l’article

    Bonne journée

    Pascal

  • Le 5 janvier 2012 à 11:18, par Maïeul En réponse à : Sept bonnes pratiques de développement avec SPIP

    Merci,

    le lien est corrigé. Quant à la faute de frappe elle n’en est pas une je parle bien de squelettes-plugins dont je viens de parler, donc un démonstratif.

  • Le 6 janvier 2012 à 13:00, par Webgardener En réponse à : Sept bonnes pratiques de développement avec SPIP

    Merci pour ces petits rappels... Comme Pascal je découvre le filtre balise_img

  • Le 6 janvier 2012 à 13:56, par Loiseau2nuit En réponse à : Sept bonnes pratiques de développement avec SPIP

    Je m’inscris en faux sur la reco n°4 : c’est un suicide à performance, en dehors du fait que c’est une pratique dépréciée selon le W3C.

    Les meilleures manières de faire un redimensionnement d’image avec SPIP, à ce jour :

    • soit directement en CSS .spip_logos {width:123px; height:456px;} pour rester dans la pratique ’standard’, même si celle ci n’apporte pas grand chose en terme de perfs si l’image de base fait genre 6000px par 3200px
    • soit |image_reduire{123,456} (à laquelle je vais personnellement préférer |image_recadre{123,456,centrer} pour mettre en valeur une zone spécifique de la photo et générer des vignettes plus sympas.) J’avoue que cette approche est plus lourde à la 1re compilation de la page mais une fois le résultat image mis en cache, la charge est normale et l’image réellement optimisée et dimensionnée comme il faut !

    Et bonne année à toi :-)

  • Le 6 janvier 2012 à 14:28, par Maïeul En réponse à : Sept bonnes pratiques de développement avec SPIP

    heu un image_reduire ou une balise_img ca te pompe les images et regarde la taille, donc en terme de perfomance c’est la même chose.

    En l’occurence balise_img ce n’est pas pour les logo dynamique ... mais vraiment pour des images de deco secondaire. Donc le redimensionnement se fait un fois directement dans le fichier et basta.

    Tu a une ref sur la depreciation des attributs width et height ?

    et bonne année à toi aussi :)

  • Le 6 janvier 2012 à 17:52, par tetue En réponse à : Sept bonnes pratiques de développement avec SPIP

    Chouette ton article, merci pour ces rappels !

    D’accord avec Loiseau2nuit, et même plus : soit l’image est décorative et donc appliquée via CSS, soit elle est informative et donc appelée dans les squelettes et éditable, c’est-à-dire via boucle DOCUMENTS ou #LOGO_...SPIP génère les attributs adéquats sans devoir s’embêter avec ce drôle de filtre |balise_img :)

    Un bémol sur le point 6 où tu recommande de faire des <INCLURE> alors qu’il y a aussi les #INCLURE et #MODELE qui sont parfois préférables (mais j’oublie toujours quand il vaut mieux utiliser lequel).

    Et pas d’accord avec le point 7, qui présuppose de savoir s’y repérer dans les priorités d’application des plugins. Sur un site perso, le dossier « squelettes » reste le plus indiqué : c’est LE dossier où placer ses personnalisations, qu’il s’agisse de squelettes, de style, de fonctions, de script, etc. car c’est ce qui est dans ce dossier qui aura le dernier mot : y placer ses personnalisations est la meilleure façon de s’assurer qu’elles soient prises en compte dans tous les cas.

  • Le 6 janvier 2012 à 18:18, par Maïeul En réponse à : Sept bonnes pratiques de développement avec SPIP

    il y a parfois des images décoratives qu’on n’arrive pas à placer en css, même si effectivement cela devient plus rare. Par exemple les images de type « lien RSS », ou « Creatives Commons » (ceci dit tu verra que sur ce site je n’utilise pas |balise_img car je viens aussi de le découvrir).

    Mon article était plus sur les orientations SPIP que sur la différence CSS / HTML. Il présuppose que le lecteur sait dans quel cas mettre une image en css et dans quel cas la mettre en html.

    oui tout a fait pour le point 6. Mais l’idée était le principe d’inclusion plutôt que le INCLURE en lui même. Pour moi #MODELE ne devrait s’utiliser que si on envisage que le rédacteur se serve du modèle en question. En revanche #INCLURE et <INCLURE> il y a des subtilités au niveau du cache :

    • #INCLURE n’a pas de cache spécifique, mais est stocké dans le cache du fichier parents. C’est comme si tu avais fait un copier-coller.
    • <INCLURE> a un cache spécifique.

    A toi de voir du coup ce qui est le plus optimal.

    Le dossier squelettes ca se discute. Perso le fait d’avoir pris cette technique m’a sacrément simplifié la vie pour m’assurer de n’oublier aucun plugin (j’indique les dépendances) ni le fichier mes_options.php. Et avoir un squelette-plugin ca permet aussi pour des structures qui possède des sous-sites d’avoir un gabarit commun à tout les sites, avec des modifs pour chaque sous-sites dans squelettes.

  • Le 6 janvier 2012 à 18:44, par Loiseau2nuit En réponse à : Sept bonnes pratiques de développement avec SPIP

    Là pour le coup, squelettes en plugins, j’abonde assez dans le sens de Maieul.

    J’ajoute même un avantage à ceux qu’il a cité : la possibilité d’injecter ses scripts dans #INSERT_HEAD et de leur faire ainsi bénéficier du compacteur.

    Loiseau2nuit, pas aussi intégriste de la perfo web que Cerdic mais quand même... ^^

  • Le 6 janvier 2012 à 18:46, par Loiseau2nuit En réponse à : Sept bonnes pratiques de développement avec SPIP

    il y a parfois des images décoratives qu’on n’arrive pas à placer en css, même si effectivement cela devient plus rare. Par exemple les images de type « lien RSS », ou « Creatives Commons »

    Comment ça ? oO

  • Le 7 janvier 2012 à 00:23, par Maïeul En réponse à : Sept bonnes pratiques de développement avec SPIP

    @loiseaudenuit : regarde le pied de page de mon site, le logo CC.

  • Le 7 janvier 2012 à 00:33, par Maïeul En réponse à : Sept bonnes pratiques de développement avec SPIP

    @loiseau de nuit : le compacteur marche même sans passer par insert_head. C’est de l’affichage_final il me semble...

  • Le 7 janvier 2012 à 00:33, par Loiseau2nuit En réponse à : Sept bonnes pratiques de développement avec SPIP

    ouais... beh celui ci sincèrement je l’aurais placé en css sans aucune espèce de remords ou de complication. Il était où ton soucis ?

  • Le 7 janvier 2012 à 00:35, par Loiseau2nuit En réponse à : Sept bonnes pratiques de développement avec SPIP

    @loiseau de nuit : le compacteur marche même sans passer par insert_head. C’est de l’affichage_final il me semble...

    ah... bah là il me manque peut être une donnée. tu peux clarifier ?

  • Le 7 janvier 2012 à 00:44, par Maïeul En réponse à : Sept bonnes pratiques de développement avec SPIP

    pour le post 12 : bah en fait cela porte du sens, mais ce sens n’a pas à être changé par l’utilisateur. C’est la règle générale des post de ce sites : licence CC. Donc pas du dynamique, mais en même tps une image porteuse de sens, donc avec attribut alt et tutti quanti.

    pour le post 13 : typiquement sur ce site je met mes css sans passer par #INSERT_HEAD et ils sont biens compactés. Parceque le compactage se fait via l’appel à pipeline |affichage_final.

  • Le 10 janvier 2012 à 00:51, par pascal weber En réponse à : Sept bonnes pratiques de développement avec SPIP

    D’accord avec Romy sur les modèles : des briques très puissantes. En les utilisant conjointement avec le noisetier, les compositions et le plugin insérer modèle on peut fabriquer une interface qui offre aux utilisateurs et administrateurs d’un site une gamme d’outils extrêmement poussée en leur donnant la main sur absolument presque tout, tout en simplifiant la maintenance et en assurant la propreté du code ainsi que la cohérence du graphisme. Effectivement je me souviens avoir vu passer un article sur les différences de performance et de cache entre <INCLURE> / #INCLURE  ou <MODELE> / #MODELE etc et ça serait pas mal d’avoir un petit mémo sur le sujet quelque part dans la doc officielle car les subtilités de tout ça ne sont pas bien claires.

  • Le 11 janvier 2012 à 18:10, par gontran En réponse à : Sept bonnes pratiques de développement avec SPIP

    Et bien entendu la règle zéro : « Essayer de ne pas utiliser Spip. »

  • Le 11 janvier 2012 à 19:22, par Loiseau2nuit En réponse à : Sept bonnes pratiques de développement avec SPIP

    Tiens ? *EyesToTop* Je ne me demande même pas d’où peut venir mon voisin du dessus, qui semble manifestement oublier la règle 0.1 : essyer d’être intelligent avant de parler...

  • Le 14 janvier 2012 à 02:38, par Valéry En réponse à : Sept bonnes pratiques de développement avec SPIP

    J’aurais tendance à ajouter à la liste l’utilisation des balises #URL_ARTICLE, #URL_PAGE, etc. pour générer des liens internes, ce qui permet aux squelettes de rester compatible avec les versions futures de SPIP. J’ai souvent vu écrire des choses du type /spip.php ?page=foo&id_article=#ID_ARTICLE

  • Le 14 janvier 2012 à 02:56, par Loiseau2nuit En réponse à : Sept bonnes pratiques de développement avec SPIP

    Je dirais même plus : [(#URL_ARTICLE|url_absolue)]

  • Le 14 janvier 2012 à 12:51, par Maïeul En réponse à : Sept bonnes pratiques de développement avec SPIP

    Autant je suis d’accord pour #URL_ARTICLE (cela a été l’une des mes premières découvertes dans SPIP : voir l’interview, qui remonte.)

    autant il ne me semble pas bon sur une page HTML d’avoir des URLs absolues (donc je te contredis Loiseaudenuit).

  • Le 14 janvier 2012 à 13:41, par Loiseau2nuit En réponse à : Sept bonnes pratiques de développement avec SPIP

    Ah bah là désolé, d’habitude je veux bien écouter les gens même quand ils me contredisent mais là, sur ce point précis ce sont mes résultats en référencement qui parlent, et continueront de parler ^^

  • Le 14 janvier 2012 à 13:47, par Maïeul En réponse à : Sept bonnes pratiques de développement avec SPIP

    t’a une étude statistiques avant/après ? Ou une étude à l’appui ?

    La logique du html c’est qu’un lien dans le même site est relatif.

    Et puis sinon faut automatiser l’application du filtre dans mes_options.php

  • Le 14 janvier 2012 à 14:11, par Loiseau2nuit En réponse à : Sept bonnes pratiques de développement avec SPIP

    etude statistique non pas à proprement parler. Juste une conviction basée sur la rapidité d’indexation et/ou de ré-indexation des pages interieures de certains sites après application du filtre.

  • Le 14 janvier 2012 à 14:12, par Loiseau2nuit En réponse à : Sept bonnes pratiques de développement avec SPIP

    C’est que pépère google il est un peu « teubé » ! Il comprend vite mais souvent faut lui expliquer longtemps ^^

  • Le 14 janvier 2012 à 14:36, par Felipe En réponse à : Sept bonnes pratiques de développement avec SPIP

    @loiseaudenuit #12 : toutes les images d’une charte graphique ne sont pas décoratives (la licence dont parle Maïeul en est un excellent exemple, idem pour le logo SPIP au début du footer) et toutes les images de contenu ne sont pas informatives.

    Quand un lien n’est constitué que d’une image, on ne doit PAS utiliser une image de fond (et en général du remplacement d’image par positionnement hors écran - texte masqué en CSS - parce que sans ça le lien vide c’est vraiment de l’intégration de goret qui en plus pénalise le SEO). Ce pour des raisons d’accessibilité : si on désactive les images mais laisse activé CSS, il n’y a plus rien à l’écran. Hautement pénalisant pour le logo du site/de la société lorsqu’il est aussi un lien voire un titre de niveau 1.

    Les choix image de fond/image de contenu, image de contenu avec alt vide ou renseigné se font toujours en fonction du contexte ; il n’y a pas de règle unique marchant à tous les coups.

  • Le 14 janvier 2012 à 16:10, par pascal weber En réponse à : Sept bonnes pratiques de développement avec SPIP

    @loiseaudenuit @Felipe : Non les gars ! Vous aviez promis « Pas de bagarre » et « Pas les mères » ;-) Ceci dit j’ai moi aussi suivi les astuces de Cederholm de remplacement d’image en CSS à la mode il y a quelques années mais comme l’indique Felipe, ça ne résiste pas à un test basique d’accessibilité : désactiver l’affichage des images dans le navigateur. Ca semblait malin et ça avait un côté « moi je suis un pro du CSS » assez séduisant... Mais c’était une idiotie. Le contenu doit se trouver dans le contenu (ce qui n’est finalement pas bête quand on y pense ;-)

  • Le 14 janvier 2012 à 16:20, par Loiseau2nuit En réponse à : Sept bonnes pratiques de développement avec SPIP

    @loiseaudenuit @Felipe : Non les gars ! Vous aviez promis « Pas de bagarre » et « Pas les mères » ;-)

    Qu’est-ce que tu parles de ma Mère toi ! Et pis laisse nous nous fritter tranquille sinon on se met à 2 sur toi :D

    Blague à part, je suis assez d’accord avec Felipe effectivement pour des images comme celles ci ok. Bon après, pour ce qui est de pénaliser le SEO, un positionnement hors page ne pénalise en rien (et là dessus je suis sûr de mon coup, j’ai fait les tests qu’il fallait pour. Faut juste effectivement bien positionner hors page et bannir à tout prix le display:none ; ou le visibility:hidden ; Sorti de là, on peut y aller tant que, comme tout, on en abuse pas !)

  • Le 14 janvier 2012 à 16:34, par Maïeul En réponse à : Sept bonnes pratiques de développement avec SPIP

    @loiseaudenuit : donc dans ce cas un |balise_img peut se justifier n’est-ce pas :- ;

  • Le 14 janvier 2012 à 16:40, par pascal weber En réponse à : Sept bonnes pratiques de développement avec SPIP

    @Loiseau2nuit @Felipe #27

    Effectivement côté SEO je ne vois pas non plus le problème puisque le positionnement CSS d’un élément n’entre pas en ligne de compte me semble-t-il.

    C’est simplement qu’une image CSS n’a pas d’alternative textuelle. On n’y met donc que ce qui est purement décoratif. Dans le cas d’une image qui est un lien, donc du contenu, il est préférable de mettre l’image dans le contenu en renseignant bien le alt pour permettre à l’utilisateur d’avoir un texte sur lequel cliquer dans le cas où il a désactivé les images.

    Si on veut jouer au malin (ce qui à mon sens n’est que de l’autosatisfaction - mais il en faut aussi) et remplacer un élément de texte du contenu par une image sans mettre tout bêtement cette image dans le contenu (pourquoi faire simple ?) c’est peut-être plus côté javascript qu’existe une solution acceptable ?

  • Le 14 janvier 2012 à 16:44, par Loiseau2nuit En réponse à : Sept bonnes pratiques de développement avec SPIP

    @Maieul : toi, je sens bien qu’tu m’cherches ! Viens d’vant l’saloon au coucher du soleil avec tes schtroumphs si t’es pas un pied tendre ! :D

    @Mandibul : je pense oui, ceci dit ca serait vraiment capilo tracté comme approche je pense. (ce qui me fait penser à ce plugin spip qui convertissait automatiquement toute adresse email écrite en clair dans un contenu, par une image générée à la volée, pour éviter que l’adresse soit aspirée par les bots...capilo tracté mais efficace pour le coup ^^)

  • Le 14 janvier 2012 à 16:46, par Maïeul En réponse à : Sept bonnes pratiques de développement avec SPIP

    franchement quand on est malin on évite de mettre du javascript pour des choses que le html fait correctement :)

  • Le 14 janvier 2012 à 16:50, par Comm2Presse En réponse à : Sept bonnes pratiques de développement avec SPIP

    Entre nous, SPIP c’est pas un peu Has Been User ? Certes, je suis un Yacs user mais toujours impressionné par Wordpress... Mais comme quoi, si y’en a qui persévère avec SPIP c’est que ça doit valoir le coup quand même non ? :)

  • Le 14 janvier 2012 à 16:55, par Maïeul En réponse à : Sept bonnes pratiques de développement avec SPIP

    perso je rédige parfois sur un site wordpress et il m’impressionne pas du tout.

    Une fois sur deux il m’impose une catégorie que je veux pas, il est à moitié traduit.

    Après pout lancer un site tout de go, je dis pas. Mais niveau personalisation du HTML, rien ne vaut les boucles de SPIP. Pas à ce faire c***** avec du PHP.

  • Le 14 janvier 2012 à 18:30, par pascal weber En réponse à : Sept bonnes pratiques de développement avec SPIP

    Je plussoie.

    Wordpress ça suffit pour déployer un petit site sympa en deux coups de cuillère à pot (on part d’un thème, on le met à sa sauce et le tour est joué).

    Dès qu’on veut aller plus loin et qu’on désire faire du sur-mesure, des fonctionnalités particulières, des développements plus personnalisés etc et qu’on ne veut pas passer des jours entiers à écrire des requêtes et des fonctions PHP, les boucles SPIP c’est que du bonheur ! Un peu d’apprentissage au départ mais après : vive liberté !

  • Le 14 janvier 2012 à 19:48, par Comm2Presse En réponse à : Sept bonnes pratiques de développement avec SPIP

    Hum, je vois le genre :) Wordpress pour les amateurs et Spip pour les pros quoi :) ? Me voilà obligé de faire un coup de pub pour le CMS Yacs alors qui a la même approche :) (Voir ma signature ou chercher gentiment sur Google). Mais on dérive un peu du sujet non ? :)

  • Le 14 janvier 2012 à 19:53, par Maïeul En réponse à : Sept bonnes pratiques de développement avec SPIP

    a mais ce n’est pas moi qui ait parlé de WP :-)

    YACS, connaissais pas, je regarderais. Mais dans le choix d’un CMS, il y a pas que la technique, il y a le sentiment aussi ;-)

  • Le 26 février 2018 à 09:49, par Skwal En réponse à : Sept bonnes pratiques de développement avec SPIP

    Bonjour et merci pour ces conseils !

    Complètement d’accord sur le fait de créer un plugin pour chacun de ses sites. J’utilise SPIP en mutualisé et ça me simplifie la vie lors de passages à une nouvelle version des sites. De plus j’ajouterai qu’il est extrêmement pratique d’utiliser la balise « necessite » dans plugin.xml pour pouvoir installer des dépendances spécifiques sur chaques sites.

    Bonne continuation, Skwal

Qui êtes-vous ?

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Acheter XeLaTeX appliqué aux sciences humaines

À propos

Titulaire d’un doctorat en théologie et d’un doctorat en histoire, sous la direction conjointe de Frédéric Amsler et d’Élisabeth_Malamut, je commence à partir du 1er août 2017 un travail d’édition critique des Actes de Barnabé.

Dans le cadre de la rédaction de mon mémoire de master puis de ma thèse de doctorat, j’ai été emmené à utiliser LaTeX, et j’ai donc décider de partager mes techniques. En effet, au cours de mes premiers apprentissages, j’ai découvert que les ressources indiquant les outils pour l’utilisation de LaTeX en sciences humaines étaient rares. Ceci m’a conduit à maintenir ou créer plusieurs packages LaTeX et à donner plusieurs formations.

J’ai reçu en 2018 le prix DANTE e.V pour mon travail autour de LaTeX, en particulier autour de reledmac et reledpar.

Par ailleurs, je suis membre actif de la communauté SPIP, au sein de laquelle j’administre le site Spip-Contrib. Je propose sur ce site quelques notes sur SPIP, en général à destination de webmestre.

Il m’arrive également de faire un petit peu de Python, de temps en temps.

Enfin, je tiens un blog de réflexions politiques et religieuses.

Maïeul