Provide some kind of default toolbar that is similar to each editor's default

You're right about us not having to create a universal default toolbar layout (which wouldn't be possible simply because, as you say, the editors have different features and buttons), but in the end we do have to create a universal system that can handle all the properties of the layout (sorting, separators, grouping, multiple rows). Implementing that separately for each editor would be a pain to maintain and create lots of similar code in each editor implementation.

This has been discussed several issues before, including the one you mention, but I'll provide a quick summary here.
What we need is a universal way to store the toolbar serialized in the database, like a multidimensional array $toolbar[row]][group][button] and a universal identifier for separator "buttons" (pipe "|" seems good). This common ground is needed so the toolbar UI can read/manipulate/write the data, and to have a common structure for defining the initial state for each editor.

The very basics for this is already in, buttons are stored as a simple array holding button names and transformed to what the editor can use by the settings callback before the settings are passed to the client. If we're willing to accept that groups, separators and multiple rows support won't be in with the first version of these default layouts, it's a much smaller task that'll take less time to do and it'll be easier to focus on just getting the initial toolbar contents in there. Wrapping issues will persist until at least multiple rows support can be added in a later task/issue/patch.

My main concerned about creating a "default toolbar" layout for each editor is which buttons to enable by default. The most obvious answer is, as you say, what matches the editor's default layout best, or all of the supported ones.

But one of the intentions with associating an editor profile with an input/text format is that you always know that what you're able to create with the editor will also be accepted by Drupal. If we enable all buttons by default, admins ought to disable all those not supported by the format they've assigned it to in order to not confuse the users.

So, in a follow-up issue to this I'd like to see a discussion on how to improve the admin experience when customizing the default toolbar (no matter what the button layout ends up being). To be more specific: how can we give the admin a hint about which buttons are usable with the current filter/format settings? This has also been discussed before, but it needs to be broken out into its own issue as a subsequent task, if "only" to summarize and implement it.

What do we do about older editor versions where some buttons didn't exist? To simplify, It's been said to base the layout on the current editor versions only, and only make exceptions for older versions if having the newer buttons in there causes major problems. Acceptable?

I have some time off from work soon which I'll try to invest into a patch for this, but everyone else is of course welcome to begin implementing things before that.

I've only got a few minutes to left to finish this in so sorry if it leaves things unanswered.

An advantage of the universal toolbar abstraction is I can switch between editors without having to reset my toolbars.

You misunderstood me. The layouts and definitions, ie what features/buttons are available and how they are placed, will be unique for each editor. I'd never attempt to abstract that out and it would probably be impossible to pull off.

What needs to be abstracted is the background system for handling the toolbar definitions in code, like storage and UI for placing/moving/removing buttons, much like how "Buttons and Plugins" is populated now. The editor implementation hands over a list of plugins and buttons the editor supports, as well as information about the "toolbar features" it supports. With this information Wysiwyg's core can handle creating GUI widgets for each button, making them draggable, show tooltip data, enable/disable plugins based on which plugins are available etc. If the editor says that it supports grouping and/or multiple rows, Wysiwyg knows to create an "Add group/row" button and how to pass that data back to the editor implementation so it can translate it to the format used by the editor.
The feature set would be unique for each editor, but the UI for configuring them would work the same for all editors that support the same type of features.
There's a lot of discussion about this, and visual mockups have been made to discuss GUI/UX problems, that entire was tackled as a single massive effort in #277954: Allow to sort editor buttons but it became very hard to review, which is why we need to take this step by step.

Without abstracting away the handling of those parts we'd have to implement the GUI and background logic all over again for each editor. Wysiwyg would in practice become a bundle of all the editor-specific modules out there. Obviously not something we want.

With all due respect, the focus has been on technological sophistication, and usability has taken a back seat. That is ironic since the whole point of WYSIWYG is usability. I think you need to reverse this: all changes need to directly enhance usability or provide for planned, future enhancements

This is exactly why we need a generic system for handling toolbar buttons/groups/rows and advanced settings provided by the editor itself or external plugins. We don't have now as everything you see under admin/settings/wysiwyg/profile/#/edit is based on TinyMCE and there's no way to override that in the wysiwyg/editors/editorname.inc files. That is what results in the poor usability.

To get better usability, we can't try to mash fixes to everything that's been identified as poor UX into one massive patch again. That most likely results in a bad DX, which later likely leads to UX regressions because the code is hard to work with and it's easy to make mistakes that users see as quirks in the GUI.

So, in terms of steps likely to become patches:

