I am trying to create a new module at WYSIWYG - GeSHi bridge. This was inspired by TwoD's comments in #723856: Support Geshi filter.

The module is supposed to create compatibility between WYSIWYG and the GeSHi Filter for syntax highlighting module by adding some user-selectable buttons.

But here's a deal breaker: per #727782: Selecting new buttons should modify, not replace, default buttons, if a user selects these new buttons, then all of CKEditor's default buttons disappear, and there's no sensible way of getting them back.

So I want to make sure: is there any way to add buttons to CKEditor with a plugin but not utterly destroy the default, nice button set?

This is documented as #727710: When enabling this plugin's buttons, all standard CKEditor buttons disappear in the WYSIWYG - GeSHi bridge's queue.

If the answer is the same as what's in #727782: Selecting new buttons should modify, not replace, default buttons--unclear if it will ever be supported--then I may have to make WYSIWYG - GeSHi bridge module work with the CKEditor - WYSIWYG HTML editor module instead, which means I am eating crow given my campaigning for WYSIWYG at #606404: Please abandon CKEditor - WYSIWYG HTML editor module.

If WYSIWYG doesn't have a clear path to do this right--i.e., adding buttons don't destroy default tool bars--is WYSIWYG really able to be a one-stop-shop for all WYSIWYG needs?

Comments

Status:Active» Fixed

Short answer: no.

Sun will likely accuse me of writing essays again, but here's the longer answer: ;)
You can get most of the buttons back simply by enabling them as well.
Some have been intentionally disabled because they don't work well at all with Drupal, or they need more advanced config options which we can't currently provide but another module might (and we might have missed some in our button definitions). The only drawback is that the buttons are currently not sorted/grouped as nicely as in the default layout. (Which is now possible to get around using hook_wysiwyg_editor_settings_alter if it is an absolute requirement.)

The default toolbar definition in the original ckeditor config file is "locked", as in we can't easily add/remove buttons to it and also be able to use different layouts for different editor instances (same editor, different format/profile, both active on the same page). We will not officially support modification of editor library files for a number of reasons, which is what you have to do with ckeditor.module.
We have to create our own toolbar layout from scratch when sending a complete toolbar definition (as opposed to just the name of an existing toolbar definition) as the value of the 'toolbar' setting to an editor instance.
Once #277954: Allow to sort editor buttons gets in it will be possible to nicely group the buttons in just the same way as the default toolbar if you so wish, for all editors which support it.

You have to understand that Wysiwyg doesn't destroy the original toolbar when a user explicitly enables the buttons he/she wants, it creates a completely new one based on the user's selections, which is something that should always be done because Drupal doesn't support, or isn't designed to work with, all the features enabled by the default toolbar configurations of most editors.
The code to handle "exceptions" to one of the default toolbars would be much more complex and bloated compared to just creating a new toolbar with the selected buttons.

Having the editor use the default toolbar when no buttons has been explicitly been set (as is the case with a completely new profile) works good as a "demo" mode as it shows that everything works, all that is left is to make it suit your needs.

If WYSIWYG doesn't have a clear path to do this right--i.e., adding buttons don't destroy default tool bars--is WYSIWYG really able to be a one-stop-shop for all WYSIWYG needs?

Again, you don't "add" buttons when selecting them in the list, you specify which buttons to include in a custom toolbar. If you only checked a single button, why would you expect the others which are still unchecked to appear in the toolbar too? It would be a whole different matter if we had a way to specify which buttons are enabled by default, and selecting one would uncheck the others, but that is currently not the case.
We do not have a good way of checking just the buttons which are enabled in the default toolbar, at least not now. We would have to come up with a complex way to dynamically keep track of the initial state and position of all buttons, something which has to be done differently for each editor to be sure we don't incorrectly mark a button/plugin as enabled or disabled when it really isn't - which would confuse the heck out of users in a much worse way. An alternative would be to make a big reference table of this information containing the toolbar layouts of all editors - which is also likely to change between versions as plugins/buttons are added/removed or just reordered.
We'd spend a huge amount of time tweaking button definitions for old editor versions instead of spending it on much more important issues.

