J’y suis assez favorable, ça nous ferait nous rapprocher d’une syntaxe connue pour l’édition de contenus, et pour plein d’autres raisons, notamment et pas des moindres cet éditeur WYSIWYM qui prend en compte les modèles.
Mais c’est un chantier, je ne sais pas par exemple si des gens utilisent l’éditeur au quotidien, en réel.
Il y a le problème des contenus existant en syntaxe SPIP (il y a un convertisseur développé par @cy_altern et @tofulm mais je ne le retrouve pas).
Et sûrement plein d’autres chantiers.
Mais si on s’organise, on peut y arriver, d’où ce fil, pour en discuter
Premier truc auquel je pense : il ne faut bien sûr pas bloquer le fonctionnement sur markdown, il faut supporter les deux syntaxes.
Mais on pourrait basculer en markdown par défaut lors de l’install / mise à jour, si on détecte qu’il n’y a pas de contenus existant (rubriques/articles).
(merci de faire une réponse séparée pour chaque point abordé, pour qu’on puisse avoir un suivi sous forme d’arborescence même si Discourse ne l’affiche pas comme ça (j’aime pas Discourse, mébon))
Sinon on peut aussi faire ça dans un ticket Gitlab, où on voit mieux qui répond à quoi.
Est-ce que tu veux dire que comme on arrive déjà pas à releaser SPIP 5 tel que prévu, ça sera plus facile en rajoutant un gros truc dessus ?
Mon avis c’est qu’ajouter cette charette à SPIP 5 c’est suicidaire car de fait très peu de gens utilisent le plugin en prod, et il faut en effet gérer la question de l’historique, dans ce cas on peut directement se retrouver en 2027 pour (peut-être) releaser…
Par ailleurs il ne faut surtout pas faire de conversion de contenus car ça va générer plein de bugs dans les contenus, notamment dès que les gens utilisent des syntaxes complémentaires perso enrichies et ça on a pas le droit.
Il faut donc supporter la syntaxe historique SPIP, et se pose alors la question de l’éditeur, puisqu’il faut un éditeur pour la syntaxe SPIP et un éditeur pour la syntaxe Markdown.
Mais il y a une alternative, puisqu’on repose de plus en plus sur composer, qui serait de faire des distributions.
Rien n’empêcherait d’avoir (au moins pendant un certain temps) une distrib SPIP legacy (avec la syntaxe SPIP, parfaite pour la mise à jour des sites existants) et une distrib SPIP markdown (en MD, parfaite pour les nouveaux sites), et de proposer un outil de conversion que les gens pourraient utiliser pour convertir leur site quand ça les arrange.
Mais bon pour moi il faut clairement viser un SPIP 6 pour ça, quitte à ce que ce soit le seul objectif de cette version majeure.
Techniquement ça fonctionnera comment au fait ? On aurait un convertisseur Markdown → Syntaxe Spip et on utilise toujours le même convertisseur Syntaxe Spip → HTML ? Ou bien on aurait deux pipelines Markdown → HTML et Syntaxe Spip → HTML ?
Eh bé non, si on passe à Markdown le but est de ne plus avoir de syntaxe SPIP (sauf les spécificités comme les modèles), donc c’est uniquement Markdown, avec les contenus enregistrés en Markdown dans la base.
Il y aura bien sûr une période de transition où il y aura les deux en mêmes temps (mais séparés soit l’un soit l’autre !). Mais au delà de la transition, le but est bien de ne plus avoir à maintenir notre propre syntaxe et se reposer sur des libs existantes maintenues, car on utiliserait une syntaxe largement répondue dans le monde entier.
À terme, la syntaxe SPIP resterait sûrement en plugin à part (avec Textwheel ?), pour les sites qui ne veulent/peuvent pas se mettre à jour. Charge à celleux qui veulent de la maintenir dans le temps… ou pas.
Et des outils de conversion (en spip-cli par exemple pour un gros site complet) devront être fournis pour transformer et nettoyer au mieux de SPIP => Markdown, pour les gens qui veulent/peuvent faire l’effort de convertir leur site déjà existant (donc pas que pour les sites neufs à zéro).
@maathieu mais tout ça n’est pas du futur, tu peux déjà le tester : c’est déjà comme ça que fonctionne peu ou prou le plugin Markdown. Les contenus sont bien en MD dans les champs « texte » des articles, rubriques, etc.
Et sinon je suis d’accord avec @cerdic, même si on a repoussé plusieurs fois SPIP 5, il reste « dans pas trop longtemps » (notamment si on veut profiter de l’anniversaire).
L’éditeur WYSIWYG est un peu plus que POC, mais pas finalisé non plus, et aussi bien pour l’éditeur que pour la gestion du MD en PHP, il y a encore de nombreuses tâches + aussi attendre qu’assez de monde teste en plugin avant de pouvoir dire « on intègre dans une dist ».
Avoir un convertisseur générique fonctionnant pour tout objet (pas que article) et sachant scanner le site entier (tous les champs pertinents de tous les objets). Compatible spip-cli parce qu’au delà d’un petit site, ça prendra forcément un temps énorme à convertir tout.
Concevoir une infrastructure qui nous permet d’ajouter (déjà existant ou à coder nous) des extensions à la syntaxe de base, notamment pour tous les plugins qui avant ajoutait des syntaxes textwheel (couleurs… FAQ… todolist… colonnes… onglets… etc, ya un ptit paquet de plugins dans le genre).
Adapter les plugins en question à Markdown ET coder des extensions à l’éditeur WYSIWYG propre à chaque ajout
Gérer encore plus loin le multilinguisme dans un même contenu (= les balises « multi ») dans l’éditeur WYSIWYG, et au moins s’assurer que rien n’est bloqué. Soit en interne, soit en adaptant le plugin « multilang »)
In most my sites over the years a bit of HTML has entered the TEXTEs.
It’s a plus in my opinion that TextWheel transitions from its syntax to HTML. It allows for customization with simple HTML without entering the template layer for every single change. A few CSS classes here and there can be very helpful.
If this can be achieved (e.g. by moving HTML to a « html source »-modele or similar, then Markdown could handle its syntax + models (including html blocks).
Oui, je sais que c’est un gros chantier, mais bon, c’était un peu optimiste…
La piste des distributions est sûrement la bonne, pendant que les outils permettant la « mise à niveau » se concrétisent.
Est-ce que c’est déjà quelque chose de réalisable, techniquement ?
Est-ce qu’on peut produire aussi facilement qu’aujourd’hui une version de SPIP Classique et une MD ?
Je reconnais que je n’ai plus du tout le niveau pour suivre cet aspect là, tout ce qui tourne autour de et avec composer.
Basic Syntax | Markdown Guide says that many Markdown implementations allow for HTML elements. Since Spip syntax also allows for HTML elements it would be important to keep this in the new syntax
il me semble que l’expérience avec seenthis est prometteuse, surtout si flex est introduit dans spip lui-même. Il serait judicieux d’encourager ce genre de chantier, je pense ?
Hello,
est ce que la décision de proposer du markdown est définitivement actée?
Je lui reproche de ne pas être standardisé, il a plein de variantes qui fonctionnent à un endroit et pas un autre.
Il existe d’autres langages de balisages standardisés et ouverts, plus riches aussi qui n’ont pas ce problème.
Je crois qu’ici, comme le suggère @cerdic , la meilleure piste soit de fournir 2 distributions (une « legacy » et une en markdown pour les nouvelles installations). La marche forcée vers l’emploi de markdown en natif me semble être une gageure pour toutes et tous.
Oh non pas deux distributions… Mais pourquoi pas deux plug-ins de rendu ? On pourrait avoir un plug-in Syntaxe Spip et un plug-in Markdown. Et d’autres utilisateurs pourraient implémenter leur propre plug-in de rendu si ça les amuse. A l’installation on fournit un plug-in par défaut (eg. Markdown pour une nouvelle install Spip 5+ et Syntaxe Spip pour une migration vers 5). Ensuite l’utilisateur peut choisir. Reste la question de la conversion… Personellement je n’ai pas envie de me prendre la tête à convertir tous mes articles en Markdown et à vérifier que le processus n’a pas fait de bêtises ici ou là
NITF, DocBook, AsciiDoc, NewsML… Mais non ils sont peu utilisés et seulement dans des domaines de niche.
La syntaxe spip est assez riche, j’ai du mal à voir comment le markdown pourrait venir fournir un équivalent. Ou alors c’est markdown « spipisé » qui est envisagé.
En fait, quelle est la logique envisagée? A terme je veux dire? Remplacement de la syntaxe spip? Fournir une variante plus légère pour les gens qui se satisfont d’une struture plus simple tout en gardant la syntaxe spip pour les textes plus complexes?
Et clairement, pas motivé du tout non plus pour traduire tous mes articles en markdown… Donc si on pouvait avoir un truc customizable avec des plugins ça serait top.
