Hide the toolbar button

Heh... you found that. There is a way (using an alternate method of attaching the plugin) to make this work, but I'm going to have to put that effort on hold a little while until I get more time for testing.

Just a quick FYI:
The optimal solution would be to allow Wysiwyg cross-editor plugins like this one to define pure button-less extensions, like the native plugin hook can, but we've had not time to prioritize that yet. Currently, Wysiwyg expects each plugin to use a button, and the distinction between the button and plugin internal names are not clear enough. Hence why this module's button is forced to exist...

@TwoD - I was trying to use hook_wysiwyg_plugin(), but it seemed that method only got me part of the way there (my plugin was recognized and added to the configuration pages, but it didn't catch when the editor attached/detached from a textfield). Are you saying this is not yet supported? I know that there are a few different API issues being cleaned up in WYSIWYG, but I didn't know if this was one of them...

Only metadata for native editor plugins can be handed to Wysiwyg via hook_wysiwyg_plugin() - that is a plugin written to use only a specific editor's API and often knows nothing about the Drupal environment. You'd need to hook into each editor's own event system to find out when the editor is initialized or destroyed, if it's possible at all. Not very interesting for this use case as it would mean a lot of extra code and APIs to keep track of.

The hooks currently used by this module are for cross-editor plugins, written to use Wysiwyg's and Drupal's APIs.
Currently, this is the only way to know when an editor is attached or detached, as the plugin's JavaScript methods attach() and detach() are called. Note however that these are always called when content is fetched from or set to the editor, so don't count on the editor being gone after a "detach" call.

In the plans for Wysiwyg 3.x, we've said that "events" need to be triggered when things like this happens that anyone can act on, not just plugins. They also need to be more clearly defined so one can act only when the editor is destroyed, selection changes, content is fetched etc.
That's going to take time though, so it's better if we can let cross-editor plugins be button-less too before that.

I see - is there an issue I can follow/support to help get buttonless plugins to be a reality?

Not that I remember, no.
But, I just added #1050340: Let cross-editor plugins be button-less (aka 'extensions') =)

EDIT: I made that a request for 7.x-2.x since that's where we add new things first, and then backport if possible.

Sounds good! I'll mark this postponed pending the conclusion of that issue.

Another slightly hackish solution is to use some targeted CSS to hide the button like:

/* Hide the linebreaks button. */
body .cke_skin_kama .cke_button a.cke_button_linebreaks,
body .cke_skin_kama .cke_browser_gecko .cke_button a.cke_button_linebreaks {
  display: none;
}

@mfer - hmm... that looks like a pretty good short-term solution (until #1050340: Let cross-editor plugins be button-less (aka 'extensions') is solved), and I just need to add in the CSS for TinyMCE as well.

@geerlingguy note that what I included is just for the one skin. It doesn't work for all skins.

I'm going to add:

/* Remove toolbar button from WYSIWYG Editor toolbars. */
.cke_wrapper .cke_toolgroup .cke_button .cke_button_linebreaks, /* CKEditor */
.text-format-wrapper .wysiwygToolbar .mce_linebreaks /* TinyMCE */ {
  display: none;
}

This hides it from both CKEditor and TinyMCE. (Note: Instead of doing something per-skin, I just chained enough CSS class selectors together to override the button in any CKEditor skin. Sadly, that's the easiest way, though it uses a lot of selectors!

I need to now determine how to set the CSS to be only included when there's a WYSIWYG editor enabled on a page... not an easy task, I think. I'm tempted to just add this as a css file to be included by default.

Committed to D7 branch: http://drupalcode.org/project/wysiwyg_linebreaks.git/commit/35a3571
...and to D6 branch: http://drupalcode.org/project/wysiwyg_linebreaks.git/commit/9ca57d3

(I'm going to keep this issue marked postponed until we can implement a proper fix, taking into account the results of #1050340: Let cross-editor plugins be button-less (aka 'extensions')).

Updating version.

Somehow wysiwyg_linebreaks.css doesn't seem to be included (Drupal 6.20). Any idea why?

I see that plugins/linebreaks/linebreaks.css is included, though.

@hba - it should be, but can you tell me which editor you're using, and which checkbox you have checked on your WYSIWYG editor settings page?

The CSS classes did not longer work. Rolling new version of this hack for D6 and 7.
Tested on D6.x
TinyMCE 3.5

It doesn't work in latest CKEditor 4.x either. I tried to target it specifically, but still did not work (notice that the class now has a double underscore):

div.cke_inner span.cke_top span.cke_toolbox span.cke_toolbar span.cke_toolgroup a.cke_button__linebreaks span.cke_button__linebreaks_icon

Can anyone else confirm/deny that the patch in #17 works?

The included CSS does not work for me using ckeditor on D7. The problem is that there is a more specific selector that sets display: block; ... so we need to be more specific by adding yet another class selector, sigh.

Yeesh. Sigh is right... but this is necessary. I've committed and will hopefully roll out a new release soon.

Commit: http://drupalcode.org/project/wysiwyg_linebreaks.git/commit/4d42feb

Thanx Jeff!

Patch incoming later (no time), this works for D6
/* REALLY Remove toolbar convert_linebreaks button from Wysiwyg Editor toolbars for CKEditor */
.cke_button__convert_linebreaks {
display: none !important;
}

in your wysiwyg_convert.css

*bye*