Title:How can WYSIWYG plugins add buttons and not destroy default tool bar?WYSIWYG should define its own default toolbars
Category:support» feature
Status:Fixed» Active

Thanks for the essay. :-)

Please realize that it is a bizarre usability regression that adding one button eliminates the entire toolbar and just adds that one button.

An alternative could be that WYSIWYG has its own default toolbar for editors. This default toolbar could mimic the vendor's default. The advantage is that adding buttons will in fact changing the WYSIWYG default toolbar and not cause the massive regression as currently designed. That does not require customizing library code; it just requires WYSIWYG to have its own toolbar starting point.

Are you sure this is not possible?

What I do with the GeSHi bridge module depends on how this question is answered. I think either proposed solution (in this or other issues) are unacceptable, that either my plugin has to define a new default toolbar (which may conflict with other plugins!) or that users of my plugin are forced to manually reconstruct a toolbar.

So what happens if I want or need to remove a button from your default toolbar?

So what happens if I want or need to remove a button from your default toolbar?

The starting point is a toolbar defined by the WYSIWYG module. So when a user goes to admin/settings/wysiwyg/profile/x/edit for the first time and clicks Buttons and plugins, he sees all the default toolbar's items selected. So removing is as simple as unselecting something.*

And this isn't my default toolbar; this is your (module maintainers') default toolbar. I assume your default toolbar would be the close to the default toolbar provided by the editor.

*I realize you guys are working through some alternate interface to specify toolbars. The "unselecting something" idea may only apply to the current setup where all I see under Buttons and plugins is a list of buttons that I cannot reorder.

Issue tags:+Usability

So you rather mean a (pre)set of buttons that are enabled by default. You do not mean a hard-coded toolbar definition.

The critical problem with any defaults is that any button that a user enables actually needs to be supported by the underlying text format. You cannot even enable the "Bold" button, if the text format doesn't allow the <strong> HTML tag.

Please realize that it is a bizarre usability regression that adding one button eliminates the entire toolbar and just adds that one button.
This is technically not what the checkboxes are currently designed to do. What you're doing (though it may not be your intention) is specifically telling it to only use one button. Since no checkboxes are selected by default (for reasons explained above) it would be strange if selecting just one of them leaves the others still visible in the editor despite not also being selected in the profile. The button selection GUI overrides the default "toolbar" setting (which is simply 'full' or similar) when something is changed. How this works internally is obviously not obvious to all users (or this issue would not exist) and I understand that. For now, it's just the way it'll have to work until we can redesign it some other way.

An alternative could be that WYSIWYG has its own default toolbar for editors.
This default toolbar could mimic the vendor's default.
Are you sure this is not possible?
Sun's question is very valid here, if Wysiwyg's default toolbar was defined in the editor's "native" way, as those toolbars can't be modified at all.

If these "toolbar definitions" weren't implemented as actual native toolbar definitions, but "just" a default state of the checkboxes on the GUI (ignored as soon as any changes are made), it would work pretty much the way you describe. But to be "perfect" this has to be done differently for each editor version, like I described in the last paragraphs above. I hope that you understand that is impossible for us to manage so we have to compromise at some point. So far, we've had to stop at the first obvious compromise - which is the behavior you see now, but I do think it would be possible to change this now that we know more about the editors etc.

We already have a very basic "representation" of the available buttons (and indirectly their positions in the toolbar) at the bottom of most editor implementations, but it currently has no "default status/group/position" information associated with it and it was probably not intended to work like that originally. We'd have to add that information and other things to make it more like the "Wysiwyg default toolbar" you requested. That request is indeed something which could be considered different from #277954: Allow to sort editor buttons which I think may only deal with reordering the buttons to a new state, regardless of the previous/default state.

