Bonjour la liste.
Je viens de m'inscrire parce que ça fait 2 fois qu'on me demande de mettre sur
le SVN de la zone le plugin que j'ai écris : FCKeditor/CKeditor pour spip
2.0.x :
http://www.spip-contrib.net/ecrire/?exec=articles&id_article=3220
Comment faut-il que je procède ?
D'avance merci.
Fred.
PS: j'ai essayé de lire les archives de la liste mais j'obtiens uniquement :
Site temporarily unavailable (maintenance)
J'espère que c'est bien temporaire.
* Frédéric Bonnaud tapuscrivait, le 03/10/2009 11:51:
Bonjour la liste.
Je viens de m'inscrire parce que ça fait 2 fois qu'on me demande de mettre sur le SVN de la zone le plugin que j'ai écris : FCKeditor/CKeditor pour spip 2.0.x :
SPIP-ContribComment faut-il que je procède ?
En ne mettant SURTOUT PAS CKeditor en entier sur la zone : SPIP a un mécanisme de chargement de library pour éviter de surcharger la Zone.
(FCKeditor et les autres outils WYSIWYG plombent déjà trop la Zone !)
Et plus généralement, à moins que tu ais trouvé un truc génial pour gérer :
- [->12]
- [[note de bas de page]]
- <modele...>
- <html></html>
Tout éditeur WYSIWYG est une perte majeure de fonctionnalité et d'évolutivité pour SPIP.
Autre challenge : réussir à continuer à enregistrer dans la base de SPIP des raccourcis typo et surtout pas du HTML.
PS : par contre, si tu as des connaissances en jQuery, PortePlume et les Enluminures Typos V3 auraient bien besoin de ton aide...
--
RealET
Le samedi 03 octobre 2009 12:04:47, RealET a écrit :
En ne mettant SURTOUT PAS CKeditor en entier sur la zone : SPIP a un
mécanisme de chargement de library pour éviter de surcharger la Zone.
Je comprends bien le problème, mais pour l'instant, j'ai pas de temps pour
cela (ça me semble assez complexe faire en sorte que le plugin downloade
ckeditor à l'installation), donc le plugins ne sera pas sur la zone.
J'ai supprimé du plugin : tous les exemples, toutes les sources et n'ai laissé
que ce qui est nécessaire au fonctionnement de CKeditor.
Pour l'instant, le plugin CKeditor pèse 3.0Mo (771K compressé) à comparer aux
1.7Mo (440K compressé) du couteau_suisse
C'est effectivement beaucoup. Mais ça ne représente que 2x le poids d'un plugin
comme le couteau_suisse.
Mais je comprends que ce soit trop important.
(FCKeditor et les autres outils WYSIWYG plombent déjà trop la Zone !)
Et plus généralement, à moins que tu ais trouvé un truc génial pour gérer :
- [->12]
- [[note de bas de page]]
- <modele...>
- <html></html>
Je ne pense pas que ce soit génial, mais pour les 3 premiers c'est
possible/utilisable pour [->12] et consorts ainsi que <modeles...> (ça
nécessite une conversion du code généré par CKeditor prévu par le plugin).
Pour les notes de bas de page, vue que ce n'est pas une balise html/xhtml/xml
CKeditor les laisse tel que, donc on peut les utiliser.
Pour la balise <html> je ne la connaissais pas, je vais regarder ce qu'elle
fait.
Tout éditeur WYSIWYG est une perte majeure de fonctionnalité et
d'évolutivité pour SPIP.
Je connais la rengaine, je comprends cette opinion, mais je ne suis pas
d'accord et ne suis pas le seul. Il n'y a qu'à regarder le nombre de personnes
qui recherchent ce type de plugin. Il y a un besoin/une envie pour un tel
plugin. Et plusieurs personnes n'ont pas besoin de la fonctionnalité que tu
décris.
Dans CKeditor il est possible d'insérer une image de spip en utilisant une
boite de dialogue ET en utilisant le mécanisme des documents spip. De même il
est possible d'insérer un lien vers un articles/une rubrique/un brève spip en
la choisissant dans une liste présentant les titres (plutôt qu'un numéro)
Pour les autres modèles, il suffit de les autoriser en configurant correctement
le plugin.
Autre challenge : réussir à continuer à enregistrer dans la base de SPIP
des raccourcis typo et surtout pas du HTML.
sauf que SPIP autorise le html, si le HTML c'est si mal, pourquoi ne pas
utiliser strip_tags sur ce qui rentre dans SPIP pour le supprimer complètement
sans autre forme de procès.
Bref dans un article spip on peut mettre du HTML mais toi tu jettes l'anathème
sur le html. Ça ne me parait pas cohérent. Tout le monde ne recherche pas
forcément un spip qui utilise des raccourcis typo, une mise en page limité à
ce qui est prévu par spip, une mise en page sémantique etc...
L'un des intérêts de spip est son système de plugin, il permet de faire de
spip ce que chacun désire et pas seulement ce que TU désires.
Bref, rien ne t'oblige à utiliser ce plugin si tu veux utiliser la mise en
page/en forme spip. Mais ceux qui le désirent le peuvent.
Une différence entre toi et moi, c'est que moi je propose un truc pour spip
laissant chacun libre de l'utiliser ou pas (je ne propose pas, je ne demande
pas de modifier le core de spip), toi tu veux imposer aux autres tes vues. Je
pense que cette forme d'intégrisme, désolé pour le vocabulaire mais je n'en
trouve pas de meilleur, fait végéter le libre.
PS : par contre, si tu as des connaissances en jQuery, PortePlume et les
Enluminures Typos V3 auraient bien besoin de ton aide...
Sauf que dans le cadre où j'utilise spip, il me faut un éditeur WYSIWYG et le
système d'édition de spip ne me convient pas (ne t'en déplaise), d'où le
développement de ce plugin. Je ne suis pas développeur, je développe ce que je
développe par plaisir, et moi ce qui me faisait plaisir c'était d'avoir un
spip avec un éditeur 'fashion' pour attirer des élèves dans le club info de
mon collège.
Bon désolé pour le ton, je me rends compte que j'ai été un peu agressif, mais
je défends mon bébé 
Amicalement,
Fred.
* Frédéric Bonnaud tapuscrivait, le 03/10/2009 13:11:
Le samedi 03 octobre 2009 12:04:47, RealET a écrit :
En ne mettant SURTOUT PAS CKeditor en entier sur la zone : SPIP a un
mécanisme de chargement de library pour éviter de surcharger la Zone.Je comprends bien le problème, mais pour l'instant, j'ai pas de temps pour cela (ça me semble assez complexe faire en sorte que le plugin downloade ckeditor à l'installation), donc le plugins ne sera pas sur la zone.
J'ai supprimé du plugin : tous les exemples, toutes les sources et n'ai laissé que ce qui est nécessaire au fonctionnement de CKeditor.
Pour l'instant, le plugin CKeditor pèse 3.0Mo (771K compressé) à comparer aux 1.7Mo (440K compressé) du couteau_suisse
C'est effectivement beaucoup. Mais ça ne représente que 2x le poids d'un plugin comme le couteau_suisse.Mais je comprends que ce soit trop important.
(FCKeditor et les autres outils WYSIWYG plombent déjà trop la Zone !)
Et plus généralement, à moins que tu ais trouvé un truc génial pour gérer :
- [->12]
- [[note de bas de page]]
- <modele...>
- <html></html>Je ne pense pas que ce soit génial, mais pour les 3 premiers c'est possible/utilisable pour [->12] et consorts ainsi que <modeles...> (ça nécessite une conversion du code généré par CKeditor prévu par le plugin).
Pour les notes de bas de page, vue que ce n'est pas une balise html/xhtml/xml CKeditor les laisse tel que, donc on peut les utiliser.Pour la balise <html> je ne la connaissais pas, je vais regarder ce qu'elle fait.
Tout éditeur WYSIWYG est une perte majeure de fonctionnalité et
d'évolutivité pour SPIP.Je connais la rengaine, je comprends cette opinion, mais je ne suis pas d'accord et ne suis pas le seul. Il n'y a qu'à regarder le nombre de personnes qui recherchent ce type de plugin. Il y a un besoin/une envie pour un tel plugin. Et plusieurs personnes n'ont pas besoin de la fonctionnalité que tu décris.
Dans CKeditor il est possible d'insérer une image de spip en utilisant une boite de dialogue ET en utilisant le mécanisme des documents spip. De même il est possible d'insérer un lien vers un articles/une rubrique/un brève spip en la choisissant dans une liste présentant les titres (plutôt qu'un numéro)
Pour les autres modèles, il suffit de les autoriser en configurant correctement le plugin.Autre challenge : réussir à continuer à enregistrer dans la base de SPIP
des raccourcis typo et surtout pas du HTML.sauf que SPIP autorise le html, si le HTML c'est si mal, pourquoi ne pas utiliser strip_tags sur ce qui rentre dans SPIP pour le supprimer complètement sans autre forme de procès.
Bref dans un article spip on peut mettre du HTML mais toi tu jettes l'anathème sur le html. Ça ne me parait pas cohérent. Tout le monde ne recherche pas forcément un spip qui utilise des raccourcis typo, une mise en page limité à ce qui est prévu par spip, une mise en page sémantique etc...
L'un des intérêts de spip est son système de plugin, il permet de faire de spip ce que chacun désire et pas seulement ce que TU désires.
En l'occurrence, je désire un vrai plugin WYSIWYG pour SPIP, pas un n-ième générateur de HTML qui rend la relecture impossible/difficile à un administrateur du site qui serait aveugle (l'exemple est tiré de mon vécu).
Bref, rien ne t'oblige à utiliser ce plugin si tu veux utiliser la mise en page/en forme spip. Mais ceux qui le désirent le peuvent.
Une différence entre toi et moi, c'est que moi je propose un truc pour spip laissant chacun libre de l'utiliser ou pas (je ne propose pas, je ne demande pas de modifier le core de spip), toi tu veux imposer aux autres tes vues. Je pense que cette forme d'intégrisme, désolé pour le vocabulaire mais je n'en trouve pas de meilleur, fait végéter le libre.
Désolé d'avoir paru intégriste.
Pour la petite histoire, un éditeur WYSIWYG pour SPIP, ça fait des années que j'en rêve.
Et puis j'ai fait l'expérience dans certaines administrations des dérives possibles suite à l'utilisation d'un outil WYSIWYG.
Tu me parle d'intégrisme.
Je te répond expérience et sagesse.
Mais comme disais confucius, l'expérience est une lanterne que l'on porte dans le dos : elle éclaire le chemin parcouru.
PS : par contre, si tu as des connaissances en jQuery, PortePlume et les
Enluminures Typos V3 auraient bien besoin de ton aide...Sauf que dans le cadre où j'utilise spip, il me faut un éditeur WYSIWYG et le système d'édition de spip ne me convient pas (ne t'en déplaise), d'où le développement de ce plugin. Je ne suis pas développeur, je développe ce que je développe par plaisir, et moi ce qui me faisait plaisir c'était d'avoir un spip avec un éditeur 'fashion' pour attirer des élèves dans le club info de mon collège.
Et est-ce que ça marche d'attirer les élèves de cette manière là ?
Bon désolé pour le ton, je me rends compte que j'ai été un peu agressif, mais je défends mon bébé
Tout à fait normal de défendre un bébé
PS : une lecture pour la route : Un éditeur WYSIWYG pour SPIP ? - Pyrat.net – Création de sites Internet
--
RealET
Le 03/10/2009 13:11, Frédéric Bonnaud a écrit :
Le samedi 03 octobre 2009 12:04:47, RealET a écrit :
En ne mettant SURTOUT PAS CKeditor en entier sur la zone : SPIP a un
mécanisme de chargement de library pour éviter de surcharger la Zone.
Oui, ça serait vraiment gentil 
Je comprends bien le problème, mais pour l'instant, j'ai pas de temps pour
cela (ça me semble assez complexe faire en sorte que le plugin downloade
ckeditor à l'installation), donc le plugins ne sera pas sur la zone.
Taratata !
http://programmer.spip.org/Installer-des-librairies-externes
<necessite id="lib:nom" src="adresse du fichier zip" />
Donc je suppose vu le zip :
<necessite id="lib:ckeditor" src="http://download.cksource.com/CKEditor/CKEditor/CKEditor%203.0/ckeditor_3.0.zip />
Ou peut être (mais je pense pas)
<necessite id="lib:ckeditor_3.0" src="http://download.cksource.com/CKEditor/CKEditor/CKEditor%203.0/ckeditor_3.0.zip />
----
Sinon, quelques autres remarques :
Dans un squelette :
[(#CONFIG{ckeditor/insertall}|oui) le code ]
<a href='[(#URL_PAGE{select_flash}
|parametre_url{article,#ENV{article}}
|parametre_url{param,valeur})]' …
----
Dans tes fonctions :
Totalement inutile en SPIP 2 :
if (!defined('_DIR_PLUGIN_CKEDITOR')){
$p=explode(basename(_DIR_PLUGINS)."/",str_replace('\\','/',realpath(dirname(__FILE__))));
define('_DIR_PLUGIN_CKEDITOR',(_DIR_PLUGINS.end($p)."/"));
}
----
include_once (_DIR_PLUGIN_CKEDITOR."ckeditor/ckeditor.php") ;
=> certainement
include_once (_DIR_RACINE ."lib/ckeditor/ckeditor.php") ;
ou encore plutot : include_spip("lib/ckeditor/ckeditor");
Préférer les include_spip() aux autres
include(_DIR_PLUGIN_CKEDITOR."toolbars.php") ;
=> include_spip("toolbars");
require_once(_DIR_PLUGIN_CKEDITOR."include/HTMLCleaner.php") ;
=> include_spip("include/HTMLCleaner");
ou if (include_spip("include/HTMLCleaner")) { actions }
A toi de voir ce que tu préfères aussi.
Bon courage.
--
MM.
Le 03/10/2009 13:11, Frédéric Bonnaud a écrit :
Pour l'instant, le plugin CKeditor pèse 3.0Mo (771K compressé) à comparer aux
1.7Mo (440K compressé) du couteau_suisse
C'est effectivement beaucoup. Mais ça ne représente que 2x le poids d'un plugin
comme le couteau_suisse.
Oui, on pourrait aussi causer longtemps du couteau suisse…
La seule différence, c'est que son code n'y est que 2 fois sur la zone (le code des plugins d'origine, et le code intégré dans le couteau suisse) ; et je t'accorde que c'est déjà une fois de trop.
Le FCK, on en a déjà 3 je crois, ça commence à bien faire, alors qu'on a développé <necessite id='lib:' pratiquement exprès pour lui ! Et que ce n'est franchement pas compliqué à mettre en œuvre…
Tiens, ma dernière utilisation en date, comme tu vois, j'ai mis les lib sur mon serveur, car, la première n'était pas distribuée en zip, la seconde a un fichier en plus :
Et particulièrement :
Et enfin l'utilisation juste là :
Je pense qu'avec tous ces exemples, tu vas t'en sortir
A bientôt.
--
MM.
Bonjour,
RealET a écrit :
* Frédéric Bonnaud tapuscrivait, le 03/10/2009 13:11:
Le samedi 03 octobre 2009 12:04:47, RealET a écrit :
En ne mettant SURTOUT PAS CKeditor en entier sur la zone : SPIP a un
mécanisme de chargement de library pour éviter de surcharger la Zone.Je comprends bien le problème, mais pour l'instant, j'ai pas de temps pour cela (ça me semble assez complexe faire en sorte que le plugin downloade ckeditor à l'installation), donc le plugins ne sera pas sur la zone.
J'ai supprimé du plugin : tous les exemples, toutes les sources et n'ai laissé que ce qui est nécessaire au fonctionnement de CKeditor.
Pour l'instant, le plugin CKeditor pèse 3.0Mo (771K compressé) à comparer aux 1.7Mo (440K compressé) du couteau_suisse
C'est effectivement beaucoup. Mais ça ne représente que 2x le poids d'un plugin comme le couteau_suisse.Mais je comprends que ce soit trop important.
(FCKeditor et les autres outils WYSIWYG plombent déjà trop la Zone !)
Et plus généralement, à moins que tu ais trouvé un truc génial pour gérer :
- [->12]
- [[note de bas de page]]
- <modele...>
- <html></html>Je ne pense pas que ce soit génial, mais pour les 3 premiers c'est possible/utilisable pour [->12] et consorts ainsi que <modeles...> (ça nécessite une conversion du code généré par CKeditor prévu par le plugin).
Pour les notes de bas de page, vue que ce n'est pas une balise html/xhtml/xml CKeditor les laisse tel que, donc on peut les utiliser.Pour la balise <html> je ne la connaissais pas, je vais regarder ce qu'elle fait.
Tout éditeur WYSIWYG est une perte majeure de fonctionnalité et
d'évolutivité pour SPIP.Je connais la rengaine, je comprends cette opinion, mais je ne suis pas d'accord et ne suis pas le seul. Il n'y a qu'à regarder le nombre de personnes qui recherchent ce type de plugin. Il y a un besoin/une envie pour un tel plugin. Et plusieurs personnes n'ont pas besoin de la fonctionnalité que tu décris.
Dans CKeditor il est possible d'insérer une image de spip en utilisant une boite de dialogue ET en utilisant le mécanisme des documents spip. De même il est possible d'insérer un lien vers un articles/une rubrique/un brève spip en la choisissant dans une liste présentant les titres (plutôt qu'un numéro)
Pour les autres modèles, il suffit de les autoriser en configurant correctement le plugin.Autre challenge : réussir à continuer à enregistrer dans la base de SPIP
des raccourcis typo et surtout pas du HTML.sauf que SPIP autorise le html, si le HTML c'est si mal, pourquoi ne pas utiliser strip_tags sur ce qui rentre dans SPIP pour le supprimer complètement sans autre forme de procès.
Bref dans un article spip on peut mettre du HTML mais toi tu jettes l'anathème sur le html. Ça ne me parait pas cohérent. Tout le monde ne recherche pas forcément un spip qui utilise des raccourcis typo, une mise en page limité à ce qui est prévu par spip, une mise en page sémantique etc...
L'un des intérêts de spip est son système de plugin, il permet de faire de spip ce que chacun désire et pas seulement ce que TU désires.En l'occurrence, je désire un vrai plugin WYSIWYG pour SPIP, pas un n-ième générateur de HTML qui rend la relecture impossible/difficile à un administrateur du site qui serait aveugle (l'exemple est tiré de mon vécu).
Bref, rien ne t'oblige à utiliser ce plugin si tu veux utiliser la mise en page/en forme spip. Mais ceux qui le désirent le peuvent.
Une différence entre toi et moi, c'est que moi je propose un truc pour spip laissant chacun libre de l'utiliser ou pas (je ne propose pas, je ne demande pas de modifier le core de spip), toi tu veux imposer aux autres tes vues. Je pense que cette forme d'intégrisme, désolé pour le vocabulaire mais je n'en trouve pas de meilleur, fait végéter le libre.
Désolé d'avoir paru intégriste.
Pour la petite histoire, un éditeur WYSIWYG pour SPIP, ça fait des années que j'en rêve.
Et puis j'ai fait l'expérience dans certaines administrations des dérives possibles suite à l'utilisation d'un outil WYSIWYG.
Tu me parle d'intégrisme.
Je te répond expérience et sagesse.
Mais comme disais confucius, l'expérience est une lanterne que l'on porte dans le dos : elle éclaire le chemin parcouru.PS : par contre, si tu as des connaissances en jQuery, PortePlume et les
Enluminures Typos V3 auraient bien besoin de ton aide...Sauf que dans le cadre où j'utilise spip, il me faut un éditeur WYSIWYG et le système d'édition de spip ne me convient pas (ne t'en déplaise), d'où le développement de ce plugin. Je ne suis pas développeur, je développe ce que je développe par plaisir, et moi ce qui me faisait plaisir c'était d'avoir un spip avec un éditeur 'fashion' pour attirer des élèves dans le club info de mon collège.
Et est-ce que ça marche d'attirer les élèves de cette manière là ?
Je partage mon expérience sur ce point : j'anime un atelier Cyberjournal dans mon collège depuis 5 années avec des élèves de quatrième (14-15 ans) en ZEP.
J'ai fait au début l'erreur d'intégrer FCK. Après 2 années de fonctionnement, j'ai voulu changer la charte graphique : passage d'un texte noir sur fond blanc à un texte blanc sur fond noir... Je ne vous explique pas la galère : du code de couleur en html partout, même lorsqu'il s'agissait d'écrire dans la couleur du texte utilisé dans le site.
Il m'a fallu reprendre la cinquantaine d'article à la main : la galère...
De toute façon, le site devenait n'importe quoi : même en donnant des consignes claires, les élèves me collaient de la couleur, du souligné, de l'italique, etc., à toute les sauces. Le site devenait illisible pour l'internaute qui ne s'y retrouvait pas.
Depuis ce temps, je suis passé à l'usage strict des raccourcis SPIP, puis maintenant au porte-plume qui est enrichi de son extension typographique, ainsi que des icônes pédagogiques que j'ai développé cet été.
Au final, l'utilisation des raccourcis typographiques n'a jamais été une contrainte pour les élèves, dés lors qu'on passe un peu de temps pour leur expliquer le fonctionnement, le but (uniformité de la charte graphique), la façon de rédiger sur le web, etc. Par ailleurs, ils s'en sortent généralement très bien en consultant l'aide intégrée en ligne.
Je me souviens qu'à mes commencements, j'avais aussi développé des choses autour de FCK et que d'autres collègues de mon académie l'ont mis en œuvre.
Maintenant, pour rien au monde je ne l'utiliserai. D'ailleurs, j'administre une plate-forme mutualisée (100 sites d'établissements installés) et je n'ai pas proposé FCK parmi les plugins disponibles. Certains webmestres me l'ont demandé, mais en argumentant un peu on les persuade assez vite. Un article à ce sujet avec quelques liens : http://spip.ac-rouen.fr/?Un-editeur-WYSIWYG-dans-SPIP-est .
Je risque de passer pour un intégriste sur ce dernier point. Mais je pense plutôt avoir un peu d'expérience et vouloir la faire partager, d'autant plus que lorsqu'on est webmestre dans un établissement scolaire, on peut être amené à passer la main d'une année à l'autre, alors ce n'est pas un cadeau de laisser du html en dur partout dans les articles d'un site pour un collègue qui n'aura peut-être pas les compétences pour faire le nettoyage nécessaire. Si la charte graphique doit être changée, ce ne sera pas une mince affaire pour le futur webmestre.
Voilà pour mon retour d'expérience à ce sujet.
Cordialement,
Olivier Gautier.
PS : l'adresse du cyberjournal : http://lepiaf.spip.ac-rouen.fr/
Bon désolé pour le ton, je me rends compte que j'ai été un peu agressif, mais je défends mon bébé
Tout à fait normal de défendre un bébé
PS : une lecture pour la route : Un éditeur WYSIWYG pour SPIP ? - Pyrat.net – Création de sites Internet
Olivier Gautier a écrit :
Bonjour,
RealET a écrit :
* Frédéric Bonnaud tapuscrivait, le 03/10/2009 13:11:
Le samedi 03 octobre 2009 12:04:47, RealET a écrit :
En ne mettant SURTOUT PAS CKeditor en entier sur la zone : SPIP a un
mécanisme de chargement de library pour éviter de surcharger la Zone.Je comprends bien le problème, mais pour l'instant, j'ai pas de temps pour cela (ça me semble assez complexe faire en sorte que le plugin downloade ckeditor à l'installation), donc le plugins ne sera pas sur la zone.
J'ai supprimé du plugin : tous les exemples, toutes les sources et n'ai laissé que ce qui est nécessaire au fonctionnement de CKeditor.
Pour l'instant, le plugin CKeditor pèse 3.0Mo (771K compressé) à comparer aux 1.7Mo (440K compressé) du couteau_suisse
C'est effectivement beaucoup. Mais ça ne représente que 2x le poids d'un plugin comme le couteau_suisse.Mais je comprends que ce soit trop important.
(FCKeditor et les autres outils WYSIWYG plombent déjà trop la Zone !)
Et plus généralement, à moins que tu ais trouvé un truc génial pour gérer :
- [->12]
- [[note de bas de page]]
- <modele...>
- <html></html>Je ne pense pas que ce soit génial, mais pour les 3 premiers c'est possible/utilisable pour [->12] et consorts ainsi que <modeles...> (ça nécessite une conversion du code généré par CKeditor prévu par le plugin).
Pour les notes de bas de page, vue que ce n'est pas une balise html/xhtml/xml CKeditor les laisse tel que, donc on peut les utiliser.Pour la balise <html> je ne la connaissais pas, je vais regarder ce qu'elle fait.
Tout éditeur WYSIWYG est une perte majeure de fonctionnalité et
d'évolutivité pour SPIP.Je connais la rengaine, je comprends cette opinion, mais je ne suis pas d'accord et ne suis pas le seul. Il n'y a qu'à regarder le nombre de personnes qui recherchent ce type de plugin. Il y a un besoin/une envie pour un tel plugin. Et plusieurs personnes n'ont pas besoin de la fonctionnalité que tu décris.
Dans CKeditor il est possible d'insérer une image de spip en utilisant une boite de dialogue ET en utilisant le mécanisme des documents spip. De même il est possible d'insérer un lien vers un articles/une rubrique/un brève spip en la choisissant dans une liste présentant les titres (plutôt qu'un numéro)
Pour les autres modèles, il suffit de les autoriser en configurant correctement le plugin.Autre challenge : réussir à continuer à enregistrer dans la base de SPIP
des raccourcis typo et surtout pas du HTML.sauf que SPIP autorise le html, si le HTML c'est si mal, pourquoi ne pas utiliser strip_tags sur ce qui rentre dans SPIP pour le supprimer complètement sans autre forme de procès.
Bref dans un article spip on peut mettre du HTML mais toi tu jettes l'anathème sur le html. Ça ne me parait pas cohérent. Tout le monde ne recherche pas forcément un spip qui utilise des raccourcis typo, une mise en page limité à ce qui est prévu par spip, une mise en page sémantique etc...
L'un des intérêts de spip est son système de plugin, il permet de faire de spip ce que chacun désire et pas seulement ce que TU désires.En l'occurrence, je désire un vrai plugin WYSIWYG pour SPIP, pas un n-ième générateur de HTML qui rend la relecture impossible/difficile à un administrateur du site qui serait aveugle (l'exemple est tiré de mon vécu).
Bref, rien ne t'oblige à utiliser ce plugin si tu veux utiliser la mise en page/en forme spip. Mais ceux qui le désirent le peuvent.
Une différence entre toi et moi, c'est que moi je propose un truc pour spip laissant chacun libre de l'utiliser ou pas (je ne propose pas, je ne demande pas de modifier le core de spip), toi tu veux imposer aux autres tes vues. Je pense que cette forme d'intégrisme, désolé pour le vocabulaire mais je n'en trouve pas de meilleur, fait végéter le libre.
Désolé d'avoir paru intégriste.
Pour la petite histoire, un éditeur WYSIWYG pour SPIP, ça fait des années que j'en rêve.
Et puis j'ai fait l'expérience dans certaines administrations des dérives possibles suite à l'utilisation d'un outil WYSIWYG.
Tu me parle d'intégrisme.
Je te répond expérience et sagesse.
Mais comme disais confucius, l'expérience est une lanterne que l'on porte dans le dos : elle éclaire le chemin parcouru.PS : par contre, si tu as des connaissances en jQuery, PortePlume et les
Enluminures Typos V3 auraient bien besoin de ton aide...Sauf que dans le cadre où j'utilise spip, il me faut un éditeur WYSIWYG et le système d'édition de spip ne me convient pas (ne t'en déplaise), d'où le développement de ce plugin. Je ne suis pas développeur, je développe ce que je développe par plaisir, et moi ce qui me faisait plaisir c'était d'avoir un spip avec un éditeur 'fashion' pour attirer des élèves dans le club info de mon collège.
Et est-ce que ça marche d'attirer les élèves de cette manière là ?
Je partage mon expérience sur ce point : j'anime un atelier Cyberjournal dans mon collège depuis 5 années avec des élèves de quatrième (14-15 ans) en ZEP.
J'ai fait au début l'erreur d'intégrer FCK. Après 2 années de fonctionnement, j'ai voulu changer la charte graphique : passage d'un texte noir sur fond blanc à un texte blanc sur fond noir... Je ne vous explique pas la galère : du code de couleur en html partout, même lorsqu'il s'agissait d'écrire dans la couleur du texte utilisé dans le site.
Il m'a fallu reprendre la cinquantaine d'article à la main : la galère...
De toute façon, le site devenait n'importe quoi : même en donnant des consignes claires, les élèves me collaient de la couleur, du souligné, de l'italique, etc., à toute les sauces. Le site devenait illisible pour l'internaute qui ne s'y retrouvait pas.Depuis ce temps, je suis passé à l'usage strict des raccourcis SPIP, puis maintenant au porte-plume qui est enrichi de son extension typographique, ainsi que des icônes pédagogiques que j'ai développé cet été.
Au final, l'utilisation des raccourcis typographiques n'a jamais été une contrainte pour les élèves, dés lors qu'on passe un peu de temps pour leur expliquer le fonctionnement, le but (uniformité de la charte graphique), la façon de rédiger sur le web, etc. Par ailleurs, ils s'en sortent généralement très bien en consultant l'aide intégrée en ligne.
Je me souviens qu'à mes commencements, j'avais aussi développé des choses autour de FCK et que d'autres collègues de mon académie l'ont mis en œuvre.
Maintenant, pour rien au monde je ne l'utiliserai. D'ailleurs, j'administre une plate-forme mutualisée (100 sites d'établissements installés) et je n'ai pas proposé FCK parmi les plugins disponibles. Certains webmestres me l'ont demandé, mais en argumentant un peu on les persuade assez vite. Un article à ce sujet avec quelques liens : http://spip.ac-rouen.fr/?Un-editeur-WYSIWYG-dans-SPIP-est .
Je risque de passer pour un intégriste sur ce dernier point. Mais je pense plutôt avoir un peu d'expérience et vouloir la faire partager, d'autant plus que lorsqu'on est webmestre dans un établissement scolaire, on peut être amené à passer la main d'une année à l'autre, alors ce n'est pas un cadeau de laisser du html en dur partout dans les articles d'un site pour un collègue qui n'aura peut-être pas les compétences pour faire le nettoyage nécessaire. Si la charte graphique doit être changée, ce ne sera pas une mince affaire pour le futur webmestre.Voilà pour mon retour d'expérience à ce sujet.
Cordialement,
Olivier Gautier.PS : l'adresse du cyberjournal : http://lepiaf.spip.ac-rouen.fr/
je plussoie moi aussi dans ce sens pour les mêmes raisons : une expérience avec des élèves et fckeditor qui me fait fuir ce type de plugin
Salut Frederic,
Je teste la version Version : 0.1 — en test de CK. sous SPIP 2.1 dév
- Importation de la lib OK (5Mo tout de même !)
- Erreur sur le CFG : Filtre >0 non défini ../plugins/ckeditor/fonds/cfg_ckeditor.html l.8
En fait c'est : <input type="text" name="taille" value="[(#ENV{taille}|>0|?{#ENV{taille}, '500'})]" qui doit être |>{0}.
- J'ai désactivé Porte Plume
- Et je n'ai pas de CKEditor sur mes articles…
- j'ai une erreur JS : CKEDITOR is not defined
[Break on this error] CKEDITOR.spip_absolutepath = 'http://dev.umaya',\n
Le problème est double :
- 1) tu inclues systématiquement $script, même si le js de CKEditor est pas chargé (comme dans mon cas ici)
- 2) en 2.1, il n'y a plus la classe CSS «barre_inserer» (a tord ou a raison…), du coup les preg_match ne match pas…
A regarder ce que tu ajoutes comme CSS/html et script, je pense que tu peux faire les ajouts entièrement en jQuery.
1) sélectionner les textarea que tu veux,
2) ajouter la classe css ckeditor
3) ajouter autour le html qu'il te faut
4) une fois que ça c'est fait, executer le contenu qui est dans $script
----
Passage en 2.0
Bon, ça marche mieux, mais :
- Porte Plume et lui ne font pas bon ménage : je dois désactiver PP.
Quelques bugs :
Sur l'ajout d'un lien SPIP, par exemple d'une sous rubrique dans le sélect qui s'affiche, ET si l'on ne renseigne pas le titre, il transforme les espaces d'espacement du titre en entités : j'obtiens :
-     Éditos
- Dans l'ajout d'image, la fonction d'exploration du serveur ne calcule pas les miniatures, mais réduit la taille d'origine de l'image : chaque image est très longue à s'afficher.
- une fois que j'ai sélectionné une image, ça me redimensionne mon navigateur (ff3.5/ubuntu)(et pas vraiment en grand !)
- en enregistrant mon article, j'obtiens :
«No tidy support. Please enable it in your php.ini. Only basic cleaning is beeing applied» : il faudrait p'tet faire tester sa présence ou non de tidy pour autoriser l'option dans le CFG
- bon, le pire pour moi est bien cela : les liens générés ne sont pas au format SPIP… j'obtiens : <a href="http://200.umaya/-Les-actions">Les Actions ?</a> Bref… et si mon article change de nom, d'adresse ?
Lien qui par ailleurs est erroné je vois, normalement, c'est -Les-actions- avec ma configuration d'url en cours.
J'arrête pour ce soir…
En tout cas merci déjà pour avoir intégré les remarques qu'on avait fait sur le zip. J'ai vu ta fonction de copie pour déplacer le plugin SPIP aussi de cke… ça va pas être simple pour les évolutions ; ie. si tu modifies ce plugin, comment vas tu assurer que tu dois recopier de nouveau le dossier lib ? (peut être avec un fichier qui nomme la version : s'il n'y est pas dans lib/ckeditor/plugin/spip/version_1.2.txt, alors recopier le dossier)
--
MM.
- Dans l’ajout d’image, la fonction d’exploration du serveur ne calcule
pas les miniatures, mais réduit la taille d'origine de l'image : chaque image est très longue à s'afficher.j'avoue mon ignorance (une nouvelle fois) : je vais me documenter.
Ah, mais ça c’est très simple hein !
src=‹ [(#URL_DOCUMENT|url_absolue)] ›
→ src=‹ [(#URL_DOCUMENT|image_reduire{150,25}|extraire_attribut{src}|url_absolue)] ›
ou encore src=‹ [(#FICHIER|image_reduire{150,25}|extraire_attribut{src}|url_absolue)] ›
«No tidy support. Please enable it in your php.ini. Only basic cleaning is beeing applied» : il faudrait p'tet faire tester sa présence ou non de tidy pour autoriser l'option dans le CFGbonne idée. Mais normalement y'a ça dans le script : $cleaner->Options['UseTidy']=false; et plus étrange, j'ai pas tidy chez moi (dev), ni sur le serveur sur lequel est installé en prod le plugin et j'ai pas ce message... mais je vais tâcher d'être plus strict.
J’ai oublié de dire que j’avais coché «nettoyer le html avec jeNeSaisQuoi» dans le CFG