Geekographie Maïeulesque

Vous pouvez utiliser (C)Keditor

Maïeul — 2011-02-20T12:50:17Z

Il y a quelque temps, j'avais posté un message extrêmement critique vis à vis de de (F)CKeditor. Je révise ici mon jugement, suite au dernier article publié sur Contrib.

Je continue à penser que (F)Ckeditor est une mauvaise idée parce qu'il incite à penser forme et non sens. Je continuer à penser que l'apprentissage des raccourcis typographiques de SPIP a plus de sens, même si cela peut prendre un peu plus de temps (et encore).

Pour autant, la dernière contribution enlève une de mes critiques majeures, en fait ma critique majeure, à savoir que (F)Ckeditor produit du HTML et non pas du code SPIP.

En effet, il est désormais possible de dire à (F)Ckeditor de produire du SPIP et non pas du HTML. Ce qui à l'avantage :

de permettre une conversion plus simple vers d'autres formats.
de permettre de se passer de CKeditor le cas échéant.
de pouvoir utiliser les crayons.

Je n'ai pas testé, mais je fais confiance à l'auteur de l'article. Reste à savoir comment nettoyer une base qui a été salie par les anciennes versions du plugin.

N'utilisez pas (F)CKeditor !

Maïeul — 2011-01-30T19:11:58Z

Les différentes variantes du plugin (F)CKeditor de SPIP ont un certain succès. Ainsi, si j'en crois le site des statistiques SPIPiennes, près de 11% des sites SPIP l'utiliseraient, ce qui prouve qu'il y a demande.

Pourtant, c'est un très mauvais choix technique. L'expérience que j'ai eue avec tous ceux qui l'ont installé me le confirme : s'il semble plus pratique au début, il entraîne rapidement des soucis.

Une confusion des genres

Pourquoi utiliser ce plugin ? Deux raisons sont principalement évoquées :

permettre aux utilisateurs de ne pas avoir à apprendre les raccourcis typographiques de SPIP.
permettre aux utilisateurs de personnaliser l'apparence de leur article.

Je passe sur la première raison, étant donné que je dirais quelques alternatives.

La seconde raison est très mauvaise :

Elle incite à confondre sens et manière de présenter.
Elle incite à se concentrer non pas sur le contenu d'un article, mais sur la manière dont il sera présenté.
Elle a pour conséquence, bien souvent, d'obtenir un site dont l'unité graphique n'est plus assurée, ce qui produit au mieux des chocs visuels, au pire des crises d'épilepsies.

Autrement dit, elle rend inutile le travail du toilemestre. Elle rend même inutile la logique d'un CMS, puisqu'un CMS est là justement pour distinguer le travail de rédaction, qui relève des rédacteurs (si si !) et celui de présentation du contenu, qui relève du webmestre.

Ainsi une des conséquences pourra être que le rédacteur confonde, par exemple un intertitre et un texte « grosse police rouge ».

Une base de donnée bousillée

Ce type de plugins n'utilise pas les raccourcis typographiques de SPIP, mais introduit directement du HTML dans la base de donnée.

Conséquence :

