Salut a tous,

Pour mon premier site j'ai programme moi-meme la partie administration au lieu d'utiliser un CMS (c'est bien la derniere fois que je fais ca vu le temps enorme que ca prend). Pour la creation de contenu j'utilise l'editeur JS gratuit OpenWYSIWYG (openwebware.com).

Mon probleme est que le code de mise en page cree par cet editeur est bizarre et differe selon le browser utilisé lors de la redaction du contenu (Chrome met des <DIV> la ou FF met des <P> !!??). Parfois je me retrouve par exemple avec des "white-space : pre" qui detruisent le layout de la page.

Premiere question : est-ce que ca vient vraiment de l'editeur ou est-ce un probleme plus general ? Si c'est l'editeur, est-ce que d'autres editeurs comme FCK editor pourraient faire un meilleur job ?

Ensuite : est-il possible d'utiliser l'editeur de Wordpress ou autre CMS ?

Et enfin : il m'arrive de partitionner certains articles en plusieurs pages. Pour cela j'introduis dans le texte de l'article des balises Smiley next . Le probleme est que si le Smiley next est placé par exemple entre la balise ouvrante et la balise fermante d'un DIV, le layout de la page est totalement bousillé. Je dois donc passer un temps fou a checker le code HTML de l'article. Ma question : comment diable font les CMS pour resoudre un tel probleme ?
Modifié par apericube (05 Sep 2009 - 14:39)
Salut,

Je crois que le meilleur éditeur WYSIWYG est tinyMCE, qui est utilisé par WordPress et Joomla entre autre.
matmat : Oui j'avais deja repéré tinyMCE qui a effectivement l'air tres bien, mais je l'ai pas choisi parce qu'il ne gere pas l'upload d'image (pour ca il faut acheter un plug-in).
FCK Editor a été réécrit récemment. La nouvelle version se nomme CKEditor et est plutôt convaincante. Cependant, comme pour TinyMCE, la société qui développe cet éditeur WYSIWYG a un modèle commercial qui repose en partie sur la vente de licences pour un deuxième outil: le gestionnaire de fichiers (que l'on peut lier à l'éditeur).

Tu as aussi la possibilité de coder ton propre gestionnaire de fichiers, ou d'en utiliser un existant, et d'utiliser l'API de CKEditor (ou celle de TinyMCE, je suppose) pour le faire fonctionner avec l'éditeur. J'ai fait ça récemment avec TinyMCE et django-filebrowser (sur un site développé avec Django, donc).
apericube a écrit :


Et enfin : il m'arrive de partitionner certains articles en plusieurs pages. Pour cela j'introduis dans le texte de l'article des balises Smiley next . Le probleme est que si le Smiley next est placé par exemple entre la balise ouvrante et la balise fermante d'un DIV, le layout de la page est totalement bousillé. Je dois donc passer un temps fou a checker le code HTML de l'article. Ma question : comment diable font les CMS pour resoudre un tel probleme ?


Peut-etre peut tu imposer a tes div ou paragraphe , form , etc .... , un : border:dashed 1px gray; pour les visualisé en mode edition , quelque soit l'editeur que tu utilise.

Le code html généré n'est effectivement pas convaincant et diffère selon le navigateur minuscule contre majuscule dans IE , comme dit precedement mieux vaut te tourner vers un autre editor .

Sauf erreur ou incomprehension de ma part , les version de fckeditor (anterieur a ckeditor) embarque un gestionnaire de fichier utilisable .

Il ya même une version de tinyMCE , nommée tinyFCK qui embarque le gestionnaire de fck . http://p4a2.crealabsfoundation.org/tinyfck .
A verifier quand même que les licences respectives le permettent

GC
Modifié par gc-nomade (15 Sep 2009 - 02:20)
apericube a écrit :
FloreEeEeent repondez s'il vous plait !

CKEditor est la nouvelle version (réécrite) de FCKEditor. Les avantages sont quelques nouvelles fonctionnalités, des bugs corrigés, une apparence plus moderne, une vitesse de chargement très largement améliorée, etc.

Par ailleurs, et très amicalement: RTFM & STFW. Smiley smile

apericube a écrit :
Et enfin : il m'arrive de partitionner certains articles en plusieurs pages. Pour cela j'introduis dans le texte de l'article des balises next . Le probleme est que si le next est placé par exemple entre la balise ouvrante et la balise fermante d'un DIV, le layout de la page est totalement bousillé.

Solutions possibles:
1. Ne pas mettre de balises DIV dans le contenu via un éditeur WYSIWYG. C'est donner le baton pour se faire battre. S'il s'agit de contenus saisis par un utilisateur non expert, il peut être utile de filtrer le code HTML saisi pour supprimer les éléments DIV (pas leur contenu). Certains éditeurs WYSIWYG font ça.
2. Parser le code du contenu pour s'assurer que la balise est en dehors d'un DIV. Si ce n'est pas le cas, la placer automatiquement après la balise </div> concernée. Beaucoup de fun avec les regexp en perspective. Smiley smile
3. Comme le suggère gc-nomade, rendre visible les différents éléments de type bloc. WYMeditor fait ça par défaut. CKEditor le propose comme fonctionnalité, et on peut peut-être le configurer pour activer cette fonction par défaut.
4. Proposer des champs d'édition de contenu ou des pages séparées pour les différentes pages d'une ressource. Bref, gérer les ressources multi-pages explicitement dans le CMS.

apericube a écrit :
comment diable font les CMS pour resoudre un tel probleme ?

Solutions #1, #2 ou #4, suivant les cas. Ou bien ils ne proposent pas de fonction de découpage en plusieurs pages.
Modifié par Florent V. (15 Sep 2009 - 13:22)