Hé @spip, je viens d’installer un #SPIP_3.2.7, sur un serveur où il est possible que j’ai des droits un peu bizarres (c’est pas moi qui héberge). Et ça m’indique :
Le cache est temporairement désactivé.
J’ai installé memcache, utilisé avec Mémoïzation, mais curieusement ça continue à me dire que « Le cache est désactivé » (et il l’est : j’ai des pages avec du contenu aléatoire qui ne devrait changer qu’au calcul, et ça change… tout le temps).
Bon, je ne sais pas s’ils vont apprécier, mais vu qu’ils m’ont filé un sudo, j’ai downgradé de PHP 7.3 à PHP 7.2. Maintenant ça roule…
Quelqu’un a eu ça aussi : ▻https://git.spip.net/spip/spip/pulls/31 et une autre personne sur l’IRC à l’instant.
Nouveau #plugin pour #SPIP_3 : Raccourci ‹dame› blanche
▻http://zone.spip.org/trac/spip-zone/browser/_plugins_/dame_blanche
Il s’agit d’une phrase du texte que l’on fait ressortir dans la maquette, histoire de rythmer la page et de faire ressortir un point accrocheur. La plupart des gens appellent ça l’exergue, mais c’est erroné : ça s’appelle une dame blanche (l’exergue, c’est une citation qui n’est pas tirée du texte lui-même, et qu’on met en début d’article ou de livre.)
Ici, on l’utilise avec le raccourci <dame> :
<dame>La plupart des gens appellent ça l'exergue</dame>Il y a déjà un plugin « exergue », mais :
– le terme exergue est fautif, et j’ai affaire à une utilisatrice qui n’acceptera jamais qu’on confonde les deux termes… ah mais !
– je voulais voir comment utiliser #textwheel dans un plugin ; je ne sais pas si on peut faire encore plus simple, mais c’est déjà vachement agréable (tu peux aller jeter un coup d’œil, vraiment c’est pratique) ;
– le style est dans un fichier, fonctionne dans l’espace privé et sur le site public, et correspond à mes habitudes ;
– je préfère utiliser <aside> plutôt que <blockquote>, parce que pour le coup ce bout de texte est en dehors de l’article. Donc : tu as intérêt à faire ton site en HTML5 si tu veux utiliser ce plugin.
Le fautif étant @booz, n’hésitons pas à le dénoncer !
(Et c’est là que je me rends compte que mon exemplaire du Code typographique de l’Imprimerie nationale – dans une édition désormais vintage – a disparu. Arg.)
Ouais parce que j’avais jamais entendu ce terme et ’ya pas grand chose sur le web… j’aurais bien lu un truc détaillé sur l’origine du nom ou quoi.
Tyto alba — l’Effraie des clochers, aussi appelée Dame blanche, pourrait faire une chouette idée de logo
(d’autant que certains écrivent typo alba)
Prenez garde !
La Dame Blanche vous regarde,
La Dame Blanche vous entend.
Pour moi, la dame blanche, c’est le fantôme qui prévient les conducteurs sur les routes de Maurienne la nuit...
Hello,
Super cette trouvaille du terme dame blanche.
Pour le plugin bien joué pour textwheel. Mais si je lis bien le code tu fais une extraction de la citation, qui est affichée une fois donc, hors du texte.
Dans le plugin exergue, le texte cité est affiché deux fois, une fois dans le texte de base, et une autre fois recopié en js dans un bloc stylé joli. La « dame blanche » est donc un ajout.
On peut également placer plusieurs dames blanches / exergues dans un même texte, à n’importe quel endroit.
▻http://zone.spip.org/trac/spip-zone/browser/_plugins_/exergue
Pas facile de trouver des ressources en ligne qui parlent de cette dame blanche, effectivement.
En voici une : ▻http://fr.comp.graphisme.pao.narkive.com/5yXXidpd/comment-s-appelle#post18
@ari si j’ai bien compris la discussion que j’ai pointé (qui date d’il y a presque 10 ans tout de même), ce serait peut-être plus utilisé au Québec…
Bonjour,
Merci pour ce plugin.
Je m’apprête à l’utiliser sur un site et j’aimerais y rajouter :
– un bouton dans la barre typo
– une possibilité de passer un alignement (left|center|right)
Qu’en dis-tu @arno ?
D’autre part, le choix de <aside> pose un problème d’accessibilité : en effet, il faut que chaque bloc HTML5 soit immédiatement suivi d’un titre, ce qui n’est pas le cas ici.
Enfin, le texte que l’on écrit dans une dame blanche me semble faire partie intégrante de l’article que l’on écrit. Pourquoi le placer en <aside> et pas en <p> tout simplement ?
Puisque ce seen est ressuscité, je précise qu’après avoir utilisé le plugin exergue un temps, on préfère désormais une alternative simple et efficace qui s’efface facilement à l’export : un modèle exergue qui s’écrit donc <exergue|texte=le texte> et produit toujours un <blockquote class="exergue">
SPIP a déjà une syntaxe pour les <blockquote> qui est <quote> (on aurait pu garder le même mot mais bref…), et on pourrait imaginer directement pouvoir lui passer une classe, puisque ça existe déjà. Du genre <quote exergue>Mon texte</quote>.
On pourrait l’imaginer mais pour l’instant on utilise le <quote>pour une chose, et des <blockquote class=pour d’autres trucs. Mais de fait, pouvoir mettre des classes aux raccourcis serait chouette.
@baroug : est-ce que tu pourrais partager ton modèle exergue dans l’idée d’en faire un plugin avec le yaml qui va bien pour insérer_modèle ?
quel intérêt ? autant le… mettre dans /modeles ? Je comprend pas l’intérêt d’un plugin qui fait une chose aussi simple. Mais oui je peux le partager c’est extrêmement simple :
[(#REM) Affiche un exergue ]
[<blockquote class="exergue">
(#ENV{texte}|propre|PtoBR)
</blockquote>]…et un peu de css of course…
Chose promise... Joyeux Noël : ▻http://zone.spip.org/trac/spip-zone/changeset/101216
Avec Mosquito, on vient de livrer le nouveau site de la Fémis :
▻http://www.femis.fr
C’est du #SPIP_3, #responsive, #HTML5 (et du #shameless_autopromo évidemment).
Parmi les points originaux…
– Le menu de navigation principal avec son animation « gauche-droite » au survol. Le javascript est très simple, et l’animation est directement en transition CSS. Dans chaque menu, les colonnes des rubriques/sous-rubriques sont aussi équilibrées que possible, et c’est fait directement avec Masonry.
– Les images passent par mon plugin « image_responsive », ce qui permet de gérer différentes tailles, ainsi que le chargement d’images deux fois plus grandes pour les écrans haute définition.
– Il y a réellement très peu d’images pour réaliser l’interface graphique. C’est essentiellement des CSS avec des dégradés discrets, des ombres portées… Comme d’habitude, mon plugin « CSS imbriqués » est très utile pour faciliter le codage (CSS avec gestion des préfixes et des variantes de navigateurs, code hiérarchisé, inversion des #media_queries…).
– La moteur de recherche (c’est du pur SPIP/Fulltext) bénéficie de petites améliorations dans les squelettes. (C’est accessible via la loupe en haut à gauche de la page.) La première consiste à faire des suggestions lorsqu’on commence à taper un mot. Tu tapes « réali », et ça te déplie des suggestions : « réalisation, réalisateurs, réalisateur, réalisé, réaliser… » classées en fonction de la présence de ces mots dans le site. Une fois que tu as validé ta recherche, la page de résultats est classique, mais avec un détail : le texte « descriptif » de chaque article est calculé pour afficher le terme recherché, surligné dans son contexte (habituellement on affiche simplement le début du texte comme partout dans le site ; là il y a un calcul amusant).
– Une grosse partie du boulot a consisté à refondre la base de donnée des anciens élèves. D’abord créer des moulinettes pour réorganiser l’ancienne base de données dans ma nouvelle structure. Ensuite évidemment gérer l’affichage sur le site (avec SPIP, cette partie, c’est assez finger in ze noze). Et surtout : des formulaires pour que chaque ancien étudiant gère lui-même sa fiche, ses infos personnelles, sa filmographie, son CV structuré… Le tout en essayant de proposer des interfaces aussi intuitives que possible, ce qui est toujours une gageure quand on a des formulaires un peu complexes.
– Ça faisait carrément longtemps : on utilise les brèves de SPIP ! (Pour l’« Actualité des diplômés »).
– Comme à mon habitude, la page d’accueil et le footer sont construits avec une « rubrique technique » invisible, laquelle contient des sous-rubriques pour structurer, et il faut donc publier des « articles virtuels » qui redirigent vers ce qu’on veut. C’est un peu plus contraignant que d’autres techniques, mais c’est ce qui donne la plus grande souplesse (on peut « référencer » des articles, des rubriques, des pages distantes…, forcer le classement qu’on veut en page d’accueil, utiliser des titres et des descriptifs plus adaptés…).
Comme à mon habitude, la page d’accueil et le rooter sont construits avec une « rubrique technique » invisible, laquelle contient des sous-rubriques pour structurer, et il faut donc publier des « articles virtuels » qui redirigent vers ce qu’on veut. C’est un peu plus contraignant que d’autres techniques, mais c’est ce qui donne la plus grande souplesse (on peut « référencer » des articles, des rubriques, des pages distantes…, forcer le classement qu’on veut en page d’accueil, utiliser des titres et des descriptifs plus adaptés…).
Héhé, par deux fois déjà, j’ai opté pour exactement la même technique, afin de sélectionner les contenus listés dans un carrousel d’accueil. Cela permet d’avoir une image différente, pas forcément intégrée au contenu final qui est lié, pareil pour le titre et le descriptif, qui peuvent être propres à l’accroche, et ça permet effectivement aussi de rediriger vers un autre contenu externe.
Pour ne pas faire de bidouille, ça pourrait mériter un plugin dédié, du genre « Sélections de contenus », où on pourrait en créer autant qu’on veut, avec un identifiant textuel non lié à la base (ce qui permet de l’utiliser dans les squelettes génériquement), et qui permettrait alors de sortir :
<BOUCLE_news_accueil(SELECTIONS){identifiant=news_accueil}>
LOGO_SELECTION
TITRE
DESCRIPTIF
LIEN (celui ci pouvant gérer à la fois une URL classique, ou un identifiant de contenu SPIP du genre : « evenement1234 »)
</BOUCLE_news_accueil>
Avec une interface bien fichue pour les administrer. Ça sera plus facile et plus facilement compréhensible (car pas un détournement).
Salut @arno,
j’ai enfin pris le temps de commencer ce plugin de sélections éditoriales.
Voici le premier commit :
▻http://zone.spip.org/trac/spip-zone/changeset/83884
Tu peux donc te faire une sélection « accueil », une autre « footer », etc. Et les récupérer facilement dans tes squelettes :
<BOUCLE_une(SELECTIONS){identifiant=accueil}>
<BOUCLE_contenus(SELECTIONS_CONTENUS){id_selection}>
<a href="#URL">
#LOGO_SELECTIONS_CONTENU
#TITRE
#DESCRIPTIF
</a>
</BOUCLE_contenus>
</BOUCLE_une>Et dans le champ « url », tu peux y mettre :
– soit un URL complet quelconque
– soit un objet SPIP sous la forme « article123 », « evenement456 », « rubrique789 ».
Dis moi ce que tu en penses.
(Et comme le dit le commit, viendra ensuite l’ajout de sélections en-dessous d’un objet SPIP. Lorsqu’on le veut.)
Oublié de le dire :
1) j’ai ajouté la création d’une sélection sous un contenu SPIP (un article par exemple), et
2) j’ai modifié le formulaire d’ajout d’un contenu sélectionné pour le rendre plus pratique : seule l’URL est obligatoire, et si on ne met que ça, la magie va chercher le titre du contenu SPIP (si on a mis « article1234 » par exemple) ou le titre de la page HTML (si on a mis un URL http).
@nidal a annoncé le lancement du site @OrientXXI la semaine dernière :
▻http://seenthis.net/messages/180554
C’est donc là :
►http://orientxxi.info
Comme c’est bibi qui l’a fait, un petit coup de #shameless_autopromo pour détailler quelques aspects techniques…
– C’est évidemment du #SPIP_3, #HTML5 et #responsive. Donc évidemment, je travaille avec mon plugin « CSS imbriqués » :
►http://www.paris-beyrouth.org/tutoriaux-spip/article/plugin-spip-css-imbriques-pre
– L’un des aspects que j’ai pu beaucoup plus travailler que d’habitude, c’est la typographie des textes des articles. C’est drôlement gros (de base sur mon ordinateur : 19px), et c’est rend la lecture à l’écran vraiment fluide. Sur tablette, je trouve que c’est carrément épatant.
– Pour l’occasion, j’ai aussi pas mal bossé les tags meta destinés à informer les réseaux sociaux du contenu de la page. Les petits pavés qui apparaissent sur Twitter et Facebook quand quelqu’un partage un article sont vraiment attrayants.
– Le pavé « Lire aussi » dans la colonne de droite des articles est totalement automatique : c’est un calcul basé sur les mots-clés utilisés par chaque article. Ça marche pas mal pour créer de la navigation transversale.
– Je fais passer mon plugin « Détecter langue » (conçu initialement pour Seenthis) sur les textes, cette fois paragraphe par paragraphe, pour pouvoir publier des articles multilingues (avec de l’arabe, ça devient indispensable) :
►http://zone.spip.org/trac/spip-zone/browser/_plugins_/plugins_seenthis/detecter_langue
On peut le voir à l’œuvre par exemple sur ce poème traduit de Mahmoud Darwich :
►http://orientxxi.info/magazine/mahmoud-darwich-for-ever-le-discours-du-dictateur-0328
– Sur ce site, je force le retour chariot façon SPIP 2 (il faut sauter deux lignes) ; parce que plus ça va (depuis que je suis sur SPIP 3), plus je constate que laisser le retour à la ligne simple sur un site éditorial conduit rapidement à la catastrophe.
– Pour le pavé de Une (fond bleu) de la page d’accueil, une sélection manuelle grâce avec mon vieux plugin « Sélection d’articles » :
►http://zone.spip.org/trac/spip-zone/browser/_plugins_/selection_d_articles
– Comme expliqué par @nidal, le site intègre directement le flux Seenthis du groupe (via l’importation de RSS de SPIP) :
►http://orientxxi.info/au-fil-du-web
– J’utilise mon vieux plugin « Lire aussi » pour pouvoir créer des « Dossiers » :
►http://orientxxi.info/magazine/oslo-20-ans-apres,0345
(donc, bien comprendre : sur ce site le pavé « Lire aussi » du site public se construit automatiquement ; le plugin « Lire aussi » n’est pas utilisé pour créer ce pavé, mais pour constituer des « Dossiers » éditoriaux)
– Dans la rubrique « Cartographie », j’affiche des cartes géantes zoomables de @reka, l’interface fonctionnant avec #leaflet.js. Ajout : un véritable mode plein écran (#fullscreen_api du HTML5, avec alternative en position:fixed pour les navigateurs qui ne l’acceptent pas). En revanche, par rapport à @fil, je n’ai pas de script coté serveur pour fabriquer les briques graphiques des cartes, j’utilise directement Zoomify et j’installe les briques sur le serveur.
Le détail sympa : la carte est consultable seule dans sa page :
▻http://orientxxi.info/cartographie/egypte-bassin-du-nil
mais il y a de plus un modèle SPIP pour intégrer la carte dans le texte d’un article :
►http://orientxxi.info/magazine/tensions-autour-du-nil,0297
(et ça c’est carrément cool).
C’est classe d’avoir ce genre d’explications sur des sites. Deux-trois retours :
– +1 pour la question des retours lignes. C’était un peu embêtant avant, fallait s’y faire, mais maintenant sur Spip 3 c’est pire :p
– Pour les réseaux sociaux, le rendu est top, cf ▻https://twitter.com/OrientXXI/status/387504642331901952
– moi aussi je veux un bouton de partage vers Seenthis. C’est le bouton pour navigateur intégré sur le site, c’est ça ?
– au niveau typo, je pense qu’on gagne vraiment à remplacer les dernières Arial qui traînent.
– sur la page d’accueil, les trois colonnes ça fait très classe, mais le web ne sait toujours pas justifier du coup ça éclate le texte chez moi. A l’inverse, j’aime beaucoup la page magazine non justifiée.
– le corps 19 pour le texte, ça fonctionne bien, mais par contre le corps 26 pour le chapô, c’est un peu trop gros pour moi.
– j’ai pas compris l’intérêt du plugin « lire aussi » pour constituer des dossiers éditoriaux par rapport à un groupe de mots-clés spécifique.
– le mode plein écran pour les cartes est vraiment impressionnant, et les cartes dans les articles sont bien aussi. Ca pourrait bien intéresser sous-surveillance. Manque peut-être juste un bouton pour revenir à une taille optimale dans le bloc quand t’as déjà zoomé.
Merci en tout cas pour les infos, joli boulot !
#spip_blog
Sur « Lire aussi » et les « Dossiers »…
– D’abord, tu dois savoir que je suis persuadé (de manière quasiment religieuse désormais) qu’il ne faut jamais utiliser les mots-clés pour gérer des statuts éditoriaux. La seule utilisation viable des mots-clés, c’est la thématisation.
À chaque fois que j’ai vu (ou qu’on m’a obligé à le faire) des mots-clés utilisés pour gérer la page de Une, la colonne de droite, les trucs qu’on fait apparaître plus gros… ça rend le site vraiment bordélique à gérer.
– Donc ici, oui, il y a des mots-clés, mais ce sont bien des mots-clés thématiques. Par exemple, les Accords d’Oslo :
▻http://orientxxi.info/accords-d-oslo
Mais il faut bien voir que les mots-clés, ce sont des thèmes « ouverts » : à tout moment quelqu’un peut ajouter tel mot-clés à tel nouvel article, et donc la page « Accords d’Oslo » évoluera selon ces ajouts.
– Ce dont j’avais besoin ici, c’est de créer des « Dossiers » figés. Un objet éditorial regroupant plusieurs articles, qu’on n’enrichira plus par la suite.
Donc pas des mots-clés. Sinon ça veut dire qu’on a un groupe de mots-clés dédiés à cela, et qu’on fabrique un mot-clé à usage unique pour chaque « Dossier ». Pour moi, c’est clairement un détournement des mots-clés, destinés à faire des manipulations éditoriales.
Ça n’est pas le pire détournement possible, mais c’est à éviter.
– Le plugin « Lire aussi » est explicitement destiné à gérer ces regroupements, au lieu de créer des « mots-clés à usage unique ». Il est construit sur le même principe que les liens de traduction : il y a un article de référence, et les articles qui lui sont liés. Dans chaque article concerné, je vois la liste des articles liés, et quel est l’article de référence.
Du coup, ici, c’est facile : l’article de référence est considéré comme la porte d’entrée du dossier (ce ne serait pas facile à faire avec des mots-clés), et je pourrais aussi décider de ne plus intégrer les articles secondaires du dossier dans la navigation, ou de manière différente (je n’ai pas fait ça, mais c’est une possibilité).
Coucou,
Plein de belles choses. Mignon la petite image « dossier » qui se colle sur le logo de l’article d’accueil du dossier.
Quelques bugs ou remarques :
– le logo est un peu pixélisé sur les autres pages que la page d’accueil (ff20/linux)
– quand y’a pas de logo pour les articles dans les listes de « Lire aussi », ça fait un peu bizarre. ici par ex : ▻http://orientxxi.info/magazine/barack-obama-et-hassan-rohani,0381
– c’est peut-être voulu, mais chez moi les thèmes ne sont pas stylés. Ça me fait penser aux sites de journaux américains, qui raffolent de liens bleus ►http://www.nytimes.com
Une petite question. Comment sont fabriquées les url ? Le numéro à la fin, c’est pour google (j’ai un vague souvenir que google demande un nombre unique pour chaque page dans l’url) ?
C’est super de présenter ses réalisations de sites et leur entrailles. Ça devrait être une rubrique sur le blog de SPIP ou sur spip-contrib, pour inviter tout le monde à le faire.
Pour les URL, c’est un bout de code trouvé je crois sur Contrib, mais je ne sais plus où. Dans mes_options.php :
▻https://gist.github.com/anonymous/6899027
Ah si, retrouvé, c’est là :
▻http://contrib.spip.net/Optimiser-les-URLS-pour-google-actus
Hop @arno pour info il existe un plugin leaflet.fullscreen fait par un ty gars sympa sur github ;)
▻https://github.com/brunob/leaflet.fullscreen
Et depuis hier, il gère aussi du pseudo fullscreen pour les vieux navs.
@arno oui c’est un truc « rapide » qui marche, mais du coup :
1) je trouve que ça enlaidie les URLs pour une histoire uniquement technique (en plus même pas pour un standard reconnu mais juste pour faire plaisir à une entreprise particulière)
2) si jamais le site a des objets éditoriaux différents (article, rubrique, événement, patate) : deux objets peuvent avoir le même nombre donc il n’est pas unique (ce qui normalement fait partie de la demande).
Lorsqu’on ne veut pas modifier ses URLs, la solution est de fournir à Google un sitemap particulier, propre à #Google-News. Il y a quelques obligations à respecter, et possiblement des infos en plus quand on les a sous la main (voir la doc).
▻https://support.google.com/news/publisher/answer/74288?hl=fr
J’ai fait ça dans un mini-plugin tout con qui ajoute ça au robot.txt de SPIP et qui fournit un « sitemap_news » basique qui fonctionne. On peut le surcharger ensuite chez soi si on a plus d’infos à y mettre.
▻http://zone.spip.org/trac/spip-zone/browser/_plugins_/sitemap_news/trunk
@arno : merci, je vais tester. Sur Rebellyon, les articles en manchette ont le mot-clé « manchette », ceux en « une », le mot-clé « une ». Et quand on a beaucoup d’articles sur un même sujet, on crée un mot-clé de dossier. Tout cela fonctionne, mais c’est pas forcément aisé à transmettre comme fonctionnement.
Je pense qu’il faut créer ou améliorer un plugin pour ces besoins, car il y a de plus en plus de sites où il y n’y a pas que les « articles » comme objets éditoriaux.
Par exemple pour le besoin de « mettre en une » (que ce soit pour l’accueil complet ou l’accueil d’une rubrique), si on veut mettre en avant des articles et des événements dans la même liste, c’est galère. Ou même si on a un site composé presque que d’événements (un site culturel par ex) et que c’est ça le contenu éditorial principal du site.
Bref, ce type de plugin devrait être agnostique au niveau des objets à manipuler.
Pour gérer les Unes, j’utilise généralement deux solutions :
– la plus efficace et agréable à gérer, ce que je fais sur ce site-là, c’est le plugin « Sélection d’articles » ; c’est rapide, ça marche bien…
– quand le site est plus compliqué, et que justement il faut pouvoir mettre en page d’accueil un peu tout et n’importe quoi (des articles, des rubriques, des « événements », des calendriers, des formulaires d’inscription à des trucs…), je fais dans le lourd : une « rubrique technique » (dont je fais généralement commencer le nom par un dièse), avec éventuellement des sous-rubriques (si la page d’accueil est très structurée), et là-dedans on installe des articles virtuels (des articles qui pointent directement vers une autre URL). C’est encore avec ça que j’ai les résultats les plus puissants et le plus de liberté, même si c’est assez contraignant.
Deux nouvelles options pour #optimiser son site #SPIP :
1. indiquer dans les logs de MySQL l’URL correspondant aux requêtes « lentes » :define('_DEBUG_SLOW_QUERIES', true);
cette option permet de savoir à quoi correspondent les requêtes logées dans mysql-slow.log
2. noter dans profiler.log les boucles demandant plus de 5 secondes (5000 ms) pour s’exécuter :define('_BOUCLE_PROFILER', 5000);
(dispo dans les branches #SPIP_2.1 + plugin #itérateurs, et #SPIP_3.)
►http://www.spip.net/fr_article4453.html
Tiens, ça me donne une idée : je vais faire un site Spip juste pour m’entrainer.
Et le ticket associé pour ne pas oublier de les documenter ailleurs qu’ici :p
@reka oui, vas-y, surtout que c’est ultra-rapide et simple maintenant. Monter le nouveau site de l’asso de soutien à l’écoles des gamins m’a pris une petite heure : ▻http://mcgfv.de
Merci aux codeurs SPIP et à tous les auteurs de plugins et thèmes !
Le site est compatible avec les mobiles, il a un wiki et (sur demande des autres parents) un espace protégé par mots de passe. Les plugins utilisés :
Accès Restreint
Autorité
Crayons
Le Couteau Suisse
Menus
odt2spip
Saisies pour formulaires
Thème Brownie
Z-core
Zen-Garden
J’ai juste modifié le css de Brownie pour avoir une typographie différente pour le titre et j’ai modifié la taille d’affichage des logos.
Je n’ai toujours pas compris pourquoi le comportement par défaut de #SPIP_3 était de respecter les retours à la ligne. Qu’il y ait l’option activable pour certains sites ayant des besoins spécifiques (comme Seenthis), oui, mais par défaut pour tout site éditorial sous SPIP, c’est juste pourri de chez pourri. Surtout que le comportement antérieur était un comportement parfaitement assumé du système dans le but, justement, de forcer les gens à faire de vrais paragraphes.
Depuis que j’ai mes premiers sites sous SPIP 3, je constate à chaque fois exactement ce pour quoi les retours à la ligne n’étaient pas respectés par SPIP : la disparition pure et simple des paragraphes, et des « articles » sous forme d’énormes pavés avec des retours à la ligne simples ne permettant plus de différencier les paragraphes.
Bref je viens de réactiver l’ancien comportement avec le :
define(’_AUTOBR’, ’’) ;
parce que c’est une sorte de catastrophe industrielle : le système qui se vantait de faire de la belle typo se met désormais à faire des pages de textes super-moches. Le comportement par défaut de SPIP fabrique désormais, c’est épatant, des sites totalement illisibles.
Mais pourquoi font-ils ça ?
Rhaaa, c’est une bêtise de @fil qui, en plus, savait très bien qu’il était en train de faire une bêtise :
▻http://comments.gmane.org/gmane.comp.web.spip.devel/62121
L’argument pourri :
oui c’est le souci, on n’est plus sur le dos des gens pour leur interdire de faire des bêtises
Le seul point embêtant que je vois c’est que ça facilite l’utilisation de <br/> qui est rarement une bonne pratique dans un texte HTML.
Alors est-ce que cette modification va aboutir à une explosion des <br/> dans les sites SPIP ? Il faudra voir à l’usage. Ça te fait pas peur ce point, Fil ?
Et retour de l’argument pourri :
ben est-ce que c’est notre rôle de fliquer les usages ?
Ben si, c’est la nature même de SPIP de promouvoir les bons usages et de rendre les mauvais usages plus difficiles. C’est sa spécificité.
Je ne vois pas bien la logique qui ferait de seenthis un site spécifique de ce point de vue. L’usage, partout, est de respecter les sauts de ligne, et la meilleure preuve que c’est chiant de ne pas le faire, c’est que dès que tu as fait un site ouvert à tous, tu t’es empressé de basculer sur cette norme.
Si, Seenthis est spécifique par rapport à SPIP, pour plusieurs raisons :
– le système est explicitement destiné à ce qu’une grosse partie du contenu soit des copiés-collés directs de documents externes ; et là, si je ne respecte pas les retours à la ligne, dans la moitié des cas je perds carrément les paragraphes ; c’est pour la même raison que le style des paragraphes, sur une page de flux (plusieurs billets successifs), réduit à 60% l’espace entre les paragraphes (il s’agit de limiter les trop grandes différences visuelles entre les extraits avec paragraphes et les extraits avec retour chariot) ;
– Seenthis exclue totalement l’utilisation des raccourcis typographiques ; et au départ, il n’y avait même pas de gras et d’italique (pas certain qu’on y ait gagné d’ailleurs) ; et dans cette logique de construire les textes en mode texte (à la façon d’un mail en mode texte), le retour chariot est assez fréquent comme outil de mise en forme (par exemple : dans un pavé Seenthis on colle l’URL sans possibilité de l’intégrer au texte ; le retour chariot est alors bienvenu) ;
– SPIP avait déjà un raccourci pour faire des retour à la ligne (underscore en début de ligne) ; dans SPIP ça se justifie, au côté des autres raccourcis non Wysiwyg ; dans Seenthis, non (puisque pas de système de raccourcis).
Mais l’argument principal, à mon avis, c’est bien ton inquiétude et ta réponse à Rastapopoulos : est-ce qu’on ne risque pas de provoquer la multiplication des usages illégitimes du <br> avec ce changement ? Tu ne réponds pas sur le fait qu’il n’y a pas un tel risque, ou qu’il serait contrebalancé par un gain ailleurs, mais simplement qu’on n’a pas à cliquer les usages. C’est un changement de paradigme de ce pour quoi SPIP est conçu, et je suspecte que ce renoncement est très présent dans nombre d’évolutions de SPIP 3.
Là je ne vois pas ce qu’on a au niveau fonctionnel (le retour chariot était déjà possible), mais en revanche on a fait disparaître sciemment un garde-fou qui faisait que SPIP avait, au niveau typographie, une vertu pédagogique (les gens demandaient comment on fait, on répondait à la fois techniquement et en prévenant que c’était rarement une bonne idée).
Bah oui, mais le underscore en début de ligne, ça marchait tellement pas qu’on avait déjà depuis longtemps forcé le saut de ligne dans les forums — là où les gens ne se relisent pas, et envoient des pâtés infâmes sans aucune respiration.
A tout prendre, le <br> est meilleur que l’espace, dès lors que l’intention du rédacteur/commentateur est de sauter une ligne ! Pour ce qui est de la soi-disant pédagogie, elle peut se faire autrement (les boutons de la barre de rédaction, etc.)
Ce qui reste in fine, c’est l’usage. Ce que je constate en à peine quelques sites, c’est la multiplication des <br class="autobr"> partout. Et tu as beau expliquer qu’il faut sauter des lignes, il en reste toujours : oublis parce que pas aussi visibles qu’avant, et/ou les gens ne trouvent pas ça si choquant.
Et, non, je ne constatais évidemment pas ça avec SPIP 2.
En parlant d’usage, avant de bouger le petit doigt j’avais notamment regardé un par un tous les forums du blog.mondediplo. Et il y avait beaucoup de sauts de ligne, à 99% exprimant une intention de passer à la ligne.
Pour moi, donc, l’usage est clair : « les gens » veulent passer à la ligne, ils tapent une ligne. Et si ça ne marche pas, par exemple lors de la prévisualisation (durant laquelle ils regardent, si tout va bien, s’il n’y a pas des fautes d’orthographe… mais certainement pas la disposition du texte), ils ne cherchent en général pas plus loin — et SPIP fait un gros pâté.
Ce qui est valable pour les forums devrait être aussi valable pour les articles.
Pour les rédacteurs qui mitonnent leurs textes dans l’espace privé, on a bossé pour rendre bien visibles les BR. Mais c’est l’espace privé… mais ça me donne une idée pour l’espace public : dans la css des crayons (ou des boutons d’admin), on pourrait ajouter le truc qui rend visibles les BR, ainsi ils seraient visibles aussi dans le public, et là vraiment personne ne pourrait les rater.
Mais les forums et les articles ne sont pas la même chose, et ne demandent pas du tout le même rapport au site (niveau d’engagement).
Je ne suis pas choqué qu’on ait des différences entre les deux. Et même, l’idée d’interdire totalement les enrichissements typographiques dans les forums ne me choquerait pas non plus.
Une piste : et pourquoi les forums ne passeraient pas, purement et simplement, dans la syntaxe de Seenthis : cette syntaxe est à la fois quasiment inexistante (surtout si tu supprimes les gras, italique et hashtags), et conçue justement pour gérer et maquetter du « texte brut » de manière quasiment transparente (donc pour des forums).
Dans les forums de spip-contrib, on échange souvent du code précis… la syntaxe de seenthis ne le permettrait pas. La syntaxe SPIP a ce grand mérite d’être à la fois simple et d’autoriser un maximum de possibilités « expressives ». Le seul bug, à l’usage, était cette histoire de sauts de ligne jamais pris en compte, bien que « saisis » (ou plutôt « tapés ») par les utilisateurs basiques.
Ton problème doit à mon avis se régler autrement, soit par l’imposition technique d’une suppression des .autobr (par le define, par un hack css, ou par ton plugin NoBR), soit par la pédagogie (en ajoutant éventuellement un signalement dans l’espace public, via la css des boutons d’admin/des crayons).
On peut en discuter encore longtemps, vu qu’on n’est pas d’accord, mais je crois que j’ai fait le tour des arguments que je pourrai développer :)
Pour former régulièrement des utilisateurs à SPIP je confirme que la non prise en compte des retours à la ligne suscite la perplexité, ainsi que le raccourci _ Pour ma part je ne rétabli les comportements antérieurs que pour des sites où le contenu est issu de copier/coller plein de retours à la ligne intempestifs. Et les rédacteurs créent quand même des paragraphes.
Ma grosse occupation de décembre dernier :
►http://www.flip-zone.com
J’ai entièrement recodé le bouzin, avec passage à #SPIP_3, HTML5, internationalisation en 10 langues sur un unique site SPIP, #responsive_web_design et, surtout, disparition totale de Flash.
Dans les prochaines jours je vais essayer de faire une série de messages décrivant des aspects techniques qui pourront soit intéresser soit servir à d’autres. Parce que du côté de la technique HTML/Javascript/CSS, c’est assez rigolo.
– Flip-Zone existe désormais depuis quelques années, je le gère avec @diala, et ça représente maintenant une partie non négligeable de notre revenu. De plus, c’est un site qui nous permet de faire la démonstration de certaines de nos compétences en matière de webdesign (ce qui reste notre activité principale).
– Récemment, j’ai découvert que la version arabe du site avait plus de 45% de ses visites sur support mobile. Les versions anglaises et françaises, aux alentours de 25%. Et le site n’était plus adapté à ces supports (la version arabe n’avait pas de version adaptée, et la version anglaises avait une vieille version iPhone datant de l’iPhone 1, et la version iPad était pas mal, mais uniquement pour la tablette d’Apple).
– Donc : passer intégralement en responsive design. J’ai lu le terme « tablet first » ; ça n’est pas totalement le cas ici, parce qu’on savait que le PC reste notre source principale de revenu. Donc le redesign est certes largement motivé par les supports tactiles, mais en gardant au centre des évolutions ce qui fonctionne (commercialement, s’entend) dans la version PC.
– Ne pas se voiler la face quand on parle de ce genre de webdesign : les bandeaux de publicité constituent la contrainte principale du projet. Les bandeaux sont moches et souvent vulgaires, rendent le graphisme incohérent et moche, ralentissent la navigation, compliquent l’aspect responsive et imposent leurs dimensions aux blocs, mais ce sont eux qui paient pour l’ensemble. Donc il faut réussir à les intégrer au mieux, et il faut que suffisamment de gens cliquent dessus (on ne peut donc pas les planquer dans un coin). Je rigole souvent en lisant les théories de webdesign qui, assez systématiquement, occultent la présence de ces affreux bandeaux. Dans la vraie vie, sur un site à vocation commerciale, hé bé ils sont le centre (moche et contraignant) du design.
– Adapter le chargement et l’affichage des images des collections (les fameux « flip-books » de Flip-Zone) à la taille de l’écran et à la haute définition (écran rétina).
– Remplacer mon ancien visualiseur de collections, qui était en Flash, par un nouvel outil HTML5. Répondre aux gestures des supports tactiles (tablettes notamment). Compatibilité des gestures sur Android (pas seulement iOS). Avoir un mode plein-écran de qualité (en pur HTML, oui oui). L’essentiel du boulot a porté sur ce point.
– Auparavant, on avait un site SPIP par langue. Ça nous faisait déjà 4 sites à gérer à chaque mise en ligne de collection. But de la nouvelle version : fusionner les 4 sites en un seul SPIP, avec un seul squelette multilingue. Du coup : passage à 10 langues (dont le japonais et le chinois). Et conserver la spécificité de la version arabe, qui est de promouvoir spécifiquement les créateurs libanais (avec le même squelette) – c’est-à-dire même contenu, même SPIP et mêmes squelettes, avec une structure de l’information présentée assez nettement différente.
On a lancé la nouvelle version juste avant Noël, et ça a l’air de tourner correctement. J’ai continue à modifier des détails, mais en gros ça semble très bien tourner. Graphiquement on est très contents, c’est assez spectaculaire ; les « flip-books » en HTML rendent très bien, sur tablette c’est vraiment épatant, sur smartphone c’est très utilisable (peut-être un bug avec les zooms des images immenses sur iPad retina, faut que j’arrive à confirmer), les nouvelles langues commencent tranquillement à avoir des visites, la gestion du site (au lieu de 4 auparavant) est nettement facilitée…
C’est propre !
Qu’est ce qui a motivé ton choix de mettre le champs de recherche en bas de page ?
Euh…
– parce qu’en haut de page, avec le responsive un peu compliqué là-haut (les menus horizontaux se rétractent en menus verticaux), ça devenait un peu chiant à caler ;
– sur ce site, c’est pas une fonctionnalité centrale ; alors autant le mettre en bas de page ;
– et j’ai repris ce que j’avais auparavant, qui est l’affichage d’un résultat illico lors de la frappe. Pour lequel j’ai besoin de place (donc en bas).
Impressionnant !
Le terme « Kulissen » pour dire « backstage » est une traduction sympa parce qu’elle est un peu maladroite. On dit « Backstage » en allemand également. On met la première lettre en majuscule car c’est un nom et hop - c’est de l’allemand :-)
sur ipad retina la photo de la page d’accueil et des « chapitres » semblent être en « basse » définition (pixellisée), tandis que celles qu’on obtient en scrollant vers la droite semblent en 2x ; mais il faut que je m’achète un microscope pour en être certain. il y a aussi un paradoxe, parfois si on clique sur la loupe ça rapetisse l’image au lieu de l’agrandir
@klaus : Backstage it is, alors !
@fil : le retina sur iPad me ose problème, il y a une limitation de mémoire par Apple qui est carrément pénible ; passé à l’Apple Store ce week-end, j’ai constaté que ça plantait carrément sur iPad (pas sur MacBook retina). Du coup, je tâtonne encore un peu pour l’iPad (d’autant que j’en ai pas de retina sous la main).
Quant à l’image de couv du flipbook, elle est en basse def (et même très basse def). Là-dessus je suis un peu coincé, je n’ai pas trouvé de solution (à cause de l’héritage, et parce que j’ai désormais un format spécial pour ça pour lequel la basse définition me laisse plus de latitude pour retailler des images).
