Insertion d'image en mode wiki

[franck]

Version installée : 2.7-dev (rev 2742).

Éditeurs configuré comme suit :

• xhtml -> dcCKEditor
• wiki -> dcLegacyEditor
• markdown -> dcLegacyEditor

J'ouvre un billet (Chrome Canary sur Mac) existant (syntaxe wiki), j'ai dcLegacyEditor actif. À l'insertion d'une image, le popup refuse de se fermer sur le bouton "Insérer".

La console Js m'indique ceci :

index.php?pf=dcCKEditor/js/popup_media.js:12 Uncaught TypeError?: undefined is not a function

C'est surtout le dcCKEditor qui m'interpelle vu qu'il ne devrait pas être chargé.

[franck]

J'ai trouvé (a priori) le problème :

Les behaviours adminPopupMedia, adminPopupLink et adminPopupPosts devraient conduire, avant de charger les js idoines, à tester si l'éditeur actif est bien le bon.

C'est valable dans les deux plugins, dcLegacyEditor et dcCKEditor.

[franck]

Du coup ça veut dire qu'il faut soit conserver l'info de l'éditeur actif quelque part et accessible par les plugins (j'ai pas vu qu'il était dans les GET quand media_item.php était chargé) soit le fournir en argument aux behaviours.

Je pense que ça serait peut-être bien de stocker ça quelque part ($core ?)

[Nicolas <nikrou77@…>]

(In [993aebff97bb]) Fix call of javascript of all editors on media_item page but also popup_link and popup_posts Closes #1983

[franck]

Y'a un truc qui me gêne avec la récupération du l'éditeur actif : d'après ce que je comprends des modifs faites pour fermer ce ticket, l'éditeur est récupéré via les préférences de l'utilisateur, indépendamment du format réel du billet en cours d'édition.

Y'a pas un blème ?

Parce qu'en l'état l'insertion d'image fonctionne maintenant bien pour le wiki (mon format préféré), mais pas pour un billet au format XHTML (pour lequel j'ai choisi dcCKEditor comme éditeur).

[philippe]

Pareil que Franck avec la r2750 pour l'insertion d'une image : c'est bon en wiki et en xhtml avec dcLegacyEditor mais pas en xhtml avec dcCKEditor

Le passage d'un éditeur à l'autre fonctionne très bien.

Je pense que le format du billet doit charger l'éditeur correspondant, quel que soit le paramètre dans les préférences utilisateur. Ce paramètre doit permettre seulement de proposer l'éditeur préféré lors de la rédaction d'un nouveau billet, ou de changer d'éditeur sur un billet existant (sans transformation du contenu autre que la conversion en xhtml si demandé comme maintenant). C'est bien ça qui est prévu ?

[franck]

Le fonctionnement du chargement de l'éditeur n'est pas en cause, sur un nouveau billet (c'est le format préféré et l'éditeur choisi pour ce format qui est sélectionné et donc chargé), ou pour un billet déjà créé (où c'est en fonction du format du billet et de l'éditeur choisi pour ce format).

Je confirme qu'on ne prévoit pas de basculement d'éditeur en cours d'édition, y compris pour la conversion en XHTML (dans ce cas c'est l'enregistrement qui provoquera le chargement de l'éditeur idoine, tout comme si l'utilisateur avait changé simplement le format du billet).

[philippe]

Dans la popup ouverte pour insérer une image, avec dcLegacyEditor, on passe par 2 URLs :

/admin/media.php?popup=1

puis une fois l'image choisie

/admin/media_item.php?id=22&popup=1

alors qu'avec dcCKEditor on passe par

/admin/media.php?popup=1&editor=post_content

puis

/admin/media_item.php?id=192&popup=1&editor=post_content

Il semblerait que post_content ne soit pas un éditeur valide

[tomek]

Je viens de tester, et outre le souci pour les médias, j'ai exactement le même comportement pour les liens (xhtml / CKEditor) : je présume que c'est la même mécanique ?

[franck]

Tout à fait.

[Nicolas <nikrou77@…>]

(In [a96ec5640056]) Each editor (ckeditor, legacy ones) loads its own context when it is active. Add plugin_id parameter to transmit that context Remove call of ckeditorExtraPlugins behavior until a good solution is found. Closes #1983