Yes, you are right that the interface will go through changes, starting with #277954: Allow to sort editor buttons and #313497: Allow configuration of advanced editor settings, how exactly that will be done and what happens after I can't say. I'm hoping that we can either implement something like your request, or make it more obvious what will happen when checking the checkboxes, and why.*

..that either my plugin has to define a new default toolbar...
As far as I know, I have not suggested this as a solution. It would indeed conflict with other plugins, and also the editor implementation itself. I have mentioned that you can alter the toolbar via hook_wysiwyg_editor_settings_alter, but that would have to be done by each user and was meant just as a last resort, say if a client demands grouping or a certain button order before we have been able to get a GUI for it implemented.


Having to explicitly enabled things is often a good thing as users should be very aware of which features/settings they have enabled when dealing with input data.

*How about adding a text above the "Buttons and Plugins" GUI saying something like: "These settings let you create your own toolbar to override the editor's default layout. Enable only the buttons and plugins you need and be sure to match its features to what the input format accepts. Using the default toolbar is not recommended other than to make sure the editor works as it should when it's first installed." If we can add that I think users would understand why it's done this way, at least for now.

Btw, what I talk about in #7 doesn't take into account the issues sun mentions in #6 (he posted that while I was typing). Ideally, the format settings should also affect which buttons can be enabled, and that would put a "veto" on some buttons even if they are defined in a "Wysiwyg default toolbar".

Ultimately, I think this needs to be postponed on #242096: Expose filter configurations for editors -- and since that issue won't be tackled before 3.x or even 4.x, I'm inclined to mark this as duplicate, because aforementioned issue is a hard dependency.

StatusFileSize
new5.71 KB

So you rather mean a (pre)set of buttons that are enabled by default. You do not mean a hard-coded toolbar definition.

Perhaps. My main request is that the configuration works intuitively, meaning that when I make trivial changes to the available buttons, I am making a change from the current state and not taking a very nice, usable toolbar and hacking it down to a stump.

The critical problem with any defaults is that any button that a user enables actually needs to be supported by the underlying text format. You cannot even enable the "Bold" button, if the text format doesn't allow the <strong> HTML tag.

That is a separate improvement that may not need to happen simultaneously with this. Right now CKEditor shows many buttons by default on any text format, so it already overwhelms the allowed tags of the default filter. You can satisfy this issue while still deferring that fix for later.

How about adding a text above the "Buttons and Plugins" GUI saying something like...

That's an improvement, but still doesn't address the wickedly ugly result you get described in #727782: Selecting new buttons should modify, not replace, default buttons. See attached image ckeditor-many_0.png.

1) Just because CKEditor module does it doesn't make it right. Contrary to that, it's common UX knowledge that wrong and broken defaults are the worst that can happen.

2) It seems the initial cause for this entire confusion is that we load an editor with its (the vendor's) default toolbar that's usually fully-fledged. Removing that would solve this issue. However, we are doing this to be able to test whether an editor works without any plugin/button configuration, which is also important to check whether bug reports and support requests ain't bogus. Tough call, not sure whether there is a solution in between.

3) The screenshot you posted clearly is a different issue. Please search in the queue whether there is one already, and if not, create a new one - you can link to the attached file here.

Title:WYSIWYG should define its own default toolbarsEnabling one button removes default editor toolbar
Category:feature» support

Proper title.

Component:User interface» Plugins
Category:bug» support
Priority:Minor» Normal

...wrong and broken defaults are the worst that can happen.

Don't disagree, but that's a different issue. This issue: don't break the nice default toolbar when you add one button. Totally separate issue: don't expose functionality that doesn't work with a given input format.

Fixing this issue might get you closer to solving the bad defaults issue, and it doesn't make the bad defaults any worse.

Component:Plugins» User interface
Category:support» bug

Isn't this really a UI bug?

Sun or TwoD: it appears that the enhancements needed to clear this issue are speculative and many months away, possibly over a year. Is that correct? Just want clarity because I would like to update the WYSIWYG - GeSHi bridge project page with this notice. I.e., "don't use WYSIWYG - GeSHi bridge unless you can help the WYSIWYG module maintainers with this enhancement."

