After upgrading from -2.1 to -2.2, all my menu icons disappeared. Downgrading back to -2.1 restored the buttons.

CKEditor 3.5.0.6230

Comments

Had the same problem.
Buttons could be configured individually through WYSIWYG, but lost templates, save, new page, and preview buttons permanently.
I also restored the old version and everything reappeared (without having to configure through WYSIWYG).

I am Facing the Same problem. After updation of this module, editor buttons are not displaying.

Same problem here. Also, it seems that other problems were introduced, i.e. layouts in IE were badly broken for CiviCRM. Beyond that, while FireFox seems to work okay once buttons are enabled, IE is badly broken and throws page errors relating to out of resources.

Even after downgrading these problems persist on my site with CiviCRM.

All told, I am going to completely uninstall the test site and re-build from scratch to see what happens. No way does this version get on my production site.

It is possible that this is related to jquery issues.

I did some more looking around and found the comments here ( http://drupal.org/node/989904 ) to be helpful for most of my problems. Turning on optimized css solved the layout problems I was having.

The missing buttons is still annoying, as turning them on individually results in a radically different layout with associated css problems of their own.

I am sticking with 6-2.1 til this is resolved.

Status:Active» Closed (works as designed)

The toolbar is supposed to be empty when you have not enabled any buttons on the editor profile configuration. The default toolbar layouts are not (and never have been) supported for production use since they show buttons that are not suited for use with Drupal.

For example, the form-related buttons; Drupal handles form creation via the serverside FAPI and there are are contrib modules to let users create forms that work (webform.module being the first that comes to mind). Hence, these cannot be enabled via "Buttons and plugins" when configuring the editor.

You must enable only the buttons corresponding to what your input format accepts, otherwise you risk misleading users into thinking all output the editor produces will work when the contents are rendered via Drupal.

The "radically different layout" mentioned above is due to all buttons being placed in one group on a single row is dealt with in #277954: Allow to sort editor buttons.

If there was a bug, it was that the default toolbar layouts were used at all, since they weren't intended for production use.
This has also been discussed in #735624: Enabling one button removes default editor toolbar.

Thanks for the explanation, TwoD. I read the two links you provided and have a better understanding of the issues.

Which thread would be the best one to use for discussing the basic issue here, that is, the issue that buttons are not grouped and break layouts, extending over div and column borders, etc? Does the patch from #277954: Allow to sort editor buttons (comment 132) work on this version and is it a reasonable solution?

@TwoD:

OK, I'm new to Drupal and apologize for what may appear to be ignorant and repetitive questions. So I went back and enabled all the individual buttons and my menu is back, but it's arranged in two long horizontal lines - That's not going to work either.

I tried to read through #277954: Allow to sort editor buttons and see a lot of discussion, but not a solution. Nancy_Dru offers a patch in #132 but I couldn't get that to work either.

I'm somewhat frustrated after over an hour of researching this issue without tangible results - Is there a solution that:

a) gives me a -2.1 menu appearance
b) retains the fixes of -2.2 including removing buttons unsuitable for Drupal.

I have not tested NancyDru's module in #277954-132: Allow to sort editor buttons with the latest release (-dev is currently the same code) so I can't promise it works. Wysiwyg for D6 still has the same database schema and since NancyDru's code is implemented as a separate module, it should still be compatible. It won't work with D7 though, but probably could with minor changes.

