Sept bonnes pratiques de développement avec SPIP - commentaires

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

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 ;-)

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 ? :)

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é !

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.

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 ? :)

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

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 ^^)

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 ?

Sept bonnes pratiques de développement avec SPIP

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

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 !)

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 ;-)

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.

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

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.

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

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

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).

Sept bonnes pratiques de développement avec SPIP

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

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

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

Sept bonnes pratiques de développement avec SPIP

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

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 ou / #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.

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.

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 ?

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 ?

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

Sept bonnes pratiques de développement avec SPIP

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

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

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... ^^

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

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_... où 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 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.

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

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 1^re 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 :-)

Sept bonnes pratiques de développement avec SPIP

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

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.

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