Title:Enabling one button removes default editor toolbarWYSIWYG should define its own default toolbars
Category:bug» task

Reviewing the above, it looks like the only feasible option is for WYSIWYG to implement its own default toolbar for every supported editor. Otherwise we'll have to live with a constant WTF where a simple change deletes the entire default toolbar.

Again, this is not the same as "default toolbar only shows buttons appropriate for the input filter." Changing WYSIWYG to define default toolbars may be a prereq for that one.

I'm ok with moving the feature to auto-use the editor's default toolbar by default into a invisible, non-configurable "wysiwyg_debug_editor_defaults" system variable.

Therefore, a profile that was not configured yet, will load an empty toolbar (or no editor at all).

Title:WYSIWYG should define its own default toolbarsEnabling one button removes default editor toolbar
Category:task» bug
Priority:Normal» Minor

So now WYSIWYG is going to force toolbar building as required setup step?

Yes. No difference actually. It always forced you. You cannot use the editor's default configuration on production sites.

Yes, I know. But can't WYSIWYG provide its own default toolbar configuration--an exact or close match of the editor's default--to totally eliminate this WTF?

subscribe

subscribing

I was using WYSIWYG w/CKeditor before but then tried to customize a toolbar and wasn't able to. I experienced the same "wtf" phenomena as Aren.

At the moment it seems if I use CKeditor alone I cannot control behavior depending on input filter (#720060: Implement toggling CKEditor and/or configuration profile based on field Input Format) but can control the toolbars as well as fine grained excluding/including on a per field basis. If I use WYSIWYG then I cannot control the toolbars but can have better control over the input filter.

-Tim

@Tim, #277954: Allow to sort editor buttons is about controlling/customizing the toolbar, this issue is just about its default state (what happens when you begin customizing).
Wysiwyg will attach editors wherever the format is available, use Better Formats to control where your formats appear. #322433: Replace default editor status option(s) with intelligent logic needs fixing to "remember" user preference per field.

Component:Plugins» User interface
Category:support» bug
Priority:Normal» Minor

+1

This is always a bind when setting up Wysiwyg.

Use case: "I want the default set, PLUS one button. But -- how do I know exactly what the default set is? I don't! So I go through randomly ticking all the boxes that look default-ish and hope I've not missed any. Then user/client complains something has gone missing."

Possible solutions:

- select the default set button checkboxes when you arrive on the form
- add a button for 'enable default set'. bonus points: some JS to make that ticky all the buttons it implies.

In case my earlier replies were not sufficiently clear: There is no "default toolbar". Unless we are able to parse the filter configuration in a text format into something we, in turn, can translate for each editor, so as to preselect only those buttons that are actually possible to use. Any other defaults would be entirely wrong defaults. We do not want broken defaults.

> There is no "default toolbar".

Maybe not for you in terms of the innards of the code, but for the end-user, there clearly is. There is "the set of buttons I get if I don't change any settings". That is a "default toolbar".

Status:Active» Needs review
StatusFileSize
new8.44 KB

Starting point. We still need/want to add an internal system variable to allow developers to test the editor's native defaults. Though perhaps that should be a separate issue and be done differently, so as to skip the entire editor configuration of Wysiwyg instead of just the buttons.

In case my earlier replies were not sufficiently clear: There is no "default toolbar". Unless we are able to parse the filter configuration in a text format into something we, in turn, can translate for each editor, so as to preselect only those buttons that are actually possible to use. Any other defaults would be entirely wrong defaults. We do not want broken defaults.

"Broken defaults" is a different problem. That's not what this bug report is about, and fixing this bug does not make it worse.

The default toolbar does not have to change, so its "brokenness" doesn't have to get any worse. Fixing this bug may get you closer to your vision of automated input filter-influenced button choices.

Don't let perfect be the enemy of better. Even if fixing this bug doesn't complete your vision, it will still enhance the product.

Patch applies cleanly to 6--2.
I'm not sure what it's meant to do... at any rate, I seem to now have no buttons at all showing on the editor.

Thanks for testing. This patch implements #17, i.e. resolving the user confusion and UX problem by defining an empty toolbar by default. Thus, enabling a button does not "remove buttons".

However, you should still get the buttons that are configured in your profile.

Note that this entire topic will resolve itself when the toolbar designer gets in.

> resolving the user confusion and UX problem by defining an empty toolbar by default. Thus, enabling a button does not "remove buttons".

... which resolves the confusion, but in a sort of 'destroy the village in order to save it' way.

I take it the current system supplies to button settings to the editor, and the editor determines its own default set, which is why we can't extract that information?

Aren't you just trading between broken defaults? I.e., "no buttons at all" vs. "editor's own sensible default toolbar that may have too many features enabled".

Like Sun said, it's a starting point. If we're going to try to make some buttons checked/enabled by default, it would be easiest to do that if the code around what was changed in the patch always assumes that the toolbar starts out empty. That is; the code by itself it doesn't keep track of which buttons were added and removed from a default state, but only which ones were added. Currently, the code only does this when at least one button has been selected and the editor's own default toolbar is no longer used.

To achieve the apparent effect of being able to both add and remove [single] buttons from the starting state, we can internally make it appear as if the user had already made the initial selection themselves - by pre-populating the profile data at the time of assigning the editor. It would simplify the logic in the editor settings callbacks - code that may run several times on each page where the editor is available - and give us the ability to reset the toolbar to the starting state at any time.

The major part missing from the above is a callback for each editor which returns this starting state, or "toolbar definition" as I've called it before. These callbacks would most likely need to know which version of the editor is installed to not return "old" or "too new" buttons/plugins.

We'd still have a situation similar to the current one though; there's no guarantee the starting state will actually work with your input format, but users would at least not end up seeing buttons we currently don't support at all (form-related ones for example).

At least, that's how I picture it. Don't know if Sun had something else in mind.

More or less, yes. :) If we will happen to implement any defaults, then those defaults will have to be specified in the registered buttons per editor. Currently, each editor defines its native buttons in the "default" plugin - which are just those buttons, which can be loaded without any additional (native) plugins. Not necessarily the same as the native default toolbar of every editor, but at least a full range of buttons that could be used.

