Résumé
Après l’activation du plugin, les contenus peuvent être directement édités « en place » sur les pages publiques du site, par les personnes autorisées.
Cela demande de préparer vos squelettes pour les rendre compatibles avec ce plugin (à noter : c’est le cas de la plupart des squelettes distribués sur SPIP-Contrib). Le principe est simple : un bloc est éditable s’il contient la classe crayon objet-champ-id
. Une balise #EDIT{}
facilite encore l’écriture. En fait, pour permettre d’éditer le titre d’un article, il suffit de remplacer dans le squelette de la page article.html
, la ligne (par exemple) :
<h1>#TITRE</h1>
par :
<h1 class="crayon article-titre-#ID_ARTICLE">#TITRE</h1>
ou encore, plus simplement :
<h1 class="#EDIT{titre}">#TITRE</h1>
Autre exemple, pour rendre « crayonnable » le texte d’un article, transformer :
[<div class="texte">(#TEXTE|image_reduire{520,0})</div>]
en :
[<div class="#EDIT{texte} texte">(#TEXTE|image_reduire{520,0})</div>]
Les pages concernées doivent obligatoirement comporter une balise </head>
, écrit précisément de cette façon (lettres minuscules).
Fonctionnement
Fabrication de la page côté serveur
Lors du chargement d’une page, le plugin agit dans le pipeline affichage_final
.
Il vérifie alors :
- si l’utilisateur est identifié
- si la page contient au moins une chaîne de caractères “crayon xxxx-yyyy-nn”,
- et si l’utilisateur possède des droits sur au moins un des éléments ainsi marqués
Le cas échéant, il insère dans le <head>
de la page le script externe crayons.js
ainsi que des données de configuration ; le script s’exécute à la fin du chargement de la page, et vérifie à intervalles réguliers si de nouveaux crayons sont disponibles, de façon à les activer en cas de besoin.
Chargement par le navigateur
Lorsque la page finit de se charger (et si le visiteur a des droits d’édition sur les crayons présents dans la page), le script crayons.js sélectionne tous les éléments possédant la classe crayon type-champ-id, et si ils sont autorisés pour l’utilisateur inscrit, leur adjoint une image clicable (un crayon) et leur ajoute la classe crayon-autorise pour indiquer qu’ils sont « éditables ».
Un clic sur cette image, mais aussi un double-clic sur l’élément lui-même, provoquent l’activation du formulaire d’édition.
Activation du crayon
Un click sur le « crayon » (ou un double-clic sur l’élément) déclenche une requête vers le serveur, qui renvoie le formulaire de modification qui va « remplacer » l’élément affiché.
La requête spécifie au serveur le « type », le « champ » et l’« id » pour lesquels le formulaire est demandé.
Après vérification de l’existence des données et des droits sur celles-ci, le serveur renvoie le formulaire (sous forme de données javascript, au format JSON). Le type et les dimensions du champs sont déterminés d’après sa nature et la place réservée à l’élément. Il contient le source brut du texte, comme lorsque on édite depuis l’espace privé ; la police, la taille et la couleur des caractères sont préservées.
crayon.js associe ce formulaire à l’élément puis "cache" ce dernier.
L’utilisateur peut maintenant modifier les données.
Attention : l’affichage final ne peut être réalisé que par le serveur, un click en dehors de la zone d’entrée après des modifications affichera à nouveau le contenu originel.
Dans ce cas, une roue dentée vous signale que vous avez introduit une modification. Click sur le bouton ou double-click sur l’élément vous y ramène, elles ne sont pas perdues.
Si vous abandonnez cependant la page, un dernier rappel vous propose de sauvegarder.
Sauvegarde
Le formulaire possède une série de boutons/touches associées :
- OK (ainsi que la touche Entrée [1]) permet de sauvegarder,
- Annuler (ainsi que la touche Escape) abandonne toute mise à jour,
- Un clic en dehors des zones de saisie cache ces zones et revient à l’affichage initial.
Il contient aussi des identificateurs et des clés associés aux données.
Le formulaire est soumis en POST par ajaxForm donc asynchrone. Sur réception, le serveur :
- analyse les données soumises, leur cohérence et leur actualité (afin d’annuler l’envoi si les données ont été entre-temps modifiées par ailleurs).
- vérifie une nouvelle fois les droits d’édition.
- appelle les procédures internes de SPIP pour mettre à jour les données.
- renvoie une vue des données modifiées, et déclenche les comportements javascript précisés par la fonction
onAjaxLoad
de SPIP.
Le système alimente notamment l’historique des modifications, de la même façon que l’espace privé.
Configuration
Le plugin propose plusieurs options, activables via le plugin CFG ; notamment :
- un message si on confirme OK mais que rien n’est changé ;
- une alerte permettant de sauvegarder les modifications si on abandonne la page alors qu’un texte est en cours d’édition ;
- l’activation de la barre typographique ;
- des couleurs permettant de mieux repérer les zones modifiables.
À noter : si le plugin est absent ou désactivé, la balise
#EDIT{...}
renvoie une chaîne vide ; cela permet donc de « crayonner » des squelettes même si l’on décide finalement de ne pas utiliser le plugin
Utilisation étendue
Toutes les tables standard de SPIP (articles, brèves, rubriques, etc.) sont gérées, y compris les forums et les signatures de pétition (mais, pour ces deux dernières, il faut utiliser le plugin Autorité pour permettre des modifications) ; pour chacune de ces tables, tous les champs de type « ligne » (titre, soustitre etc), ou « texte » (texte, chapo, descriptif...) sont crayonnables.
On peut également éditer les logos avec le crayon #EDIT{logo}
; un réglage permet de redimensionner ces logos à la volée lors de l’upload.
Les documents sont modifiables avec le crayon #EDIT{fichier}
: le nouveau document vient remplacer l’ancien et sa taille, hauteur et largeur sont mises à jour. (NB : pas encore compatible documents distants).
Enfin, à partir de spip 2, on peut éditer les champs extra.
À noter :
- Les crayons fonctionnent avec n’importe quelle table — à condition que cette table possède une clé primaire (numérique) qui s’appelle
id_xxx
, où le nom de la table estspip_xxxs
. - pour la table spip_meta qui ne propose pas ce type d’index numérique, il faut utiliser la balise
#EDIT
d’une manière un peu différente en préfixant le champs à éditer parmeta-
, par exemple [2] :#EDIT{meta-descriptif_site}
- pour éditer une valeur de configuration de plugin, on utilise la même syntaxe en ajoutant « meta » ; Par exemple pour éditer un champs de configuration adresse pour un plugin dont le préfixe est croque :
[<div class="inner #EDIT{meta-croque/adresse}">(#CONFIG{croque/adresse})</div>]
- Si un texte « crayonnable » est un champ MySQL
MEDIUMTEXT
ou plus long, les crayons affichent unTEXTAREA
, et sinon, unINPUT
. - Seuls les admins complets peuvent ainsi crayonner des textes provenant d’une table non-SPIP.
Editions simultanées de plusieurs champs
L’obtention du formulaire d’édition (« contrôleurs ») ainsi que la vue obtenue en retour sont surchargeables, par de simples squelettes (voir les exemples dans les répertoires controleurs/ et vues/ du plugin).
Ces formulaires peuvent travailler en parallèle sur plusieurs champs d’un enregistrement (article), voire plusieurs enregistrements d’une même table ou de tables différentes [3] : il y a là de quoi faire des interfaces d’édition spécialisées et très efficaces.
Comme toujours, contributrices et contributeurs sont bienvenus !
Discussions par date d’activité
303 discussions
Bon et bien la dernière version des crayons me donne une erreur javascript :
Uncaught TypeError : Cannot read property ’$erreur’ of null
C’est par là le probleme :
=> if(c.$erreur)
uniAlert(c.$erreur) ;
Répondre à ce message
J’ai pu resoudre (a moitier) ma premier bug avec la plume.
J’ai maintenant un deuxieme qui est en utilisant la method de 2 adresss web pour consulter la site (un ou la plume marche et l’autre, l’address public ou ca marche pas).
La plume casse en activant champs-extra et plugin associer ou la couteau swiss.
Je presume c’est en liens avec la premier bug de chanement de domaine, car tout c’est plugin marcher biens ensemble durant la development du site.
Aussi, effasant tout, reinstallation, remetre la database a l’etat avant activer ces plugin ... toujours casser la plume, donc ca je comprend pas n’emplue.
J’aimerai vraiment de l’aide car si ce bug est pas coriger un n’autre developeur riske gagner son argument pour drupal ... qui m’embete.
J’arrive toujours pas a resoudre ce bug.
C’est definitevement pas un problem local.
Un copie marche super sous un address IP ... le fait simple de pointer l’address WWW a la site et la crayon refuse the marcher.
Donc ca semble lier au DB, mais un recherche sur tout le DB sort pas l’adresss IP apres avoir changer au WWW.
Comme je t’ai déjà demandé, regarde s’il y a une erreur dans la console « Network » de ton navigateur.
Dans la console Network riens se passe.
Dans la « console » que les deux prochaine choses :
[19:17:27.858] Unknown property ’box-sizing’. Declaration dropped. @ http://www.gosol.org/About
[19:17:27.864] TypeError : $.browser is undefined @ http://www.gosol.org/spip.php?page=crayons.js&callback=startCrayons:447
En regardant le code HTML de la page d’accueil, je vois que tu charges jquery.js de deux manières différentes : une fois à travers SPIP (prive/javascript/jquery.js) et une fois à travers googleajaxapi ; c’est peut-être ça la cause du problème ?
Je pensais aussi ca pouvais etre lier au jquery.
Le crayon marche pas meme avec squelettes-dist, sans mes squelettes.
Répondre à ce message
Bonjour,
Pardon pour ma francais bidon, je suis anglophone.
J’ai un bug, spip 3.0.16 et Plume 1.19, la plume marche plus apres que je change la URL dans l’identite du site (par example passer d’un url type IP pour la development a la URL type www.).
Ca « mouline » sans j’amais ouvrir, ca produit pas des erreur dans la log.
J’avais extra-champs et site-horligne du couteau suisse activer quands la bug a produit le premier fois, mais la bug reproduit avec un fraiche installe aucune autre plugin (mais la meme database, donc c’est toujours possible il y a un conflit qui ce creer dans la db).
Reinstallation du plugin n’a pas d’effet (en suprimant les fichier du plugin), utilisant que squelettes-dist n’emplu, ni vider la cache, ni meme efacer tout la dossier tmp par ssh, ni aucune combination de c’est action.
Je peut regler la bug en installant un nouveau spip sous url originel type IP, et importer la database. Aucume autre plugin installer.
Mais passant a url type www reproduit la bug, donc ca semble definitevement associer a cette action.
Donc je sais vraiment pas ou chercher pour le resoudre (un ligne dans la DB qui guarde la memoir du anciens URL ? mesure anti-hackeur que je declenche ?? ).
Bon, je peut regler en gardant la URL IP dans la partie identiter et puis forward cette address IP a l’address www avec .httaccess, ca semble pas ideal, et d’autre pourais etre affecter par ce bug.
Regarde peut-être s’il y a une erreur dans la console « Network » de ton navigateur.
En faite, mon maniere autour ce bug marche plus, ca semblais davoir marcher un fois, de reinstaller sous la URL IP originel, mais meme ce proceder marche plus.
Ca marche en faite de sous la URL IP, mais changer a URL www recrer la bug (meme en guardans la adress IP dans la identer) ... mais enfaite cette fois j’ai rediriger la IP a la www, donc ca semble quoi que je fasse la plume function pas sous la URL www.
C’est assez embettant, le seul solution semble d’etre avoir URL IP et URL www pointant au meme dossier ... mais c’est pas elegant comme solution.
J’imagine il y a un souvenir dans spips du URL IP et la plume refuse de connecter sans cette IP.
(biens evidement j’ai vider ma cache local, esseyer sur d’autre ordinateus, d’autre utilisateur etc. donc c’est pas un problem local)
Cette fois j’ai esseyer de re-installer sous la URL www public, avec que la plme comme plugin, et meme bug, donc ca semble il y a un memoir du URL dans le DB.
Un n’autre detail, la URL originel du cite est du type IP:porte/ peut-etre c’est en liens.
Si j’install un copie du site sous URL IP:porte ca marche, le problem est des que je utilise le plus sous un nouveau URL meme en installant fraiche sous la URL public et importer la DB.
J’ai chercher dans la database si le URL ancien est qq part ... ce n’est pas ... donc je vois pas comment un nouveau installation direct avec la URL public reproduit la bug ...
J’esseye plusieur choses sur un copie du site.
Le procedure : desactive plume, suprime la dossier plume > vide cache > suprime tout dans tmp > suprime tout dan local > surpime tout cookie local > suprime squelettes > unzip spip sur les fichier > unzip crayon > active crayon > meme bug.
Hors, ca marche sur les autre site sur le meme serveurs, sur un installation fresh de spip avec le DB, mais aucune maniere de le faire accepter la URL public type www.
Hors, j’ai aussi regarder dans la DB, avec un less db.sql et un recherche du DB de l’anciens URL, qui n’aparait pas ... donc ca semble pas en liens avec la DB.
Hors, meme un installation fresh sous URL www reproduit le bug.
Si j’insall fresh sous le URL type IP origine la plume marche.
Donc je vois pas qq d’autre a esseyer.
J’ai fais du progres.
Ce procedure resous la bug pour un copie du site sous un IP :
rm -r spip/config && rm -r spip/tmp && rm -r spip/local && rm -r spip/plugins && rm -r spip/ecrire && rm -r spip/plugins-dist && rm -r spip/prive && unzip spip-3.0.zip && cd spip && chgrp -R www-data IMG tmp local config plugins-dist && chmod -R 775 IMG tmp local config plugins-dist
En bref, souprime tout et reinstall avec meme DB, reinstall plugin : la plume remarche.
Mais la meme procedure avec la site public functionne pas. Hors, comme j’ai dit un recherche du DB pour les URL IP ou WWW sort riens de specialle.
Bon, je peut pointer la site public a la dossier donc j’ai resolue la bug avec la procedure j’ai mentioner.
Vider la cache, vider toute cookie local.
Creer Situation :
Si je login sous URL public, la crayon march pas.
Si je login sous IP:port la crayong marche biens.
Si je change la URL du site sous identiter la crayon march pas ni dans sous la URL public ni sur URL IP:porte. Si ensuit je le rechange URL public a IP:port ca continue a ne pas marcher, mais je peut refaire la procedure ecraser tous pour revenir au situation.
Donc, je vais functioneer comme ca mais c’est moins que ideal car plusieur liens renvoie au site WWW si t’est sous IP. Mais en faison attentions on peut rester sous le address IP et utiliser la crayon. Pour les visiteur toute les liens semble de rester sous WWW, donc c’est functionable comme solution, mais pas ideal.
Pour eviter ce bug si la site est du depart sous la URL prevue ce n’est pas un problem, en utilisans la « maintenance mode » du couteau-swiss.
La crayon a marcher biens tous le temps de notre development, mais marche plus apres changement du URL.
Mais, il y a des situation ou changer de URL est necessaire. Dans mon cas la domaine public etais entrain d’etre transfere a mon compte apres achat, donc impossible de developer sous URL public.
C’est possible que si j’ai « transferer » le site avec procedure de sauveguarde-database et restaurer dans le nouveaus site le bug manifestera pas. Mais dans mon case j’ai pas changer du serveur, donc ca sembler raisonable de juste pointer la domain public a la meme dossier (sous precedant version de spip ca na pas creer de bug de juste pointer un nouveau URL a un instance de spip existant).
En-tout cas, merci pour ce plugin, spip + plume est un super outil, j’espere que ce bug est resoulable et affect pas d’autre.
Répondre à ce message
J’observe sur un site en SPIP 2.0.1 [13495] un bug qui disparait quand je désactive les crayons (dernière version téléchargeable).
ne fonctionne pas (mal : le texte est coupé beaucoup plus tard) lorsque les crayons sont activés.
Il n’y a pas d’autre plugin actif...
Quelqu’un a-t-il déja rencontré la même chose ?
Attention ton code est faux :
#EDIT{#TEXTE}
devrait être#EDIT{texte}
.Ouuupps ! Autant pour moi... Désolé pour le bruit ....
Répondre à ce message
Bonjour,
Crayon fonctionne très bien sur mon site (Spip 3.0.15 / ScolaSpip 3.0.24), si je suis connecté en administrateur (sur tous les articles donc).
En revanche, les rédacteurs ne peuvent pas l’utiliser pour éditer leurs propres articles.
Un problème de droits donc, mais je ne sais pas où chercher...
Une idée ?
Merci
Hello,
Je me permets de faire un petit ’up’ des fois que...
essaie de mettre dans
mes_options.php
la ligne suivante :et regarde ensuite dans les logs pour voir ce qui se passe
Merci pour cette réponse, mais ça va être compliqué, mon hébergeur (ac-creteil.fr) a fermé tous les accès FTP. Donc pour éditer le fichier php et lire les log, ça va être dur.
Répondre à ce message
Bonjour,
sur une mutu SPIP 2.1.19 / crayons à jour dernière version, j’ai ce message d’erreur...
TypeError : ’undefined’ is not a function (evaluating ’$(’.crayon:not(.crayon-init)’).live’)
Quelle est la cause de ce message ?
Un retour à la version 1.16 a rétabli la situation et les crayons fonctionnent de nouveau… Un ch’ti problème qqpart avec la toute dernière version ?
apparemment c’est le même problème que signalé juste en dessous
http://contrib.spip.net/Les-crayons?lang=fr#forum473393
Mais alors, mis à part la rétrogradation à la version inférieure (encore faut-il en avoir gardé une sous le coude) , quelle est la parade ?
il faut analyser le bug et réparer :)
Aïe, la lecture de la page consacrée à live() me confirme que ce n’est pas encore tout à fait pour moi cette affaire-là…
Dans une vie future, promis, je me mets à la programmation, mais là… je me contente de rétrograder (ça je sais faire)
Salut,
j’ai essayé de corriger ce bug en révision 81231 (version 1.18.0 des crayons). Peux-tu confirmer si c’est ok ?
hé bien ça marche ou pas ?
Désolé de la réponse un peu tardive : j’étais (et je suis encore) un peu noyé sous le boulot.
j’ai fait le test : c’est OK pour moi également...
Merci beaucoup (et encore désolé…)
Répondre à ce message
C’est la première fois que j’utilise ce plugin et j’ai l’erreur javascript suivante :
Uncaught TypeError : Object [object Object] has no method ’live’ spip.php ?page=crayons.js&callback=startCrayons:1064
$.fn.crayonsstart spip.php ?page=crayons.js&callback=startCrayons:1064
startCrayons ?var_mode=recalcul:15
(anonymous function) spip.php ?page=crayons.js&callback=startCrayons:1131
A priori ça provient du fait que .live() qui est déprécié. Néanmoins le plugin embarque ça propre version de jquery. Je suis le seul à avoir ce problème avec SPIP 3 ?
Pour information :
Le plugin dispose bien de sa propre version de jquery.(1.6)
Par conséquent si vous utilisez une version supérieur dans vos squelettes ça ne marchera pas.
Salut,
j’ai essayé de corriger ce bug en révision 81231 (version 1.18.0 des crayons). Peux-tu confirmer si c’est ok ?
Je teste demain matin et je te dis si c’est ok
alors ????
Non ça marche toujours pas :(
Uncaught TypeError : Object [object Object] has no method ’live’
peux-tu préciser quelle ligne ?
Vers 1063 ==> if((typeof crayons_init_dynamique==’undefined’)||(crayons_init_dynamique==false))
$(’.crayon:not(.crayon-init)’).live(’mouseover touchstart’,function(e)
tu peux vérifier si tu as bien récupéré la dernière version du fichier ?
http://zone.spip.org/trac/spip-zone/changeset/81231/_plugins_/crayons
Crayons 1.18.0 - stable ==> Je suis bien avec la dernière version
Bon je viens de re-vider mon cache de virer le plugin de ré-installer le plugin et de re-vider le cache.
Et là miracle ça fonctionne :)
ouf, merci !
Merci à toi
Répondre à ce message
Bonjour
A vérifier, pour supprimer une notice en php 5.4
Notice : Undefined index : espaceprive in /.../plugins/auto/crayons/v1.16.6/crayons_fonctions.php on line 35
http://zone.spip.org/trac/spip-zone/browser/_plugins_/crayons/crayons_fonctions.php#L35
Mettre à la place :
if (isset($config_espace_prive[’espaceprive’]) == ’on’)
Cela semble fonctionner, mais comme moi et le php nous ne sommes pas trop copain...
Merci ; c’est corrigé en 80124
je suis super content, j’avais presque pas fait d’erreur dans mon idée :-)
Il reste celui-là :
Notice : Use of undefined constant PORTE_PLUME_PUBLIC - assumed ’PORTE_PLUME_PUBLIC’ in /.../ecrire/public/composer.php(83) : eval()’d code(79) : eval()’d code on line 1
Par contre, là, j’arrive pas du tout à résoudre, possible que cela vienne de porte plume, mais je trouve pas la solution...
J’ai essayer en 3.0.14-dev et en 3.1 et pareil à chaque fois.
j’installe le plug, et la notice apparait quand je vais voir la page de config de crayons.
C’est un truc a résoudre à l’occasion.
Répondre à ce message
Bonsoir
Mon problème : je n’arrive plus à éditer un fichier pour le remplacer. Je fais des tests sur une page article avec inclure documents ( images sans liens pour que le crayon soit actif)
Message : erreur de communication —> ok —> Fichier ajouter_documents introuvable
J’arrive à modifier le logo de l’article et les textes avec les crayons.
Spip 3.0.5, version des crayons à jour, aucun autre plugin.
Merci d’avance
Bonsoir
Au mois de mars, je pouvais « modifier » des images depuis le site public (quand elles étaient dans le portfolio) comme on peut les modifier dans l’administration quand on passe par médiathèque (modifier une image). C’était avec Spip version 3.0.5 et Crayons version 1.14.1
Aujourd’hui, je ne peux plus... personne pour m’aider ? merci
Bonjour
La révision @ 77245 corrige le problème, merci Kent1
Répondre à ce message
Un autre problème à signaler :
Avec le plugin autorité en plus, un visiteur inscrit peut modifier ses propres messages mais étonnamment peut aussi modifier tous les articles !
je viens de retester en local : un visiteur, sauf si on lui donne explicitement les droits, ne peut éditer les articles. N’avez vous pas par erreur activé l’option wiki du plugin autorité ?
Le wiki n’est pas activé.
C’est l’espace de publication qui est ouverte aux visiteurs enregistrés.
Mais même là les visiteurs ne devraient pouvoir modifier que leurs propres articles.
« C’est l’espace de publication qui est ouverte aux visiteurs enregistrés. » ... pas compris cette phrase.
mais je vous confirme que les règlages standard d’autorité, les visiteurs ne peuvent modifier les autres articles.
Dans la configuration du plugin autorité, il y a une rubrique
Espace de publication ouverte
Choisissez ci-dessous un secteur à traiter comme un espace de publication ouverte pour les rédacteurs et / ou visiteurs enregistrés (à condition d’avoir une interface, par exemple les crayons et un formulaire pour soumettre l’article) :
(Secteurs)
Voulez-vous ouvrir la publication — au-delà des administrateurs :
- aux rédacteurs du site
- aux visiteurs enregistrés
Je confirme que c’est bien l’activation de l’espace de publication ouverte (en permettant à un visiteur inscrit de publier un article) qui provoque ce comportement étrange.
effectivement. Mais le terme espace de publication ouvert est très ambigu. A mon avis on peut le comprendre dans ce sens là.
Cela étant, la question serait plus a poser sur le forum d’autorité. Et sinon il faudrait
1) soit ameliorer code du plugin
2) soit passer outre et déclarer soit même ses autorisations.
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 :
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.
Suivre les commentaires : |