Un editeur WYSIWYM pour SPIP : WYMeditor

Ce que vous voyez est ce que vous voulez dire

Attention, page complètement obsolète, qui devrait être dépubliée : liens brisés, etc.

Attention ! Cette contribution modifie des fichiers du noyau de SPIP !

Même si elle a été testée par plusieurs utilisateurs nous ne pouvons garantir qu’il n’y aura pas d’effets secondaires dommageables sur votre SPIP. Conservez toujours les fichiers d’origine pour pouvoir revenir au noyau originel.

De plus, elle n’est compatible qu’avec une version précise de SPIP et sera perdue à la prochaine mise à jour : vous devrez donc recommencer.

L’objectif est d’avoir une édition sémantique du même type que celui permis par les raccourcis typographiques de SPIP, tout en ayant une édition plus visuelle.

Qu’est-ce que c’est ?

WYMeditor est un éditeur WYSIWYM (What You See Is What You Mean : Ce que vous voyez est ce que vous voulez dire), c’est à dire un éditeur sémantique.

L’objectif est d’avoir une édition sémantique du même type que celui permis par les raccourcis typographiques de SPIP, tout en ayant une édition plus visuelle.

WYMeditor en action

Pour l’instant, seul le champ texte des articles est éditable avec ce plugin. Les prochaines versions devraient permettre l’édition des champs ’texte’ pour des brêves et des rubriques.

Remarque : ce n’est pas un éditeur WYSIWYG : en particulier tout ce que permet le HTML n’est pas facilement faisable (pas plus facilement qu’avec l’interface SPIP habituelle).

Typographie SPIP :

L’insertion d’images est habituelle, il faut taper des liens du type : <img12|center>. Ce qui fait que le téléchargement habituel via l’interface de SPIP fonctionne. On peut toute fois insérer une image de manière plus visuelle si on connaît son url.

Les notes de bas de bas de page s’insèrent toujours via [[note de bas de page]]

De manière plus générale, le balises du type <xxx|yyy> fonctionnent comme d’habitude.