1. Set up default toolbars. Toolbars look bad but work.
2. Add button ordering. Still looks bad but now I can make them look bad in any order!
3. Add support for multiple groups, rows and separators. Not as bad looking anymore!
4. Add support for overriding the profile configuration GUI to Wysiwyg Core. Doesn't change anything visually, but the potential is there for an editor to make changes.
5. Add support for letting plugins do the same.
6. Remove TinyMCE specific settings from the profile configuration and put them in tinymce.inc (or tinymce.admin.inc) so they only show up for TinyMCE.
7. Add support for the settings that resemble the TinyMCE-specific settings to other editors, if there are any.
8. Add GUI widgets for the most often changed settings for the more popular editors.
9. See if any of them are specific to plugins and only need to be shown if that plugin is enabled (which perhaps depends on whether a button is enabled)
10. Add as many other settings we can for all editors.

See what I mean?

That is pretty much the plan. The framework for better toolbars and advanced settings, along with a few other things like offoading library handling to Libraries API will be the beginning of 3.x.

I don't have the powers to manage releases etc though, so Sun will have to comment on that part.

@Aren Cambre:

somewhat broken but usable is better than unbroken and unusable

You must have missed the tons and gazillions of (bogus) bug reports against this project that basically said:

I enabled editor Bar, but when I use button Foo, it DOES NOT WORK!

Even though your (technically-oriented?) perception might be different, most of the users do not understand why a button/plugin "Foo" does not effectively do Foo, even though it's available.

It's even available by default. But the most common and popular UX guidelines just tell you the right thing: Use valid defaults.

The previous (native editor) defaults were anything, but not valid. More than 90% of the defaults were invalid for Drupal core's default text format.

They were not even compatible with any of the default text formats. To effectively use an editor's default toolbar, you had to customize an existing format (remove *all* input filters) or create a new, custom text format (containing no input filters). And doing that entirely contradicts Drupal's underlying security design and considerations regarding text formats. I'm sorry to have to state it directly, but this is the point at which your arguments don't hold any water.

I'm happy to discuss this topic and further exchange objective arguments, but let's please make sure that the arguments we're raising are sufficiently grounded and do not entirely contradict the common user experience as well as support issues we are seeing in this project's issue queue every single day.

We DESPERATELY need to develop a usable method for building acceptable toolbars sooner, rather than later. The attitude here seems to be, "let's leave things broken until we have the super-duper toolbar design solution." This has been the case now for over a year. Meanwhile, it's impossible to build a functional wysiwyg implementation with this module without the toolbar issues so clearly shown by ckeditor when you have more buttons than the width of the editing area. You get a tangle of strange triangles that make the editor look unusable and broken. (http://drupal.org/node/820652) This issue is exacerbated by the fact that the USABLE ckeditor module will not be upgraded for Drupal 7, so we're forced to use wysiwyg with its broken interface. (correction, I now see that someone has built a D7 ckeditor module, yay! But it still won't work with other contribs like the media module)

Can I propose an intermediate solution to this issue? If you look at the excellent ckeditor module, you'll notice that developers can create a set of custom button sets in a definition file. (ckeditor.config.js) In fact, most wysiwyg editors provide a way to build a custom button definition in a profile file. Yes, this does require the developer to custom code the button definitions, but this option allows for a highly customized and excellent toolbar. In most cases, the developer doesn't want users to define the toolbars anyway. And custom toolbar definitions reside in code, can be copied easily to other Drupal installations and managed by version control. Allowing developers to custom code the toolbars (which would overrule the custom button selection option) allows us to use the wysiwyg module effectively, save setup time, and build beautiful toolbars with separators and groups.

Here's how I see this working:

1) In the UI, give the user the option to EITHER select buttons from a list as is currently done, OR use a custom coded toolbar definition file. (at least for wysiwyg editors that allow this, like tinymce, ckeditor, & fckeditor) If the users choose the custom toolbar definition option, the button select form is disabled.

2) Provide a lookup path to "sites/default/libraries/toolbars" for this custom toolbar definition. That way, the custom toolbars aren't overwritten when users update the wysiwyg module or the wysiwyg editors themselves. (Much like the ckeditor module uses its own ckeditor.config.js file instead of ckeditor's default toolbar definition file, ckeditor.js) Developers who choose to define custom toolbars are responsible for reading the documentation from their respective favorite editor. But once the coding work is done, developers can then reuse this definition file on multiple Drupal installs.

3) Finally, at some point in the distant future, you guys can offer the "super duper toolbar design tool" but in the meantime, we'll have an alternative way to define a nice, professional wysiwyg toolbar for ourselves and our customers, in code.

PS: I hope this explanation made sense, and I hope I'm not overlooking some other obvious solution, but frankly, there are so many issues on wysiwyg it's hard to read or understand them all. :-)

The attitude here seems to be, "let's leave things broken until we have the super-duper toolbar design solution."