The reason for why I want to solve this issue as simple as possible for now is that

  1. the toolbar designer will change things drastically. I can see the point of "rather wanting to skip the current profile configuration" and just use the "defaults", regardless of whether they are safe to use or not. However, with the toolbar designer in place, configuring your toolbar will turn into a joy.
  2. further required changes to the internal structure of editor plugins and buttons will possibly allow us to define whether a button should be enabled by default or not.
  3. instead of wasting time with broken defaults (and like it or not, any such code will eat at least the time of Wysiwyg maintainers), we should focus on implementing proper support for filters in text formats, to derive a working default configuration from them.

That is; the code by itself it doesn't keep track of which buttons were added and removed from a default state, but only which ones were added. Currently, the code only does this when at least one button has been selected and the editor's own default toolbar is no longer used.

Nobody is asking you to change that logic.

The change is rather that toolbars never have an un-customized state. When you first install WYSIWYG and add editor X, the default state is a customized toolbar that is remarkably similar, and possibly identical, to toolbar X's own native default. That is conceptually no different than if someone customized a toolbar except that WYSIWYG is starting out with a customized toolbar state.

These callbacks would most likely need to know which version of the editor is installed to not return "old" or "too new" buttons/plugins.

How often are buttons deleted? Seems like the main risk is a button that was added. New editor buttons/functionality should not break anything--only changes to existing buttons functionality add significant breakage risk.

You might need to have "champions" for each toolbar who are willing to keep up with the changes?

Let me propose a compromise: make every toolbar's default state the same as the Drupal-delivered Filtered HTML input filter. It has these advantages:

  • Starts us out with something instead of nothing.
  • Eliminates this bug (adding 1 button destroys entire default toolbar).
  • Good chance that it covers the majority of use cases.
  • Likelihood that even people using Full HTML filter may want to (ought to?) choose their buttons carefully anyway.
  • Far easier to maintain than a toolbar that does everything.
  • Gets all the basics.
  • Because it just covers basics, drastically reduced probability of its selections being mangled by future changes in the editor and likelihood that it will persist over many versions of the editor.

A compromise like that sounds nice, but as of now it is not doable, because the module provides no means to specify default buttons.

Therefore, the only way to implement those default buttons would be via dirty hacks. I'm not a fan of hacks, and I really hope you are neither.

After all, the proposed compromise is exactly what I mentioned previously: The defaults should be derived from the text format the profile is assigned to.

I'd really like to move forward here. Also, because I think that this issue, compared to its overall effect and usefulness, gains too much momentum. To roughly explain the roadmap again:

1) Start from an empty toolbar here.

2) Implement the toolbar designer to simplify configuration of buttons.

3) Change the internal structure of buttons and plugins, so as to make every button configurable. (Think of Views' fields configuration.)

4) Due to 3), each button has to be defined with much more meta data. When reaching that state, we are able to define semantic properties per button, such as required HTML tags/attributes.

5) Find a way to automatically determine allowed HTML in a text format. Limit all available/configurable buttons in a profile to what has been determined.

6) Based on 5), either enable all possible buttons by default, or some arbitrarily defined subset of them.

I guess my main concern is that, as per #33, stopping at item 1 just trades between broken defaults. So as long as there is a path to complete all 6 items, and your loins are girded for complaints you'll get when people see blank toolbars by default :-), then we're fine.

> and your loins are girded for complaints you'll get when people see blank toolbars by default

I would really recommend you don't make any official releases with a blank toolbar on install :)

Nobody is asking you to change that logic.

