Subject pretty much says it.
It I enable any of the advanced buttons/plugins, that is the buttons that are linked, It basically kills the editor and only that one button shows.
So far I've tried iframe, media, insert time, font size, insert date, BBCode, Table and some others. In the case of a plugin like BBCode or iframe, which have not buttons, the editor bar is blank. In the case of something like Table, it shows all buttons associated with that plugin. In the case of something like Font Size or Media, it shows just the one button/dropdown for that plugin.
If I get rid of the advanced plugin, everything works well
Now here's the really messed up part: I have the editor working fine with the img_assist plugin for the Full HTML format. But I cannot get it working for a custom Rich Editor format, whether I turn off the HTML corrector and HTML filter and all that or not.
I've tried clearing caches (drupal and browser), switching browsers all to no avail. I did notice that even in the Full HTML format, the advanced button loads first, then the others. In the format that's giving me issues, it loads first, and then everything stops.
Not sure whether I'm doing something stupid (documentation/knowledge problem) or whether or not there's an actual bug.
Comments
Comment #1
twodOnly the buttons/plugins you have enabled will show, by design. If none are enabled the editor falls back to its own standard configuration (so we know it's working as suppoesed to in its most basic configuration).
(What we basically do is create an empty toolbar, fill it with the enabled buttons and use that instead of the standard one.)
You say you've tested the iframe button, but that button is not available to be enabled unless you've modified the editor implementation files, or used a plugin which makes it available. Is this the case?
When you say "advanced buttons" are you referring to the "Advanced Image" and "Advanced Link" and "Advanced horizontal rule" buttons?
The HTML corrector and filter act on the content after it has submitted and can not interfere with the editor on the client so it won't load. Having them incorrectly configured will however break some of the contents when viewing the final node, but that's another issue.
Comment #2
ergophobe commentedHey TwoD,
iframe - no I have NOT modified the editor implementation files, but the admin page -- admin/settings/wysiwyg/profile/3/edit -- gives me a check box for iframe. I believe that's intended simply to stop filtering out iframes inserted manually in the HTML (adding a valid_elements item ???) not add a button. But when I enable it, I lose *all* buttons (it doesn' revert to the standard, TinyMCE has no buttons whatsoever).
"Advanced" - don't know the proper nomenclature here, but basically I mean the ones that are links (Advanced Image on down) and mostly also TinyMCE plugins.
What's weird, is that with the default Full HTML input format, it all works fine. With the custom profile, though, even with every filter unchecked, I run into this consistently.
It could just be a weird glitch in my system and to some extent, I don't really care since the site works fine using the other input formats, but I did want to flag the behavior in case there's an issue with the module.
If there are specific troubleshooting/debugging steps you'd like me to take and report back, let me know. BTW, I'm decent with PHP, but my Javascript skills are pretty rudimentary. But I would do what I can.
Thanks
Tom
Comment #3
twodThe TinyMCE editor package does not include an iFrame plugin, nor does Wysiwyg module. See #544032: Add iframes via TinyMCE for a discussion about that. If you do have an iFrame plugin, and no Wysiwyg module files have been modified, it's because another module implements hook_wysiwyg_plugin() and puts the plugin there.
When you enable only a single plugin/button, all other buttons are disabled by design. If you wish to show more buttons, you have to explicitly enable them.
Otherwise you would not be able to remove buttons from the toolbar, only add them. What you're doing when enabling the iFrame plugin (which, as you say, probably just extends valid_elements) is to tell the editor to drop the default toolbar and use only your settings instead.
The editor only reverts to using the standard buttons if you have not explicitly selected any buttons to show you that it's working. It behaves like that to show people that it's fully working and usable without any configuration. But as soon as you start explicitly enabling buttons/plugins, the editor switches to a completely custom toolbar for technical reasons. In addition, the current editor implementations have nowhere to store "plugin/button-was-enabled-in-standard-toolbar" states, nor any ordering/grouping information.
The filters have nothing to do with the buttons/plugins in the editor, they only work on the contents after it has left the editor.
Btw, don't enable the BBCode plugin if you do not have an input filter which can turn BBCode to HTML when viewing the node/comment, or you'll simply see the BBCode tags as text.
Comment #4
ergophobe commentedOkay, let's just for a minute entertain the idea that I'm just being an idiot about this. As it turns out, that hypothesis checks out and explains everything.
I'm sorry to have wasted your time, but I do appreciate the explanations. It should have been obvious, but it wasn't.
Comment #5
twodI hope I did not offend you. That was really not my intention. If you did solve the problem, please explain how so we know if some documentation or FAQ entries needs updating. If there is still a problem with the advanced buttons, or anything else for that matter, I'd love to help. Step by step instructions to reproduce the issue, or perhaps even a live test environment online which exhibits the problem, would be awsome.
Please forgive any misunderstandings.
Best regards
Henrik
Comment #6
ergophobe commentedOh, you did not offend me in the least. I was just trying to be funny, which I guess I failed at!
I didn't mean to imply that *you* made me feel like an idiot. It's just that after you explained it, it seemed so ridiculously obvious, I was sorry to have wasted your time on such a trivial thing.
You were extremely gracious and polite and your explanations were very clear. I appreciated them very much.
So in short, I solved the problem by following your instructions. When I created the new content type, I was not checking any boxes, so as you explained, that reset everything to show just the one thing I had checked. In the case of the iframe, since there's no button associated with it, it resulted in a completely blank bar.
If I were to make a suggestion, perhaps it would be that on the settings screen it might say something about checking any button will reset the default settings and you'll lose existing buttons. The basic settings tab has plenty of help text, but there's nothing on the buttons tab. Perhaps something like this:
"Note, if you select any items on this list, it will reset the editor button selection. If you check one feature, you must check all features you wish to use for that profile."
That might have helped me, assuming I actually saw it and read it!
Thanks for your help
Comment #7
twodAh I see hehe. Not being a native English speaker has its disadvantages, especially when one can't hear what someone means just by their tone.
I'll try to keep your documentation suggestions in mind for future versions so this will be less confusing.
Comment #8
twodLess intimidating title...
Comment #9
ergophobe commentedThank you and sorry for any confusion.
Your English is, I would say, exceptional for a non-native speaker. I think it's just that tone doesn't come through in writing so well. Irony is always hard in a forum.
Anyway, I always thought it might be something obvious that I was missing, but figured at least by raising the issue, it would create something that would come up in searches for future users.
Comment #10
treksler commentedi can see that this was closed by design.. from a UX point of view, this is incredibly stupid design
possible proper solutions
1) detect the default config and enable the proper checkboxes by default
2) if unable to detect default config, make the user conciously switch from the default buttons to a custom config, so it doesn't look like they lose all buttons by enabling one
solution #1 is by far better for usability
Comment #11
twod/me tries to make this not sound harsh, but will most likely fail. ;)
1) Will not happen, at least not soon. We don't want to have to build a JavaScript interpreter in PHP. We also need more data for the "Button and plugins GUI" than what is provided in the default toolbar definitions so we need to keep much toolbar data hardcoded somewhere anyway.
2) Looks a lot like what will be attempted in #735624: Enabling one button removes default editor toolbar. To summarize: We've decided to try to make the initial toolbar appearance [and checkbox state] resemble the editor's own default toolbar as much as possible. Please continue the discussions in that issue.