Dans WordPress, le bloquage de l’éditeur visuel basé sur tinyMCE en position HTML arrive relativement souvent sans que l’on sache vraiment pourquoi. C’est typiquement le genre de petit soucis qu’on laisse passer un temps avant de s’attaquer au problème. En ce qui me concerne, j’ai parcouru les quelques ressources qui en parlait, pour découvrir que certains thèmes WordPress causaient des problèmes en ajoutant des fonctionnalités à l’éditeur.
Toutefois, dans mon cas, vu que mon thème, c’est moi qui l’ai fait, je sais ce qu’il y a dedans : je n’ai pas touché à ce satané éditeur visuel… Hum… sauf qu’en testant avec le thème par défaut, le problème s’est réglé. Damned! Le problème vient donc bien de mon thème…
A partir de là, il ne m’a pas fallu bien longtemps pour chercher du côté du fichier functions.php qui apparaissait comme le seul à pouvoir torturer le petit tinyMCE de la sorte. D’autant plus que j’utilise des morceaux du thème Sandbox dans lesquels j’aurais pu faire une coupe trop franche ou pas assez !
Je ne vais pas vous faire patienter plus longtemps pour vous livrer le coupable qui se cachait dans une fonction qui servait à insérer une vidéo Youtube via un shortcode. J’avais pourtant déniché cette petite perle chez quelqu’un de confiance 😉
J’ai donc supprimé les fonctions et tout est revenu à la normale… pendant au moins dix minutes ! le temps d’écrire ce billet, et hop, l’éditeur visuel perdait la vue à nouveau /o le code de l’ami burn’ n’étant donc pas fautif !
Je décidais de laisser ce petit soucis de côté pour la prochaine fois pour embrayer sur la résolution d’un problème bien plus important : mon flux RSS, invalide, provoquait des erreurs. Après une discussion sur Twitter avec Olivier Galluchot qui m’a fournit des pistes précieuses, comme supprimer tous les espaces surnuméraires dans les fichiers relatifs aux flux présents dans le dossier /includes, et tout rentrait dans l’ordre.
Cerise sur la cacahouette, en revenant corriger cet article, j’ai retrouvé un éditeur visuel en parfait état de marche…
Conclusion en forme de proverbe indien : pour réparer éditeur visuel bloqué ; casses un flux RSS ^_^
Ouf ! Failli croire que ça foirait vraiment à cause de ce shortcode :p (bien que ça pourrait, c’est plus une « fonction de démonstration », un cas d’école, qu’autre chose…)
Par contre, mon éditeur était resté bloqué « en position » html par défaut pendant une 10zaine de jour (mais avec le wysiwyg accessible par le bouton ad hoc) et j’adorerais trouver un moyen simple de reproduire ceci… Rédigeant le 80% du temps en html directement (notamment pour pouvoir insérer mes micro-formats peinards), ça me gonfle de l’avoir en wysiwyg par défaut mais supprimer totalement cette fonction dans mon profil utilisateur me gêne aussi (pour le 20% du temps restant).
Ceci étant, la modification des fichiers du flux liée à la gestion de l’éditeur visuelle ça me parait tordu à un point ! Z’étaient un peu ivres chez Automattic pour le coup nope ? 😀
Bonjour,
Il m’est arrive quelques mesaventures avec des plugins incluant du Javascript. Certains appelent leurs scripts avant l’affichage de l’interface d’admin, meme si cela est inutile. Depuis, lorsque j’ai un probleme, je commence par desactiver tous les plugins pour voir si le bug est persistant.
Exemple de plugin « genant »: WP-CodeBox qui perturbe d’autres plugins comme Lightbox et ses dérivés.
Emmanuel.
ca a l’air super bien wordpress 😀
#burningHat {
Malgré tout, je pense que le shortcode peut être plantogène dans certains cas lorsqu’on ajoute le shortcode de cette manière :
add_shortcode(’youtube’, ‘youtube_func’);dans le but de l’inclure dans l’éditeur, justement. A la place, on peut utiliser la formeadd_shortcode(’youtube’, ‘sc_youtube’);si on veut « juste » pouvoir utiliser le shortcode dans la zone de rédaction des billets.Enfin, c’est encore à prendre avec des pincettes parce que j’ai l’impression que de nombreux paramètres se disputent le droit de mettre une raclée à l’éditeur de WordPress 😀
}
#emmanuel {
Je n’ai pas réussi à isolé le plugin coupable, mais je ne suis pas loin de penser que c’est le même qui a destroyé mon flux RSS et qui a bloqué mon éditeur.
}
#boulde {
WordPress, c’est bien parce que l’éco-système est riche. Après, cet avantage peut vite devenir un inconvénient parce qu’on est inciter à tester plein de trucs qui ne vont pas forcément ensemble. Mais, bon entre l’éditeur de wordpress (tinyMCe, quoi) et moi c’est une longue histoire 😉
}
@Bruno ouaip il est clair qu’il est potentiellement plantogène mais pour d’autres raisons je pense…Par exemple le fait qu’il manque déjà quelques checks de validité des arguments plus abouti, etc. Un vrai cas d’école donc 😀
Par contre je vois pas la différence entre ton youtube_func et sc_youtube sachant que dans les deux cas le second paramètre de add_shortcode est juste le nom de la fonction a exécuté. C’est donc simplement une question de façon de nommer ces fonctions et ne change fondamentalement rien (ou alors j’ai raté un épisode et je serais ravi de combler ce vide). Tu peux me briefer ?
#burningHat {
Je n’ai pas vraiment regardé la doc, mais intuitivement il me semble que youtube_func tente d’installer un bouton dans le mode HTML alors que sc_youtube se contente de parser la page à la recherche du marqueur. Bon, on a qu’à chercher des infos et partager nos conclusions 😉
}
Si Tiny MCE vous satisfait pas, vous pouvez toujours changer d’editeur HTML et le remplacer par FCK Editor par exemple.
@DirtyF > oui bien sûr, la solution peut passer par l’installation de plugins. Sauf que j’en ai essayé plein, notamment FCK Editor qui est très bien.
Sauf que le l’ai installé une fois en production en attendant la version 2.5 de WordPress (j’avais besoin de pouvoir mettre une classe facilement sur une image) et on s’est aperçu plus tard que tous les imports d’images réalisés avec FCKEditor n’étaient pas « reconnu » par WordPress, aussi curieux que celà puisse paraître. Et celà, même en allant chercher les images dans le dossier et en les plaçant dans /upload après avoir modifié les options de classements par mois et par année pour éviter les problèmes…
Bref, c’est typiquement le genre de problème que je vois rarement évoqués par les aficionados de telle ou telle plugins mais qui peuvent te pourrir une soirée (voire deux 😉 )
Dans un registre différent, j’ai tester Markdown qui est très bien. Toutefois, si la doc dit que normalement il ne devrait pas y avoir de problème avec les balisages html réalisés avec un autre éditeur, j’ai remarqué pas mal d’interprêtations bizarre (des paragraphes qui disparaissent, etc.)
Alors bien sûr, j’imagine que les cas qui posent problèmes sont moins nombreux que l’inverse, mais dans le doute, j’essaie toujours d’utiliser les outils par défaut.
Et puis bon, on est bientôt en 2010, et à l’heure de l’Odyssée de l’espace, il serait temps d’avoir des éditeurs visuels (ou non d’ailleurs) qui fonctionnent sans problème ! Parce que bon, autant si un CMS déconne, on peut en changer, mais si l’éditeur fout ma prose en l’air avant d’inscrire joyeusement une soupe de balise en base de données… là, je suis moins d’accord 😉
ça prouve juste que Arthur C. Clarke était plus que visionnaire… Il a anticipé plein de choses mais c’est un peu planté avec la datation 😉
(pour le reste, rien trouvé allant officiellement dans le sens de ton idée mais je creuse encore…)
@Boulde: En fait, je trouve que WordPress est particulièrement stable par rapport à d’autres plateformes, surtout si l’on tient compte de la vitesse des évolutions, et de la diversité de la communauté (la version 2.5 etait quasiment exploitable en prod dès la RC1).
Le défaut (mais cela peut également être une qualité), c’est qu’il n’y a pas de règles strictes au niveau du développement des plugins. WordPress donne des recommandations, mais ne bride personne.
Nous sommes donc très dépendants de la rigueur/qualité des développeurs de plugins ou de Widgets.
Pour les développements AJAX notamment, la librairie n’est pas imposée. On peut donc avoir sur le même blog, des plugins utilisant Prototype, d’autres JQuery ou MooTools. Si les librairies sont compatibles entre elles, tout va bien, sinon … et je ne parle pas des scripts « maison », qui entrent en conflit par les librairies (je pense que c’est le cas de WP-CodeBox).
A un moment donné, je pense que les développeurs de WordPress devront « imposer » certaines règles pour réduire les impacts d’un mauvais développement de plugin ou de widget.
Bonjour,
J’ai lu tous les commentaires, et je me suis aperçue que vous êtes super doués ! mais pour moi petite débutante, qui a le même problème en ce moment avec wordpress 2.5.1 j’aimerai juste savoir ce que veut dire concrètement : casse un flux rss (en bref, la démarche).
merci d’avance
@ellaszandra > en fait, il ne faut rien casser du tout pour que ça fonctionne 😉 c’est juste qu’en réglant un problème (le flux RSS) mon soucis d’éditeur visuel s’est débloqué.
Concrètement la démarche à suivre est d’aller dans le dossier /includes de l’installation de wordpress, puis de chercher les fichiers qui ont un rapport (il y a rss, feed ou atom dans le nom) avec un flux RSS ou Atom et de supprimer les éventuels espaces qui se seraient glissés entre chaque ouverture et fermeture de balises PHP, soit entre : ?> et <?php …
Il se trouve que chez moi ça a marché, mais je ne garantit rien. A la limite, si tu ne veux pas ouvrir ces fichiers à la main, tu peux (après avoir fait une sauvegarde) réinstaller le dossier "includes".
Sachant quand même que si ton flux n'a pas de problème, le soucis vient sûrement d'ailleurs… Tu peux aussi tester la réinstallation complète de WordPress puis activer les plugins les uns après les autres jusqu'à ce que tu identifies celui qui bloque l'éditeur.
Bon courage 😉
merci,pour tout car grâce à votre j’apprends vraiment
Music started playing as soon as I opened this web page, so annoying!