Dans le cadre de la refonte de l’administration de Dotclear un gros pavé s’est présenté lorsqu’il a fallu s’intéresser à l’éditeur, ou plutôt aux éditeurs disponibles (Wiki et XHTML). À ce jour aucun de ces deux petits éditeurs n’est vraiment accessible, essayez pour voir la navigation au clavier et c’est pourtant un des endroits où l’utilisateur de Dotclear passera le plus clair de son temps, normalement.
J’ai commencé à faire un peu le tour du Net pour voir ce qu’il se disait sur la question et si des réponses avaient été apportées. Eh bien, ça fait des années qu’on en parle et ça fait des années qu’on tourne autour. Conclusion, on a pas encore découvert LE module qui remplacerait avantageusement l’éditeur actuel, ni d’ailleurs ceux utilisés ailleurs — mais je n’ai peut-être pas fait un recensement exhaustif de l’offre disponible !
À ce sujet, d’ailleurs, je me demande aujourd’hui comment font les aveugles qui utilisent Dotclear pour éditer et publier leurs billets ? Connaissent-ils par cœur les différents codes Wiki utilisés par Dotclear ? Utilisent-ils le mode source XHTML et ce faisant comment basculent-ils dans ce mode ? J’ai pas mal de questions et pour l’instant peu de réponses.
Un groupe de travail a été constitué sur ce sujet par la société Atlassian, ceux qui fournissent l’hébergement de projets Mercurial via BitBucket, pour étudier un éditeur en particulier de ce point de vue : CKEditor. Ils ont l’air d’avoir pas mal avancé sur ce sujet et je me suis dit que s’ils avaient sélectionné cet éditeur, ce ne devait pas être tout à fait par hasard. Du coup je me suis un peu plus intéressé à celui-ci et il appert qu’il pourrait tout à fait constituer un début de solution.
Cela dit, il en existe d’autres. Sachant tout de même que les futurs postulants doivent tout de même permettre d’être embarqués dans Dotclear et donc dans une licence compatible avec la GPL, permettre une configuration suffisante pour assurer l’essentiel de ce qu’on propose déjà dans Dotclear, permettre de produire un code conforme et accessible, voire plus (extension via des extensions tierces, traduction de l’interface, …).
J’en ai listé quelques-uns ci-dessous, sans toutefois les avoir pour l’instant testés :
Et il en existe peut-être d’autres…
J’ai trouvé également une cheklist très intéressante pour commencer à évaluer ces éditeurs, mais peut-être faudra-t-il la remanier en fonction de nos besoins précis et j’aimerais qu’on — oui j’ai bien dit on — bosse un peu sur ce sujet et qu’on en ressorte, si possible, une ou plusieurs recommandations pour le développement et/ou l’adaptation et l’intégration d’un éditeur, voire de plusieurs pourquoi pas, au sein de Dotclear. Il est probable, si ce projet arrive à terme, qu’il soit également utile à d’autres systèmes de publication en ligne, alors ne boudons pas notre plaisir.
Êtes-vous intéressés, avez-vous un peu de temps à consacrer à cette étude, avez-vous déjà vu des études sur ce sujet ailleurs, … ? En un mot, ça vous cause ?
PS : Si vous n’avez pas le temps de participer mais que vous avez des billes ou des bribes d’infos sur ce sujet, n’hésitez pas à nous les communiquer, ça peut servir !
1 De jblanche -
Jamais testé mais j’ai plusieurs fois entendu du bien de Aloha Editor : http://aloha-editor.org/
Peut être à regarder également.
2 De Franck -
Je vais rajouter cet éditeur à la liste, jblanche, bien que celui-ci nécessite visiblement qu’on soit en HTML5, ce qui peut éventuellement donner un peu plus de travail pour basculer l’administration de Dotclear dans ce mode.
3 De Da Scritch -
Je suis de l’avis que pour dotclear, plus c’est léger, mieux c’est.
Pour mon service, j’ai customisé à fond TinyMCE. Mais le plus pénible a été de produire un unique document js pour limiter au maximum les rappels d’options et donc les lenteurs de l’interface. TinyMCE a un truc intéressant ; l’exploitation d’une CSS externe, puisque le rendu est dans une iframe.
Par contre, et c’est extrêmement pénible, ce sont toutes ses popups. Et pour étendre l’architecture d’un popup (disons pour faire votre propre gestionnaire de documents), c’est une sale horreur : pour avoir les JS de dialogue, il faut rappeler tout les éléments (css, etc…) .
CKeditor, je l’avais mis de côté (j’ai commencé mon système en 2008), il s’est peut-être très solidement amélioré.
Aloha est extrêmement prometteur par son code, par son côté novateur (pour une fois que les menu-ribbons à la Microsoft Office sont bien employés…), mais exige que le contenu soit DANS le document. Or, cela peut devenir très vite problématique pour des contenus élaborés : j’ai écrit sur mon blog des billets avec inclusions javascripts qui auraient immanquablement fait planter l’interface d’admin de Dotclear.
Ceci dit, je suivrais vos travaux avec une intention bienveillante.
4 De Franck -
Merci pour les retours Da Scritch, c’est toujours utile à savoir.
5 De Marc -
Incapable de te dire si je peux aider, pas sûr d’avoir les compétences, je veux bien tester à mort plein de trucs sur des blogs chez moi et faire des retours très précis. Donc voilà, si y’a besoin d’une poire pour se mettre au volant et conduire, je peux. En revanche, faire des plugins, là ça va pas être possible.
Pour le reste, depuis la première version de dotclear, tout, absolument tout en wiki. Je déteste les autres éditeurs, FCK editor, TinyMCE et Cie, je sais pas comment je me démerde, mais cela se termine toujours avec des erreurs….
6 De mathieu -
Au cours du développement d’interface d’administration pour des clients, j’ai testé quelques uns des éditeurs cité dans le billet …
Dans tout les cas j’ai eu des problèmes en retour
Au final celui que j’ai retenu est CKEditor. Les possibilités sont très larges, l’intégration est simple et le code généré est correcte (même si en cas d’édition répété et d’utilisation massive de changement de taille de police, d’application de couleur et autre joyeuseté du genre on arrive vite à des choses forcément du meilleur gout).
Par contre je déconseille vivement TinyMCE. Non pas qu’il soit mauvais bien au contraire, il est plutot bon et possède des options de nettoyage de code qui donne de très bon résultat. Mais il possède un module de gestion de documents permettant de passer en ligne des fichiers images, pdf et tout ce que vous voudrez seulement j’ai eu la très mauvaise surprise de me faire attaquer des serveurs par le biais de faille dans ce module (faille persistante même après mise à jour). Il est possible que la version actuelle n’ait plus de faille connu, mais cette très mauvaise expérience m’a incité à abandonnée cet éditeur qui me donne l’impression de stagner depuis quelques années.
7 De Franck -
Merci mathieu de venir ainsi confirmer le bien que j’ai lu à propos de CKEditor et d’avoir signalé la potentielle faille persistante pour TinyMCE.
8 De Da Scritch -
Mathieu, je dois t’avouer que j’ai même pas songer utiliser le gestioonnaire de documents de TinyMCE : j’ai préféré écrire le mien. Et c’est là que j’ai pleurer : en utilisant l’interface en mode “advanced”, il faut que tu appelles le <head> du style advanced pour prendre les librairies javascript qui te seront utiles pour dialogues avec la session tinymce.
Mais je dois avouer une chose : j’ai pas franchement chercher très très loin de ce côté.
Dans tous les cas, les éditeurs Wysiwyg comptent sur le parseur html de chaque navigateur, avec du patch au taquet. Il faut impérativement garder la possibilité de repasser en mode “brut”.
Dernier point : tous les BBCode et compagnie, je trouve ça insupportable. Il faudrait que j’écrive sur mon blog les inconvénients. Mias je comprends que les non poweruser en ont besoin.