Actually, that is exactly what you're asking us to do. I'm too tired to explain the details of the code, but I hope that you understand that without Sun's patch (#28) the editor's own default toolbar (which is beyond Wysiwyg's control) would show up at one point or another. Unless we make the button handling code overly complicated... It's much easier to always send a button list (empty or not) to the editor so that'll never happen.

It would also remove the assumptions being made about being able to just remove a single button from what appears to be a default state controlled by Wysiwyg, while in reality Wysiwyg just omits a toolbar definition (for debuggin reasons) until you've actively made a choice to enable one or more buttons. To reflect how Wysiwyg works (ignoring debugging), the editor should be empty until that choice has been made. Once that patch is in, we could change how Wysiwyg's button selection works, and the editors would always accurately reflect that.

There's no reason to stop at step 1 above. Showing an empty toolbar may be the technically correct thing to do judging by Wysiwyg's internals, currently containing no info about the default state of each button. But with that I'm not saying we shouldn't change the internals to keep track of the required info, in one way or another so that "the default state of the user's choice" would be determined by the editor's "native" default state, the Drupal input format associated with, the enabled filters or other things.

sub

I'm almost not a new admin anymore but I can tell you that this really wasted a good deal of my time and reduced my confidence in this module and platform. The whole button selection is key to managing the environment for my people, I have to get rid of stuff they really don't need and I don't need strange behavior taking up my time trying to get it to work as expected. I'm using TinyMCE at present.

I realize it's more complex than it seems, but this is more important than some seem to think. If, as expained way back at #1,

"you don't "add" buttons when selecting them in the list, you specify which buttons to include in a custom toolbar,"

then this needs to be clearer in the admin UI. If it's expected behavior, then help me by setting my expectations appropriately with on-screen and documentation text.

Just a comment from the gallery.

Hi,

I solved / work-arounded that problem using a custom module for D6, which restores default CKEditor toolbar (but disables those buttons that are not enabled in config).

The same can be done for other editors as well.

Its as easy as implementing a hook _alter.

See here for screenshot and module:

http://drupal.org/node/751196#comment-3091682

Best Wishes,

Fabian (LionsAd)

subscribe

@sun, @TwoD: You are not insane. I understand. And subscribe++.

Status:Needs review» Fixed

Testing this patch myself, the resulting effect is much more natural and makes sense. When only assigning an editor without doing anything else, then it's just logical to see an editor with an empty toolbar.

This is definitely a step in the right direction. The overall master plan has been outlined in #33 already. No worries, we'll get there -- especially with D7. So let's make some progress!

Thanks for reporting, reviewing, and testing! Committed to all branches.

A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Status:Closed (fixed)» Active

The patch created a major usability regression by eliminating default toolbars and making it infeasible for site admins have anything but the simplest toolbars. I'm unclear why this patch was considered a resolution to this bug.

See #1005836: No buttons by default.

Simply because there was no real bug in the sense this issue first described it and
Wysiwyg's behavior when enabling buttons hasn't really changed after the patch here was committed, the initial state just matches what the GUI said it should be now, no buttons enabled.

The editor's default toolbar layouts were meant for debugging purposes only when no buttons had been explicitly enabled, but users obviously used the editor with that layout, which can be a bit deceptive since not all the content one can add will be rendered by or useful together with Drupal - even with the Full HTML format.

Yes, I recognize that a lot of users didn't expect this change, but the way it was caused a a lot of confusion too and took focus away from a real usability issue; not being able to reconfigure the toolbar layout properly.
We've had an issue about adding support for reconfiguring the toolbar layout - grouping, sorting, separators and multiple rows - open a long time, but the number of people helping out with code, mockups and tests has been very small and we've not had time to do it on our own. We've also decided to split that task into much smaller bits. Getting new people to write code for or even be interested in helping out with, an issue of the proportions #277954: Allow to sort editor buttons has reached isn't easy.
When we have at least basic grouping or multiple row support in, the ugly wrapping issues will go away as well, so can we please focus on that? A lot of work has already been done in #277954, but the patches there are massive and try to do everything in one step.

If you need a quick workaround for showing the full toolbar while this is sorted out, implement hook_wysiwyg_editor_settings_alter(&$settings, $context) and unset() the toolbar definition in $settings when it's empty, that should make the editor fall back to the default setting.

Priority:Minor» Normal

Status:Active» Closed (fixed)

I don't agree that this issue is truly resolved, but the discussion has morphed too much, so more focused, new issues are good at this point.

Please see my comment (#30) there: #594548: Viewing source removes new lines with fckeditor. I agree with you, this issue is not truly resolved.

For those finding this via searches and for some reason want the default toolbars, you can set them manually via hook_wysiwyg_editor_settings_alter().
That's the only way you'll be able to activate them, but note that this completely overrides the "Buttons and Plugins" section in the editor profile configuration, so you should really combine it with an hook_form_alter() implementation to replaces that entire section with something else, or we'll soon be seeing bug reports about it being broken...

Create: sites/all/modules/MYMODULE/MYMODULE.info

name = MYMODULE
description = My dev tweaks.
core = 6.x

Create: sites/all/modules/MYMODULE/MYMODULE.module
<?php
function MYMODULE_wysiwyg_editor_settings_alter(&$settings, $context) {
  switch (
$context['profile']->editor) {
    case
'fckeditor':
      unset(
$settings['buttons'], $settings['ToolbarSet']);
      break;
    case
'ckeditor':
      unset(
$settings['toolbar']);
      break;
    case
'tinymce':
      unset(
$settings['plugins'], $settings['theme_advanced_buttons1'], $settings['theme_advanced_buttons2'], $settings['theme_advanced_buttons3']);
      break;
    case
'whizzywig':
      unset(
$settings['toolsItems']);
      break;
    case
'wymeditor':
      unset(
$settings['toolsItems']);
      break;
    case
'yui':
      unset(
$settings['toolbar']);
      break;
  }
}
?>

Ok, thanks for this workaround!