De la même manière les liens ([Titre->lien]) et ancres ([#ancre<-]) fonctionnent aussi. On peut toute fois utiliser une interface plus visuelle pour les liens.

Si on le souhaite (mais cela supprime d’intérêt du plugin) continuer d’utiliser : les enrichissements SPIP : gras, italique, titre, etc ...

Installation :

Télécharger :

Extraction dans le repertoire plugins, puis activation du plugin dans l’espace privé de spip.

Ce qui reste à faire :

  • les couleurs équivalentes à celles du couteau suisse (mais, est-ce bien utile),
  • des menus plus logiques,
  • prévoir une configuration du plugins via CFG (en particulier pour pouvoir changer la feuille de style),
  • permettre l’édition des brêves et des rubriques,
  • surement plein de choses.

Compatibilité :

Dans l’état, le plugin est compatible avez SPIP 2.0RC1.

De plus WYMeditor est compatible avec les navigateurs :

  • Internet Explorer,
  • Basés sur Gecko (Firefox, Seamonkey, Galeon, Epiphany...),
  • Safari,
  • Opera,
  • Google Chrome

WYMeditor :

Copyright (c) 2008 Jean-Francois Hovinne, http://www.wymeditor.org/ sous double licence :

  • MIT
  • GPL

Il y a un problème avec jQuery. Normalement, jQuery est chargé par SPIP. WYMeditor nécessite jQuery. Tout
devrait aller pour le mieux, mais WYMeditor nécessite aussi (si on veut que le composant puisse être
redimensionnable) jQuery.UI : il faudrait donc que SPIP permette d’ajouter des plugins jQuery. Dans
l’état actuel des choses, ce n’est pas le cas, donc j’ai choisi d’utiliser les plugins jQuery livrés
avec l’éditeur AVEC le jQuery de SPIP, cela peut surement poser des problèmes.

Discussion

9 discussions

  • Bonjour

    Inconditionnel de FCKéditor, je viens de tester WYMeditor : Whaou !

    Je le trouve excellent et plein de promesses.

    Je souhaite que vous puissiez mener à terme ce projet qui me semble allier, pour les non informaticiens, la facilité d’utilisation (FCK) et la compréhension de ce que l’on fait (wysiwym natif Spip, qui rebute souvent les simples utilisateurs).

    Bon courage pour la suite.

    jmfre

    Répondre à ce message

  • J’utilise ce plugin avec la version SPIP 2.0.2 [13532]. Il fonctionne nickel en local avec MAMP et pas sur mon site. Quelqu’un aurait-il une idée de la piste à creuser pour résoudre ce problème ?

    Merci d’avance

    Répondre à ce message

  • Comme Wysiwym, j’utilise Spip Typo (basé sur BBComposer) qui produit une syntaxe typographique Spip en sortie. Cependant, je sais qu’il permet aussi de sortir du XHTML 1.0 strict donc, c’est une bonne manière de proposer un wysiwym sans instaler un autre plugin supplémentaire.

    Pour enregistrer des raccourcis typo pour spip avec WYM editor, vous devriez demander à utiliser les fonctions de conversion de Spip Typo :
    http://www.bitbucket.org/nfroidure/spip-typo/src/tip/chrome/spip/content/spip.js

    ++

    Répondre à ce message

  • 9

    2 questions :

    • est-ce que le plugin enregistre bien des codes typo SPIP (pas <strong> mais bien {{ ?
    • est-ce que tu peux mettre ce plugin sur la zone afin de permettre à d’autres d’y travailler avec toi ?
    • faut arreter la psychose du code html enregistré dans la base ce n’est pas dramatique du tout si le code est valide et stylé uniquement en css. De plus, l’aspect wysiwym insiste justement à baliser son code sémantiquement plus qu’à faire de la mise en forme donc je ne vois pas où serait le problème

    • Il y a plusieurs problèmes :

      1. si le langage HTML évolue d’une manière non compatible, la conversion sera difficile.
      2. si on enlève le plugin, le code sera illisible
      3. (à vérifier) si l’éditeur n’est pas accessible à une personne aveugle, elle ne pourra pas travailler les textes dans SPIP (l’éditeur n’est pas activable auteur/auteur)
      4. la lecture d’une soupe de tag HTML + de balise SPIP (modèles) ne sera franchement pas une partie de plaisir...

      Un éditeur WYSIWYG pour SPIP ? peut être une ressource intéressante à lire...

    • Malheureusement non, ça enregistre du xHTML.

      Je n’ai rien contre mettre le plugins sur la zone, comment fait-on ?

    • Le language HTML est standardisé, en l’occurrence, ici il s’agit d’xHTML c’est tout ce qu’il y a de plus standard, ça ne risque donc pas d’évoluer de manière non compatible (avec quoi d’ailleurs)

    • l’idée de WYMeditor est justement de permettre l’enrichissement typographique avec des style css et pas autre chose à la manière des enrichissements spip. Mais en xHTML.

      Effectivement ça pose problème aux aveugles. C’est un souci. Je n’ai pas de solution.

      Pour le problème de la récupération de code spip : je pense qu’avec un peut de travail ça doit pouvoir se régler.

      Pour l’intégration à d’autres champs : c’est prévu.

    • Je vais prendre un exemple au hasard : xHTML 2.0 est *incompatible* avec xHTML 1.0. Si cette norme devait s’imposer, tous les sites bourrés d’html et d’xhtml 1.0 dans leur base seraient incapables de migrer.

      Mais l’argument plus général est effectivement qu’un outil comme cela, aussi génial soit-il (et je pense que WYM fait partie des bons) ne peut être imposés car inaccessible. Les rédacteurs doivent donc pouvoir éditer manuellement, avec raccourcis typos, leurs contenus. Qui doivent rester sous cette forme en base de donnée.

    • Cette incompatibilité est toute théorique.
      1) WYMeditor ne met que des tags : p, div, strong, em et table, aucun truc spécifique.
      2) la norme xhtml 2.0 est pratiquement complètement compatible avec xhtml 1.0 (du moins dans le sens 1.0 -> 2.0) cf : http://www.w3.org/TR/xhtml2/introduction.html#s_intro si tu regardes les différences, il n’y a que des ajouts. _

      Que WYMeditor ne peut être imposé : c’est une évidence. D’ailleurs c’est un plugin pas une proposition de patch pour SPIP. Par contre, je ne suis pas d’accord que les rédacteurs DOIVENT pouvoir éditer manuellement les raccourcis typos. Ça dépend du publique de rédacteurs à qui s’adresse ton site. _

      De plus, perso, je préfère éditer du xhtml que du spip même à la main, en particulier les tableaux pour lesquels franchemement le parseur de spip est nul : va mettre par exemple dans spip 1.9.2e (j’ai pas essayé dans la version 2.0 rc1) un tableau avec des retours à la ligne dans une cellule de tableau, ou une liste dans une cellule de tableau. Crise de nerfs garantie avant d’y arriver : faut être un pro de spip ! Perso, je trouve le xhtml plus consitant. Mais c’est un avis perso. Je ne prétends pas qu’il faille obliger tout le monde à éditer du xhtml. Je comprends parfaitement que tu (et d’autres) préfères le SPIP. Mais moi ce que j’aime dans spip, c’est : tout le reste. La mise en forme SPIP m’exaspère. _

      Donc je cherche une solution, j’ai un début de solution, je partage.

    • euh la xhtml 2.0 faut arrêter c’est mort et enterrer, quand bien même si tu as du xhtml propre tu peux le passer en xml.

      Le code illisible si plugin désactivé ? je vois pas trop pourquoi, c’est du xhtml.

      L’éditeur inaccessible il ne n’est pas moins que la barre typo de spip et apprendre à quelqu’un faire <h3> est pas franchement plus compliqué que {{{ par contre je t’accorde que la lecteur est plus fastidieuse bien que lire
      <modele|para=xxx|param=yyy|param=zzz> doit pas être très plaisant non plus.

    • Donc je cherche une solution, j’ai un début de solution, je partage.

      Et c’est super que tu partages ça.

      En retour, tu as de nombreuses réactions parce qu’il y a une forte attente depuis très longtemps sur ce sujet et que la réponse technique que tu y apporte est en décalage par rapport à ces attentes.

    Répondre à ce message

  • yakafaucon

    Bonjour,

    Je me permets d’apporter mon avis.

    Entre intégristes et révolutionnaires il doit y a avoir de la place pour trouver un consensus ;)

    Je suis en train de monter un site collaboratif à vocation régional. J’espère avoir donc des rédacteurs volontaires nombreux . Ceux ci ne connaissent en général qu’un éditeur de type Word et donc pas le SPIP dans le texte. Donc pour eux il me faut installer un éditeur WYSI*.
    Je veux offrir un espace de rédaction public mais un éditeur non WYSI fera fuir les bonnes volontés.

    Mais baser un article que sur des listes, du gras et de l’italique c’est TRES réducteur pour de la mise en page (j’exagère volontairement).
    Pouvoir rajouter de la couleur c’est bien et cela permet de clarifier le contenu et accentuer le fond. Il y a surement a regarder de ce coté là .

    Cela dit, un éditeur WYSIWIG doit forcement stocker sous un format natif (et donc se restreindre aux possibilités offert par celui ci), sous peine de rendre incompatible le contenu existant.
    Une idée ...il «  »« suffirait »« » de typer l’article en base et d’indiquer s’il est écrit en BBCODE, SPIP ou HTML par exemple et d’avoir le parser en face qui va bien....
    Traduire du SPIP en BBCODE ou l’inverse ce ne doit pas pas être sorcier, idem avec HTML. et d’appliquer le parser dans le bon sens et à l’écran, la mise en forme est nickel et appliquer un éditeur WYSI* est alors chose possible.

    Répondre à ce message

  • 3

    Une bonne idée que ce plugin. Il serait pertinent que vous vous branchiez avec Arnault qui a travaillé sur la barre typographique la Barre typographique généralisée
    et la Barre typographique multilingue.

    Répondre à ce message

  • Je viens de tester en activant la bête sur un site déjà existant.

    1. le plugin enregistre dans la base SPIP du xHTML et non des raccourcis SPIP
    2. les changements de paragraphe (lignes vides) ne sont pas pris en compte : tout l’ancien contenu se retrouve dans un seul paragraphe
    3. chaque fois que j’ai voulu passer à la ligne (FF3) l’éditeur me ramenait à la fin de la ligne précédente :(
    4. le code est un remplacement pur et simple de article_edit.php ce qui n’est franchement pas conseillé (de plus, ça rend cet éditeur uniquement utilisable pour les articles et pas ailleurs).

    Bref, en l’état, ce plugin est inutilisable pour moi (et pas seulement parce que je ne peux pas saisir plus d’un paragraphe.

    Répondre à ce message

  • Enfin dernière question. Votre éditeur produit du HTML ou bien du texte avec les raccourcis SPIP ?

    Répondre à ce message

  • En allant un peu plus loin, il faudrait voir comment faire fonctionner ensemble votre éditeur, l’extension aux autres champs, les onglets multilingues, les outils de la BT2 (comme les stats par exemple) et la possibilité à d’autres de s’y brancher pour rajouter d’autres fonctionnalités.

    Il me semble que tout cela mériterait une réflexion collective.

    Répondre à ce message

Ajouter un commentaire

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

Qui êtes-vous ?
[Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom