Un éditeur WYSIWYM pour SPIP : feuille de route et questions annexes

Dev
#1

Pour reprendre et compléter la discussion de Refaire un éditeur à base de CodeMirror + ajouts (#3720) · Tickets · spip / porte_plume · GitLab sur un éditeur WYSIWYG pour SPIP moderne et parce que le projet est lancé « pour de bon », je tente une synthèse pour essayer de faire une feuille de route accompagnée d’un certain nombre de points à discuter.
Pour les lecteurs pressés : « Help wanted » pour le comparatif des éditeurs

Cahier des charges :

En s’inspirant des éléments donnés dans ticket initial on pourrait le définir (grossièrement) par :

  • Dans l’éditeur avoir une vue avec le « vrai » rendu HTML c’est à dire proche de la mise en forme finale (avec les images, modèles, etc)
  • A minima, dans un premier temps, supporter en WYSIWYG tous les raccoucis typographiques de SPIP « de base » (= sans plugins autres que ceux du core) : soit les -*, {...}, <doc123> et autres tableaux ou notes de bas de page…
  • Supporter les variations de langue en <multi>
  • En parallèle, pouvoir intégrer sous leur forme « code » tous les modèles et raccourcis supplémentaires (= ceux amenés par les plugins)
  • Pouvoir « switcher » entre la vue WYSIWYG et la vue « code typographique »
  • Dans l’esprit de ce qui est fait avec Composer et les lib PHP : utiliser un éditeur ayant déja une communauté de développement conséquente, un « écosystème » de plugins, une API pour permettre « l’extensibilité »…
    …et le tout bien sûr en open-source !
  • Le code produit doit pouvoir se stocker correctement dans un champ TEXTE de la base de données
  • Toujours dans une optique de ne « pas réinventer la roue », l’idée serait de passer le code typographique par défaut de SPIP au format Markdown, dans sa version « étendue » CommonMark et/ou GitHub Flavored Markdown (GFM) telle que définie sur Extended Syntax | Markdown Guide (afin d’avoir le support des tableaux et notes de bas de page en particulier)

Choix de l’éditeur :

Le tableur Framacalc - tableur collaboratif en ligne devrait permettre de comparer un peu plus précisément les multiples éditeurs listés dans le ticket initial. Pour l’instant incomplet toutes les bonnes volontés sont les bienvenues pour le compléter tant au niveau des infos techniques que des « retours utilisateurs » !

Mise en oeuvre :

A priori la « version cible » serait SPIP 5 pour un éventuel plugin-dist en remplacement du Porte-plume mais d’ici là c’est d’abord un plugin pour SPIP 4 avec le plugin Mardown pour SPIP en « necessite » (configuré dans le mode « Syntaxe par défaut: MarkDown »). Dans les 2 cas l’utilisation de l’éditeur WYSIWYG impliquerait que le code généré par défaut dans le SPIP soit du MD
Dans les « tâches annexes » il y a (entre autre) :

  • la mise à jour de la lib PHP utilisée par le plugin « Markdown pour SPIP » en la remplaçant par celle de PHPLeague (https://commonmark.thephpleague.com/) comme signalé dans ce ticket Librairie MarkDown sous-jacente (#1) · Tickets · spip-contrib-extensions / markdown · GitLab
  • l’évolution du plugin « Insérer modèles » pour qu’il puisse être compatible MD et, à terme, devenir l’outil permettant l’insertion « quasi WySIWYG » des modèles dans l’éditeur
  • un « convertisseur » SPIP → MD pour permettre de passer l’intégralité d’un SPIP compatible avec l’éditeur. A noter qu’il ne s’agit pas de faire des « aller-retour » entre typo SPIP et typo MD mais uniquement de faire la conversion « une fois pour toute ». Dans l’idée un script cli pour permettre de traiter des volumes d’articles importants

Des points à discuter

  • Etant donné le fonctionnement actuel des éditeurs, faut il privilégier / imposer un éditeur fonctionnant « par blocs » ? (= édition bloc par bloc par opposition aux éditeurs « à l’ancienn » cad traitant l’ensemble du texte en une seule entité)
  • Quel « format pivot » ? Les éditeurs mis en test fonctionnent, dans leur majorité, en créant un contenu temporaire qui permet la génération de la vue WYSIWYG en HTML. Ce code sous-jacent constitue le « format pivot » (souvent du JSon). Au moment de l’enregistrement en BDD il sera transformé en « format de stockage » : en général soit du HTML soit du MD.

…et j’en oublie forcément mais l’intention n’est pas trop de tergiverser et couper les cheveux en 4 à l’infini mais plutôt de pouvoir trouver un consensus / base de développement opérationnel d’ici l’été !

5 « J'aime »
#2

Chouette projet.

Y a t il un exemple en ligne permettant de se rendre compte de l’édition « par blocs » ?

J’imagine que l’export du format SPIP vers md aura d’autres usages que pour cet éditeur, étant donné la démarche d’intégration progressive de SPIP à l’écosystème webdev ambiant.

#3

le plus « emblématique » me semble être TipTap, à tester sur https://templates.tiptap.dev/ ou (plus « classieux ») sa déclinaison GutenTap : https://gutentap.letsdance.agency/ qui permet aussi de visualiser le JSON « pivot » généré.

#4

Pour préciser, et comme je l’ai rajouté hier soir dans le tableur : TipTap contrairement à la plupart des autres, ne fournit aucune interface, c’est vraiment uniquement une API et seulement une API (c’est annoncé clairement « headless editor »).

C’est donc à chacun⋅e de construire une interface propre à son projet par dessus cette API. Ce qui peut être long suivant le niveau de fonctionnalités qu’on veut atteindre, si on part de 0 avec TipTap seul.

Il y a donc aussi des éditeurs avec interface basés sur TipTap (lui-même basé sur ProseMirror). Mais ces interfaces peuvent nécessiter plus d’autres libs. Par exemple le template est basé sur React. Tandis que GutenTap est basé sur Vue. Je n’ai pas encore trouvé d’interface déjà prête à l’emploi… mais uniquement basé sur du Vanilla.

Par contre si on crée nous-même notre interface, là TipTap (+ ProseMirror) fonctionne en Vanilla sans aucun problème, et c’est à nous d’ajouter des menus, boutons, drag-n-drop…

Un autre éditeur pas mal (mais qui n’est pas que headless, qui lui fournit bien une interface style block en React par défaut), a le même genre de chose pour Vanilla où faut implémenter l’interface graphique : Usage Without React (Vanilla JS) - BlockNote

L’un des points à décider ensemble est donc :

  1. évaluer à quel point c’est gros, lourd, long ou pas d’implémenter la partie interface
  2. si ça parait lourd, est-ce qu’on est prêt à dépendre d’un « gros » framework JS genre React Vue etc ?
  3. ou bien chercher uniquement un éditeur qui fonctionne en Vanilla avec interface de base, fut-il soit moins riche en fonctionnalités (l’éditeur de StackOverflow par ex, basé sur ProseMirror aussi), soit beaucoup plus complexe à manipuler (CKEditor à première vue)
1 « J'aime »
#5

Très réjouissant !
Merci pour l’annonce @cy_altern

S’il y a des choses précises à tester/explorer, on peut certainement dégager un peu de temps de notre côté (avec @bricebou)

Sur les sites existants, est-ce que cela supposera de migrer tous les contenus en markdown, ou il y aurait une cohabitation syntaxe SPIP/markdown ?
Si migration obligatoire, comment anticipez-vous la chose ? Est-ce qu’il y aura des points d’attention particulier ? Sur des vieux sites avec une grande base d’articles à la syntaxe parfois douteuse, on pourra s’attendre à une migration en douceur sans trop de difficultés ?

#6

À priori pour l’instant le but c’est de n’activer cet éditeur que quand c’est Markdown par défaut. Quand c’est la syntaxe SPIP, ça reste l’ancien porte-plume.

Dans le cadre des SPIP actuels, on a le porte-plume fourni en « dist », qui s’active sur le SPIP par défaut en syntaxe SPIP. Et en installant le plugin Markdown + le nouvel éditeur, ça remplacera.

L’idée à moyen/long terme serait possiblement d’inverser le défaut, et donc que SPIP fournisse Markdown et le nouvel éditeur dans la dist, et que le Porte-plume devienne un plugin normal à installer en plus quand on sait qu’on a un ancien site avec l’ancienne syntaxe.

Ce qui permettrait bien de garder les anciens sites tels quels sans avoir à migrer leurs contenus, mais en pouvant quand même continuer de mettre SPIP (et la plupart des plugins) à jour.

#7

Concernant la migration (à priori c’est là-dessus que je vais me concentrer), on peut supposer :

  1. tant qu’on est en SPIP 4 on fonctionne selon le principe du plugin « MD pour SPIP » : une option de config qui permet de choisir la syntaxe par défaut avec comme choix :
    • syntaxe SPIP + édition avec le porte-plume
    • syntaxe MD + édition avec l’éditeur MD
  2. de façon complémentaire il serait souhaitable de pouvoir choisir la syntaxe lors de l’édition d’un article : i.e. je suis sur un article ayant été rédigé avec la syntaxe SPIP je devrais pouvoir le rééditer avec le porte-plume (ou sans éditeur) si je souhaite simplement modifier le code SPIP existant

A partir de là, pour la migration plusieurs options semblent possibles :

  • option 1: pas de conversion des articles existants : ils restent « tels quels » et en cas de modification sont réédités en SPIP (avec ou sans porte-plume selon ce qu’il est techniquement possible de faire).
    Seuls les nouveaux articles sont en MD.
  • option 2: conversion de l’ensemble des contenus existant (à priori via un script cli) avec (forcément) le risque qu’on ait des pétouilles plus ou moins nombreuses selon le niveau de complexité des contenus et la qualité de leur code SPIP initial…
  • option 3: pas de conversion « en masse » de l’existant mais lors de l’édition d’un « ancien » article/contenu donner la possibilité d’appliquer la conversion vers MD et pour pouvoir les éditer en MD
    (dans l’idéal on pourrait imaginer que le script de conversion puisse prendre en charge un certain nombre d’options permettant de préciser (par ex) les secteurs/rubriques devant êtres convertis…)

A priori, pour permettre « l’adoption » de ce nouvel éditeur MD, j’ai dans l’idée de créer un script de conversion SPIP → MD, utilisable « en masse » en cli pour ceux qui souhaitent faire la migration complète. Dans l’idée, sur la base de ce script, il devrait être possible de l’utiliser pour proposer la conversion « au coup par coup » : on aurait donc un mix option 2 / option 3

2 « J'aime »
#8

Comme récemment avec l’action géo des images dans GIS, le découpage ça pourrait être d’avoir une action classique de SPIP en PHP qui fait que unitairement (si possible pour tout contenu objet/id_objet, dans ses champs de texte), genre action/convertir_spip2md.php avec arg=objet-id_objet. Ce qui permet toujours d’appeler l’action classique en web dans l’admin pour un seul contenu.

Et ensuite une commande CLI markdown:convertir l’appelle en masse pour X contenus d’affilés (sans option tous les contenus de tous les types, et option pour dire seulement telle liste de type d’objet par ex).

Sinon pour la stratégie des sites futurs, mon avis actuel pour l’instant c’est que :

  • soit veut pas se casser la tête ou on a peur que ça casse trop de choses, et on veut garder un SPIP existant avec l’ancienne syntaxe SPIP, et donc on met les plugins (devenus optionnels pas dist) qui vont bien, Porte-Plume etc pour reproduire le fonctionnement d’antan
  • soit on veut migrer, et c’est forcément 100% du site sur 100% des objets
  • mais pas un entre-deux avec un mélange de plusieurs choses à gérer dans le même site

Ça fait déjà deux possibilités, en continuant de garder les anciens fonctionnements. Mais ça reste plus simple à gérer que permettre des mélanges.

#9

Oui par pitié pas de Wordpress à moitié en Classic Editor, une seconde moitié en Gutenberg, une 3ème moitié en Divi, une 4ème moitié en WPBakery et j’oublie la 5ème moitié en Elementor au gré des fantasmes de chaque webmaster. :nauseated_face:

#10

Wysiwyg, le retour…

Après avoir vu couler beaucoup d’encre sur le sujet, c’est le retour de la soi-disant modernité, de l’argument qui manque à SPIP pour attirer le chaland, de la mode à suivre…

Je suis fondamentalement contre cette idée, bien que ça m’a trotté dans la tête pendant un certain temps, j’en suis revenu. 20 ans à résister aux quémandeurs de wysiwyg.

Le wysiwyg, c’est l’abandon du design du site avec son squelette et ces CSS, c’est la suppression des modèles de documents et donc une gestion fondamentalement différente des documents. Et pourquoi faire perdre du temps machine pour transformer même du MD en HTML, autant mettre directement le HTML dans le champ de la base, c’est plus simple et ça ne change rien. Même si je suis conscient que de mettre les adresses en absolu dans le HTML est une source de problème en cas de changement de domaine ou de répertoire.

Pour que le wysiwyg fonctionne, il faudrait brider le moteur aux fonctions utilisées dans SPIP et y associer le design du squelette donc une action provenant du moteur (core) et des plugins typographique et une autre action provenant des squelettes : grosse prise de tête en vue pour la configuration du module choisi. Y ajouter les mêmes fonctions que dans « media », sauf si déjà présentent.

Surtout que SPIP propose déjà une prévisualisation en direct dans l’éditeur et dans le cadre du site avec juste en haut de page un gros carré « Prévisualisation du message ».

Maintenant, c’est juste mon petit avis sur la chose, faite comme bon vous semble.

1 « J'aime »
#11

Je ne suis pas sûr que tu aies lu le ticket de départ sur la forge, et même le fil ici-même, avant d’écrire tout ça… :stuck_out_tongue:

Vu qu’il est clairement indiqué que le but est d’avoir un éditeur WYSIWYM (plutôt car pas les styles finaux du site public), qui enregistre en base dans une syntaxe non HTML (à priori MD pour ne plus maintenir une syntaxe perso alors qu’on peut se baser sur des libs super maintenues pour MD), et que ça doit toujours gérer les modèles et les balises multi de langue. Tout ça est indiqué me semble-t-il.

Donc que les documents sont bien insérés toujours pareil, notamment.

On ne parle pas d’un éditeur de HTML (avant TOUS les éditeur WYSIWYG étaient uniquement HTML) mais bien d’un éditeur de contenus quelconques qui utilise un format pivot (généralement du JSON) pour manipuler les données, et donc pouvoir ensuite exporter comme on veut dans un format final (qui peut être HTML… ou n’importe quoi d’autre…). Cela n’a rien à voir avec les éditeurs d’il y a 15 ans.

1 « J'aime »
#12

Désolé pour mon erreur d’interprétation mais le terme wysiwyg m’a fait voir rouge !!!

Je pense avoir compris le pourquoi de ces changements (code SPIP → Markdown(MD)) avec ajout du wysiwym.

Pour ma part, il faudrait, afin de convenir au plus grand nombre, le concevoir sous cette forme :

  • un plugin dist MD en remplacement du plugin dist porte plume (édition dans le champ texte du code MD brut, comme le code SPIP actuel).
  • un plugin wysiwym en addition non obligatoire en dist désactivable ou plugin normal ou dist supprimable (comme SVP).

Pour la mise à jour du code SPIP vers MD dans la base, pourquoi pas un plugin qui fait le travail pour toute la syntaxe SPIP core avec un pipeline que pourrait utiliser tous les plugins qui font de la typo. L’action sera donc non automatique mais par validation dans une page de config.

#13

Un traducteur SPIP vers MD des contenus, plugin indépendant, extensible, complet et précis, ça serait bien et ça permettrait de / ça serait une condition pour / envisager que MD devienne le format de SPIP.

Mais comment faire avec MD pour obtenir l’équivalent des modèles et basiquement gérer la diversité des insertions de documents ?

#14

« plugin traducteur » ou non, il semblerait que, quoiqu’il arrive, MD s’achemine pour devenir le format « par défaut » de SPIP 5…

Pour ce qui est des modèles : ceux « de base » de SPIP (<doc123|right> par ex) fonctionnent déjà avec le plugin « MD pour SPIP » existant : il suffit de les insérer tels quels dans le code MD, exactement comme dans le code SPIP.
Et pour l’éditeur MD l’idée pour être dans l’esprit WYSIWYM serait de pouvoir utiliser le plugin Insérer modèles alternativement à la saisie « à la mano » (ce qui revient grosso-modo à ce qu’il se passe actuellement avec le porte-plume)

#15

effectivement, il semblerait logique qu’un script de conversion SPIP → MD, ne gérant que la typo SPIP « de base », ait un pipeline permettant aux plugins qui font de la typo de venir faire leurs adaptations (ou suppressions !)
A partir de là les mainteneur·euse de ces plugins pourront produire (ou non) l’effort nécessaire pour que la conversion inclut leurs altérations de la typo SPIP…