No, but we do have a lot of editors to consider that all use different approaches to defining a toolbar layout, so we must abstract away that definition to not have to create an unmaintainable mass of editor-specific code. See why that has taken so long in the discussion above (and in the related issue of course).

Can I propose an intermediate solution to this issue? If you look at the excellent ckeditor module, you'll notice that developers can create a set of custom button sets in a definition file. (ckeditor.config.js)

1) If you want that, implement hook_wysiwyg_editor_settings_alter() to include the config file and unset the toolbar definition (an any other setting for that matter). Like you say, this requires some knowledge and custom code, but it'll allow you to do exactly what the ckeditor.module does.

2) Not needed, users can place the custom config files anywhere (if the editor supports them at all), just say where to load them from in hook_wysiwyg_editor_settings_alter().

3) Already possible, see 1 and 2. ;)
Yes, there are a lot of issues, but I think we (maintainers) will have more time to deal with them now that D7 is almost done. We're also about to split the larger issues into smaller tasks so they won't be so hard to overlook and it'll be possible to make progress in small steady steps rather than huge leaps with tons of new code (yeah, I'm talking about the button sorting issue).

TwoD,

Thanks for your measured and patient response to my diatribe. :-)

I know it must be a nightmare to support so many different wysiwyg editors. Sometimes I think us Drupal developers lose sight of the end goal of Drupal, which is to have a friendly, functional website, not a developer toolbox full of cool tools. :-) I commend the patience of the wysiwyg developers for trying to be all things to all people.

If you want that, implement hook_wysiwyg_editor_settings_alter() to include the config file and unset the toolbar definition (an any other setting for that matter). Like you say, this requires some knowledge and custom code, but it'll allow you to do exactly what the ckeditor.module does.

I've seen reference to this option, but frankly, haven't understood its implications, as I am not a php or module coder. (yet) Is there any significant documentation on how to implement this hook for non-coders? I don't mind slogging through the learning process if I have a little direction. And, as a documentation specialist, I wouldn't mind writing up a comprehensive article on how to implement a ckeditor solution, if I could figure everything out. I'm just looking for an interim solution that will allow website developers to build a consistent, quality wysiwyg solution that can be easily replicated on several Drupal websites without the pain of reconfiguring the wysiwyg editor every time. (which one has to do with the ckeditor module, since it can't be packaged as a "feature") The wysiwyg module provides the plug-n-play solution, if only the toolbars were working.

Ckeditor and Tinymce are perhaps the two most popular wysiwyg editors with ckeditor taking the lead. Having a drop-in code solution for ckeditor, where a developer could copy some hook_wysiwyg_editor_settings_alter() code into a sub-directory, with a custom button file, would allow us noob Drupal devs to accomplish our goals while we wait for a comprehensive solution. The wysiwyg module seems to be the future of Drupal, so it's important to build a solution for it.

If you can direct me to some posts on how to implement the hook_wysiwyg_editor_settings_alter() solution, I'll happily share my final solution (and documentation) with the community.

One other thought: how much effort would be involved in a knowledgeable module developer throwing together hook_wysiwyg_editor_settings_alter() code and a ckeditor toolbar template as a sub-module to the wysiwyg module? This would seem to be far quicker than writing the toolbar button gui and would provide a good quality "ckeditor" solution for hundreds of Drupal websites until such time as the full solution is completed. It would also promote the wysiwyg module as the ultimate solution in Drupal 7, which will be essential for other partner modules like the media module.

@zoon_unit, The main documentation for that hook will be provided in wysiwyg.api.php, but there are samples scattered throughout the issue queue as well. See #964978: Document hook_wysiwyg_editor_settings_alter().
Simply put, that hook can alter the settings object (sent to the editor when an instance of it is created) any way it likes. Settings can be added/removed/modified without Wysiwyg taking damage. I won't go into more details on that here since it's dragging the issue off topic, but have a look over in #313497-52: Allow configuration of advanced editor settings

To export/import/migrate editor configurations, see #624018: Exportables and Features support for WYSIWYG 7.x. This is a bit complex for D6 since it only provides numerical ids for input formats, but D7 has improved that situation a lot.

I recently posted some code over at #829266-47: Fixing toolbar for the CKeditor / Using the settings hook which could be used to order CKEditor's buttons nicely. It can be reused for several sites which need not have the same buttons enabled as it compares the list buttons under admin/settings/wysiwyg/profile/#/editor "Buttons and plugins" with an internal toolbar definition and keeps only those from the internal layout that are in that list.
That code could easily be turned into its own module and expanded to work with other editors based on the same principles. My first goal with that code was to make it step out of the way automatically once Wysiwyg gains these capabilities on its own, but my client at the time was not interested in that.

TwoD,

Thanks for the information! I will dig into this in 2011.

subscribe

+1

+1