un HTML bien souvent foutoir et illisible, impossible à « épurer » simplement, par exemple le jour où l'on décide d'avoir un site à l'allure cohérente.
l'absence d'abstraction entraîne une conversion plus difficile vers des formats autres que le HTML (LaTeX, XML et j'en passe).
l'absence d'abstraction rend tout changement beaucoup plus complexe.

Exemple du troisième point : alors que le système des documents de SPIP affecte un numéro à chaque document, numéro qui est appelé dans le texte grâce au raccourci . Il est ainsi possible d'appeler plusieurs fois un même document dans divers articles, puis de modifier une seule fois ce document et que cela se répande sur tous les articles. ~~Ce n'est pas du tout possible avec FCKeditor~~. En fait c'est possible avec la dernière version du plugin. Si le plugin s'améliore afin d'utiliser les raccourcis de SPIP et non pas du HTML, ma critique tombera à l'eau.

La perte des crayons

Et oui, il est impossible d'utiliser avec cela le plugin Crayons. Or ce plugin est incontestablement un très bon plugin et une aide précieuse pour le maintien d'un site, puisqu'il permet d'éditer le contenu sur le site public.

Si on essaye de crayonner un article créé avec CKeditor, on obtient alors une catastrophe, puisque le HTML apparaît dans le formulaire.

Quelles alternatives ?

Apprendre les raccourcis typographiques de SPIP n'est pas la mer à boire et permet aussi de se concentrer sur le sens. On pourra même obtenir un tableau récapitulatif : http://www.uzine.net/IMG/pdf/doc-273.pdf. Et le temps pour un webmestre de formation des rédacteurs sera largement compensé par le non-temps passé à démêler le HTML produit par CKEditor.
On pourra utiliser le porte-plume qui offre une barre typographique produisant des raccourcis SPIP, propre. Et les extensions du porte-plume permettront de combler certains manques.
On pourra également utiliser le plugin Odt2SPIP qui permettra de convertir un fichier Openoffice structuré selon le sens en article SPIP.
Pour la gestion des documents, on utilisera avec pertinence le plugin médiathèque, éventuellement en conjonction avec la Médiabox.

Cet article aurait pu être publié sur Contrib … mais celui-ci n'a pas pour but d'engendrer une polémique.

On lira également mon article suite aux modifications apportées dans le code de (F)CKeditor.

Champ extra, crayons, sqlite

Maïeul — 2010-12-07T16:59:00Z

Pour un projet associatif, j'utilise une base de donnée SQLite que je gère via SPIP.

J'ai ajouté à la table spip_articles de SPIP un champ extra, et je souhaitais pouvoir l'éditer via les Crayons.

Voilà comment j'ai procédé, une fois le champ extra ajouté.

Pour rendre éditable le champs (que j'appel ici #CHAMP) via les crayons, rien de plus simple.


#CHAMP

Seulement voilà : j'obtenais lors de l'édition, non un textarea mais un simple input, ce qui pour rend l'édition compliqué, puisque le contenu du champ peut faire plusieur ligne.

Le plugin crayon définit le type de champ de formulaire, appelé « Contrôleurs » affiché selon le type du champ SQL. Pour les champs de type TEXT, cela dépend de la longueur.

Seulement voilà, en SQLite, les champs de type TEXT ne peuvent avoir qu'une seule longueur. Il n'y a pas de TINYTEXT ou de MEDIUMTEXT ou autre BIGTEXT. C'est pourquoi j'avais systématiquement un input, et non pas un textarea.

Les crayons ont un contrôleur et une vue [1] par défaut pour les champs extra, mais on peut en définir des nouveaux pour chaques types de champ.

Le contrôleur

Dans mon dossier de squelettes [2], j'ai créé un dossier controleurs, dedans un squelette champ.html, qui contient ceci

[(#REM) Controleur pour le crayon 'champ' , uniquement html ]
#CACHE{0} 
 [(#CHAMP**)]

La vue

Idem, dans mon dossier de squelettes, j'ai créé un dossier vues. Et dans ce dossier un fichier champ.html, qui contient

[(#REM) Vue pour le crayon 'champ' ]
#CACHE{0}

[(#CHAMP|propre)]

Et voilà, j'ai désormais mes crayons qui me permettent d'éditer un champ texte long avec une base SQLite.

J'ai choisi d'utiliser SQLite

Pour économiser une base MySQL chez L'Autre.net, qui limite le nombre à six par adhérents
Parce que je n'avais pas besoin d'une base MySQL, étant donné que seulement cinq personnes peuvent la consulter, et que donc les performances ne sont pas vraiment en jeux.
Parce qu'il est plus simple de récupérer par FTP le fichier SQLite que de passer par PhpMyAdmin pour faire un export [3].

[1] i. e. ce qui est affiché après la modification d'un champ via les crayons.

[2] Qui est sous forme de plugin, .cf mon article « Jeux de squelettes sous forme de plugin ».

[3] SQLite ne fonctionne pas selon un schéma client/serveur, mais avec un fichier local. Cause, en partie, de ses faibles performances.