Rich-text fields should be easier to implement

[bruno]

Currently dcCKEditor and dcLegacyEditor enable multiple editors for textareas.

However, when a plugin wants to implement its own rich-text fields, it quickly becomes a nightmare : dcLegacyEditor visual editor is only enabled if fields are sons of "edit-entry" and must be named post_excerpt or post_content. Otherwise lots of copy&paste of insane js are required.

Same thing for dcCKEditor, where rich text fields are currently quite hard to define.

Having a rich-text field shoud be as easy as adding a css class to this field (and eventually add a generic code on php side), and not borying about its id...

[franck]

le behaviour adminPostEditor est censé être utilisé pour définir la liste des éléments (a priori textarea) sur lesquels activer l'éditeur, pas besoin d'une classe supplémentaire.

[bruno]

Ok.

Dans ce cas il y a un bug dans dcLegacyEditor : dans le plugin pages, si je renomme l'id du div #edit-entry en autre chose, l'éditeur visuel en mode wiki ne s'affiche plus.

Et s'il suffit d'appeler le behavior adminPostEditor, pourquoi y a-t-il des traces de #post_excerpt et #post_content dans les js de dcLegacyEditor ?

[franck]

Pour le premier cas (div#edit-entry) probablement parce que page.php charge /js/_post.js et que le chargement de l'éditeur se fait sur cette div dans ce js.

Par contre la présence des #post_excerpt et #post_content n'est effectivement pas normale, il reste du boulot à faire de ce côté pour être totalement indépendant. Cela dit il va falloir voir comment gérer le changement de format et la conversion gérée par ce js de façon indépendante

[nikrou]

dcLegacyEditor, à ma connaissance fonctionne depuis la 2.7 aux mêmes endroits où il fonctionnait. Si on souhaite le mettre en place à d'autres endroits c'est la plaie comme tu dis.

En revanche, CKEditor se met en place plus facilement sur d'autres éléments que ceux prévus originellement, en utilisant le behavior adminPostEditor et en ciblant ces dits-éléments.

Après pour la présence des identifiants (#post_excerpt, #post_content et d'ailleurs #post_comment) ce n'est pas complètement propre, je l'avoue. La réelle question est plutôt : veut-on continuer à maintenir N éditeurs ?

[franck]

Pour la maintenance de dcLegacyEditor, je dirais qu'il faut au moins assurer le minimum pour que les syntaxes wiki soient correctement gérées (dotclear, markdown, …).

Pour le reste, on peut reporter à plus tard si c'est vraiment chiant à faire, mais ça veut dire qu'on quasi impose l'usage de dcCKEditor pour l'édition en XHTML C'est peut-être pas très acceptable ?

[philippe]

Il faut quand même continuer à proposer la possibilité d'ajouter une syntaxe alternative pour l'édition. Après, on pourrait probablement se passer de dcLegacyEditor pour le xhtml et ne conserver que le wiki, ce qui donnerait les choix suivants

1) Wysiwyg ou xhtml en mode source avec dcCKEditor

2) syntaxe wiki de Dotclear (ou autre comme Markdown ou Textile)

[bruno]

Replying to nikrou:

dcLegacyEditor, à ma connaissance fonctionne depuis la 2.7 aux mêmes endroits où il fonctionnait.

Sauf les quelques plugins qui supportaient des champs en rich text (gallery), je vois ça comme une régression. Je le rappelle, ça tombe en marche avec le plugin pages parce que c'est un copier-coller brut de post.php.

La réelle question est plutôt : veut-on continuer à maintenir N éditeurs ?

le maintenir, peut-être pas, faire en sorte qu'il marche à iso-fonctionnalités, certainement.

[franck]

Pour être exhaustif, signalons que dcLegacyEditor fonctionne aussi avec la description des catégories alors qu'il n'y a ni div #edit-entry, ni textarea #post_content ou #post_excerpt.

Cela dit ça n'enlève rien au travail qu'il faut faire dessus pour le rendre sinon élégant, a minima potable.