What that module does is allow button reordering - on a separate configuration page - by simply changing the order in which the button names are stored in the database. This might need to be done after each time the normal configuration page (admin/settings/wysiwyg/profile/#/edit) has been saved because Wysiwyg itself doesn't know it needs to consider the button order when saving.
It does not allow button grouping, or multiple rows. Adding that in would probably mean Wysiwyg could no longer recognize the stored toolbar definition (expected to be a single array).

The toobar appearance is identical between 2.1 and 2.2 if you had explicitly enabled any buttons, the difference is only that the editors' default layouts have been disabled because they weren't supposed to be used.
Wysiwyg had no control over which buttons were enabled or disabled by default prior to 2.2, it simply didn't pass along a toolbar definition when no buttons were explicitly enabled, now it always passes one.

You might want to take a look over in #829266: Fixing toolbar for the CKeditor / Using the settings hook if you're using CKEditor. The same idea can be applied to most of the other editors as well, but exactly how the rows/groups/buttons are defined and arranged varies between them so the code needs some adaptations.

Component:Editor - CKEditor» User interface
Priority:Normal» Major
Status:Closed (works as designed)» Active
Issue tags:+Usability, +regression

(Coming from #1005836: No buttons by default.) This is a major usability regression. You have removed the very nice default toolbars without giving us a way to recreate them.

Please undo this patch until you have more of your master plan for usability implemented. Right now we're just left hanging.

BTW, it's happening with more than just CKEditor.

(Transferred these comments from #735624: Enabling one button removes default editor toolbar.)

Why did you declare war on default toolbars? In every case, each default toolbars has been a nice starting point from which I can add or remove features.

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.

OK, then remove the (tiny number of?) buttons that conflict with Drupal from the default toolbars. BTW, would like to know more about what is conflicting?

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.

But the problem is you left us with a major usability regression. That may be fine for a dev or alpha of the module but not a release.

Title:6.x-2.2 upgrade from -2.1 causes button menu to disappear6.x-2.2 has no button menus by default

This might solve everything: #1006072: Provide some kind of default toolbar that is similar to each editor's default.

Also changing title because it has nothing to do with upgrading. Even new module users will experience this.

> the difference is only that the editors' default layouts have been disabled because they weren't supposed to be used.

It really doesn't matter that they *weren't supposed* to be used. They are used, and they have been used by just about everybody -- I hardly ever enable any buttons when I used this module, I just use the defaults.

What we have here is a UI desire path. Please don't fence it off :)

Title:6.x-2.2 has no button menus by default6.x-2.2 has no toolbar buttons by default

Well, personally I've never found a reason to keep all buttons enabled since there's so many that no user would or could use (at least not for the more complex editors), so using the default toolbars is a bit puzzling to me. I'm a bit surprised people don't consider that a UX/UI issue too. I won't bitch on about that though as it seems more people than we anticipated were actually using those toolbars and, as joachim says, a path has already been formed.

@Aren Cambre, Thanks for creating #1006072: Provide some kind of default toolbar that is similar to each editor's default.

OK, then remove the (tiny number of?) buttons that conflict with Drupal from the default toolbars. BTW, would like to know more about what is conflicting?

The problem is that the default toolbar definitions are defined in JavaScript, and we need to modify them from PHP. The easiest way to do this is what's suggested in #1006072: Provide some kind of default toolbar that is similar to each editor's default: manually create a duplicate of those definitions in a universal format, and use that for the initial state.
I don't remember any good examples of the conflicts other than the form buttons off the top of my head, but I'll see if I can find some for you later.

But the problem is you left us with a major usability regression.

We did not think this would be considered a regression, as we had little indication so many people actually used the default toolbars. Maybe that explains why we still have the sorting issue open... :/

Category:bug» support
Priority:Major» Normal
Issue tags:-Usability, -regression

@woodp: Your particular issue seems to be #308912: TinyMCE & CKEditor: IE/Chrome: Buttons do not wrap

Status:Active» Closed (duplicate)

In addition to the original issue, I've explained why the desired path makes no sense from a technical nor usability perspective in #1006072: Provide some kind of default toolbar that is similar to each editor's default

@sun: Thank you for that link #308912: TinyMCE & CKEditor: IE/Chrome: Buttons do not wrap. I read through it but it also seems to be more of a discussion and less of a solution.

I can't fault you for trying to bring WYSIWYG into compliance, but I just wish I had known my blind use of WYSIWYG plus CKeditor was going to lead me down this path. I'm now faced with the following for my existing eight Drupal 6 sites:

  • Click every imaginable CKeditor button and just deal with a very user-unfriendly toolbar. (That's exactly what I'm doing with one site.)
  • Uninstall WYSIWYG and replace with CKeditor module plus CKeditor editor. (Completed at one site. I don't know if I like it yet - It'll take some time getting used to.)
  • Roll back to WYSIWYG 6.x-2.1. (In effect at one site. The unfortunate result is that generates regular cron-based warnings - "New release(s) available for ...")
  • Do nothing and wait for Drupal 7 which is what I'm doing at the remaining five sites. That also leaves me with cron-based warnings, and the reality that these maintenance-only sites are going to need time-consuming (and costly) upgrades that the client won't want to pay for.

If there's a fifth, and more palatable option that doesn't involve just shutting down the warning messages, I'd be very interested! I'm surprised there are only a handful of us caught in this dilemma.

please provide a default button list. it shouldnt be hard to have these marked in the button layout by default

@woodp, Yes, there's at least one more alternative: #829266: Fixing toolbar for the CKeditor / Using the settings hook. These hook_wysiwyg_editor_settings_alter() implementations can be put in their own module and reused on all your sites without modifying Wysiwyg itself. Once Wysiwyg gains button sorting/reordering capabilities on its own, that module can simply be disabled.

@LPCA, please see #1006072-7: Provide some kind of default toolbar that is similar to each editor's default for Sun's opinion on this.

So the buttons are fixed in dev, or not?

The editor's own default toolbar layout will not be used anymore by Wyswiyg module since they don't match what input Drupal accepts, nor by default or after customizing input formats, which is why they've been disabled.

As we don't have button sorting/grouping support in Wysiwyg yet I can understand if this seems strange, but the old behavior can be achieved by implementing hook_wysiwyg_editor_settings_alter() in a custom module and unsetting the toolbar definition passed to the editor in the $settings array. That will make the editor fall back to its default toolbar layout, but since the buttons enabled in it won't ever match what your input format accepts, Wysiwyg won't use it.

In a perfect world, we would want the editor profile to auto-configure itself so only the buttons/features that can create content accepted by the input format are enabled. Determining that programatically is unfortunatly very difficult, which is why we have to leave that decision up to the site owner since only they know exactly what content they want their site to accept.
When the user has determined which buttons to enable, they should of course be allowed to alter the order/grouping as they wish. That part has been discussed and worked on in #277954: Allow to sort editor buttons but the patches there have become huge and hard to review, so we're going to split those up into smaller parts, something like what I outlined in #1006072-3: Provide some kind of default toolbar that is similar to each editor's default (comment #3).

Until that is done - which is going to take some time given the difference between the editors and the scope of the task - others have implemented ways to sort and regroup toolbar buttons that require no modifications of Wysiwyg itself, as can be seen in #829266: Fixing toolbar for the CKeditor / Using the settings hook. Most implementations only work with one or a few editors, depending on what toolbar "features" they support, but they should be pretty straight forward to modify as neeed. This way, one can enable/disable buttons via the GUI, and still have a nice layout, something which is not possible if the hook is used to fall back to the editor's own default toolbar.

> but the old behavior can be achieved by implementing hook_wysiwyg_editor_settings_alter() in a custom module and unsetting the toolbar definition passed to the editor in the $settings array

You know that someone is just going to release that code as a module on d.org. And then that will mean that instead of having to download and install wysiwyg, everyone will just have to download a second, tiny, mostly pointless module. Why can't you put that code into wysiwyg as an interim until all those follow-on issues are dealt with?

What exactly is still not clear after reading http://drupal.org/node/1006072#comment-3863790 ?

Yes yes that all makes sense.

But. We had a broken system. We've now got a MORE broken system. We have a better system on the horizon. There's an obvious flaw there.

And thousands of people implementing hook_wysiwyg_editor_settings_alter() in a custom module is a massive waste of collective time.

We did not know people were using the default toolbars for production use at all, everyone who had enabled just the buttons they needed never noticed this change, as was intended.

The decision to not show the editor's toobar was made because it was the only reasonable default state in line with Drupal's guidelines. That and because people were constantly misunderstanding what happened once they started adding buttons to the toolbar. Now "no buttons enabled" really means "no buttons enabled" rather than "all buttons enabled, including those that don't work well with Drupal's input formats", and enabling one button no longer means "enable one button but remove those already visible".

Had we anticipated this reaction, then maybe we would have added an option to explicitly ignore the "Buttons and plugins" GUI in favor of using the editor's own configuration files and let the user set things up manually. As for adding code to do that properly now, I'm not sure yet. I'd rather work on making it possible to organize the toolbars generated by Wysiwyg and have them utilize the editor's toolbarfeatures properly, but I don't have time to do that right now because of work on other projects.

EDIT: Actually, Wysiwyg is less broken now because it does what the GUI says it should do. ;)
EDIT2: Thousands of people are already using per-site custom modules, an not all of them are going to want to change things in the same way anyway. So rather than downloading that tiny pointless module and add yet another hook implementation, it'd be less work to all the customizations they need in a single hook.

Where is this other module? I'd like my less broken WYSIWYG back!

I'm going to be the noob here.

I should explain that I am much more comfortable programming to API standards for machine to machine communications, humans are much too contradictory.

I know that TwoD has mentioned before that there are numerous buttons that don't make sense to have enable because the input mode won't support them. I would ask that as a courtesy to those of us (namely me) who don't know what features are supported by which filters that TwoD or someone else with the knowledge post a list of suggested buttons for filtered and full html input modes.

I currently only enable a wysiwyg editor (CKEditor to be precise) for the Full HTML input mode since I see no need for it on filtered mode. I also do not enable it for php mode. That being the case, a list of appropriate buttons for the Full HTML input mode would be greatly appreciated and I can deal with styling issues elsewhere.

Having read the arguments put forward by sun and TwoD I have to agree with them.

temporary suggestion: add two sub modules, one for filtered html buttons and one for full html buttons

each with it's hook to implement the buttons, for at least ckeditor and tinymce.

Priority:Normal» Critical

This is so ridiculous. I'm a newbie and when i finally got ckeditor in the library and wysiwyg as the module; i was wondering where the toolbar was. And by the way there needs to be some specification of what is a module and what is a library. I was shocked to see from this thread that i have to enable them individually. This is a major usability issue and i was seriously thinking of quiting all together. This just makes it too hard to use and leaves the user confused.

you guys are thinking as programmers and not as users.
admins and designers already have a hard day guessing what programmers mean, now imagine users ;)