Enhance FCKeditor support, Patch for multiline support

There is only rudimentary support for FCKeditor currently. Developers/maintainers of the FCKeditor Drupal module promised to take over this work and told me not to do anything about it. So if you want to see enhanced FCKeditor support, please bug them, not me. ;)

Also, since FCKeditor implements many advanced settings like TinyMCE, and the current profile configuration form is still based on the obsolete TinyMCE module, this issue slightly depends on #313497: Allow configuration of advanced editor settings. That doesn't necessarily mean that the basic editor configuration cannot not be improved in the meantime though ;) (such as adding a resizable grippie)

Wysiwyg's integration of editors in Drupal is far ahead of FCKeditor module's. However, you have almost no control over FCKeditor's configuration in Wysiwyg currently. Enhanced support for FCKeditor will be ready when it's ready - either done by FCKeditor developers or someone else who takes this on. So the answer to your question heavily depends on what you need. My biased recommendation is to use Wysiwyg module, of course. The more people are using it, the increased will be the demand for better FCKeditor support.

I wish I had more time to dig into it already at this stage. Be patient and the better FCKeditor support will come, I promise. I wish all the best to this project. As sun noticed, when Wysiwyg API will be complete, this module will simply beat all other wysiwyg modules. Currently, if you need a better control over FCKeditor, use the FCKeditor module. If, however, you can live without additional FCKeditor plugins and all other custom configuration settings that FCKeditor module provides, use this module and support its development.

@wwalc: Not to stress on you, but there is a great amount of users that are awaiting better support for FCKeditor in Wysiwyg API. When do you plan to start contributing some code?

I'm attaching a patch that will make the "Buttons" configuration in the Wysiwyg profile working properly.

A hack with a special plugin is required to define FCKeditor toolbar dynamically. This plugin must be loaded in the configuration file.
Because it would be a pitty if people would have to adjust the configuration file each time they upgrade FCKeditor, another "custom" configuration file is used: fckeditor.config.js.
We actually do need this file to load the plugin mentioned before and set some default (Drupal specific) settings.

PluginsPath has been changed into wysiwyg/plugins, because it is a better idea to load plugins form a directory outside "fckeditor" root directory (again, if one decides to upgrade FCKeditor, all plugins could be lost after deleting the "wysiwyg/fckeditor" folder).

Regarding directory structure... it seems that plugins should be divided into subfolders, for example "break" plugin works only with TinyMCE, so imho it should be in a "tinymce" subfolder. There is a similar problem in "editors/js" directory. There are already two files for TinyMCE (tinymce-2.js and tinymce-3.js), I have created another file: fckeditor.config.js.
To keep things clean, I think we need separate subfolders.

...ok this one should be better (new files are included in a patch)

Thanks for giving this a shot, wwalc!

I do not think that we need fckeditor.config.js at all in Wysiwyg API. The reason is that each and every configuration option needs to be configurable via the UI (in the long run).

Based on the code of this patch, we can skip both fckeditor.config.js and plugins/fckeditor/dynamictoolbar/fckplugin.js, and just pass the toolbar button configuration via Drupal.settings (i.e. in the returned $init (settings) array of wysiwyg_fckeditor_settings(), which is directly passed to Drupal.wysiwyg.editor.attach.fckeditor() in JS). So, in the end, FCKeditor either uses its default toolbar, or the custom one configured in the wysiwyg profile.

If required, we can initialize the toolbar via Drupal.wysiwyg.editor.init.fckeditor() for each input format first. However, I do not really think that we need an init() function for this.

Aside from that, the 'plugins' folder is intended for editor plugins only. Editor plugins should not contain any editor-specific code - see #319363: Rewrite editor plugin API.

I feel sorry that you had to copy this code from tinymce.inc:

  if (!empty($config['buttons'])) {
    foreach ($config['buttons'] as $plugin => $buttons) {
      foreach ($buttons as $button => $enabled) {
        // Iterate separately over buttons and extensions properties.
        foreach (array('buttons', 'extensions') as $type) {

Yes, that's the current, awkward way of walking through plugins - so, what you did is actually correct, but the plugin registry needs a major overhaul as well (separate issue).

However, this part in fckeditor*.js should not be removed:

-//  else {
-//    tinyMCE.triggerSave();
-//    tinyMCE.remove();
-//  }

Instead, the uncommented code needs to replaced with proper code to detach all editors from all form elements in the passed context - see markitup.js for a proper example. That's a separate issue though (so, removing that hunk from this patch would be sufficient).

The following changes also seem to be unrelated to this issue:

+// Protect PHP code tags (<?...?>) so FCKeditor will not break them when switching from Source to WYSIWYG.
+// Uncommenting this line doesn't mean the user will not be able to type PHP
+// code in the source. This kind of prevention must be done in the server side
+// (as does Drupal), so just leave this line as is.
+FCKConfig.ProtectedSource.Add( /<\?[\s\S]*?\?>/g ) ; // PHP style server side code
+
+//Set to 'encode' if you want to obfuscate emails with javascript
+FCKConfig.EMailProtection = 'none' ;

Ad) fckeditor.config.js
This is actually a limitation of FCKeditor 2.x. There is no other way to pass anything else than a string as a configuration directive outside of the configuration file.
So we need this file to pass the folowing configuration option:

FCKConfig.Plugins.Add( 'fckeditor/dynamictoolbar' ) ;

If we can't have a file, the other option is to create this file dynamically (hook_menu + function)
Ad) plugins/fckeditor/dynamictoolbar/fckplugin.js
This is actually a plugin that must be editor specific. This is a hack for FCKeditor to be more compatible with Wysiwyg module, so that we could create a toolbar dynamically (it is not doable in FCKeditor). This plugin will never become "generic" and will not work with any other editor.

Now things that have been added to make FCKeditor user friendly:

Ad) Wysiwyg toolbar definition in fckeditor.config.js
At this moment, by default "Default" toolbar is enabled in FCKeditor. This is simply wrong. General purpose of "Default" toolbar is to show all capabilities of FCKeditor.
We should not scare people with 100s of buttons enabled by default.
If anyone decides to compose his own toolbar, he will be able to do it (as long as the dynamictoolbar plugin will be available).
So the Wysiwyg toolbar is a sane default value, which is sorted in a reasonable way (that's why I haven't used a list of default buttons in fckeditor.inc #277954: Allow to sort editor buttons - again, we do not want to scare users having a set of unarranged buttons).

Ad)

+// Protect PHP code tags (<?...?>) so FCKeditor will not break them when switching from Source to WYSIWYG.
+// Uncommenting this line doesn't mean the user will not be able to type PHP
+// code in the source. This kind of prevention must be done in the server side
+// (as does Drupal), so just leave this line as is.
+FCKConfig.ProtectedSource.Add( /<\?[\s\S]*?\?>/g ) ; // PHP style server side code
+
+//Set to 'encode' if you want to obfuscate emails with javascript
+FCKConfig.EMailProtection = 'none' ;

My intention was to make FCKeditor usuable as much as possible with current Wysiwyg limitations. It could be actually added to wysiwyg_fckeditor_settings()... but this way we are adding another bytes to each generated page. fckeditor.config.js is downloaded once and then cached in a browser.
We may drop these two things as soon as there will be another way to do it (#313497: Allow configuration of advanced editor settings). In the meantime, let's simply make FCKeditor implementation more user friendly.

Well, thanks to your low-level input, I was able to implement the dynamic toolbar the way I imagined it.

Please note that this patch contains some more clean-up. (fckeditor.inc was the second editor support file in Wysiwyg API and has not been touched until now.)

On a sidenote: If FCKConfig.ProcessHiddenField() in editor/internals/fckconfig.js would support parsing of objects/arrays, the entire setup of a dynamically defined toolbar would be much more trivial. Currently, FCKeditor still seems to follow the paradigm that users of this editor _have to_ edit arbitrary configuration files by hand. That's pretty old-school.

Committed the clean-up changes separately.

Good job, it's working as expected.
There are just few minor things that should be corrected, I'll try to attach new patch tomorrow.

In short:
- buttons that are commented out could be removed from the code, we should keep just the necessary things
- the alternative names for buttons should be corrected:
"CreateDiv" -> "Create Div Container"
"ShowBlocks" -> "Show Blocks"
"SpellCheck" -> "Check Spelling"
...and so on. Ideally, the same values as in FCKeditor should be used to avoid confusion.
- the "buttons" and "format" settings shouldn't be passed to FCKinstance.Config array, it should contain only valid values

btw, what are the "Create DIV container" and "Show blocks" buttons for? (ie. what do they do?) Is it possible that they are equally useless in Drupal?

We can remove settings.buttons, but not settings.format, since that is required for fckeditor.config.js.

"Create DIV container" creates div element and displays a nice dialog box with various options for this div element.
"Show blocks" shows a thin border around all block elements in the editing area.
Both buttons can be useful without any special preparations. On the other side, buttons like "Checkbox" or "Textarea" are not available, because noone actually will use it in Drupal.

After reviewing patch from #14, I have decided to attach another patch (based on patch from #14):
- I have sorted all the buttons in a similar way as they are sorted in the Default toolbar, renamed some of the buttons to keep their names as similar to internal names used in FCKeditor as possible
- By default, all built-in FCKeditor buttons available in the Wysiwyg profile will be used instead of "Default" toolbar. This way user will not have to search where does this toolbar come from and will have less reasons to touch the fckconfig.js file
- dropped some settings, that are set by default in FCKeditor, there is no need to redefine them:

'DefaultLanguage' => 'en',
'AutoDetectLanguage' => TRUE,
'ToolbarStartExpanded' => TRUE,
'EnterMode' => 'p',
'ShiftEnterMode' => 'br',

- in fckeditor.config.js I have added a trick required by FCKeditor so that Wysiwyg toolbar was not cut off when too many buttons are enabled.
Note that the default toolbar is splitted into smaller arrays:

FCKConfig.ToolbarSets["Default"] = [
	['Source','DocProps','-','Save','NewPage','Preview','-','Templates'],
	['Cut','Copy','Paste','PasteText','PasteWord','-','Print','SpellCheck'],
	['Undo','Redo','-','Find','Replace','-','SelectAll','RemoveFormat'],
	['Form','Checkbox','Radio','TextField','Textarea','Select','Button','ImageButton','HiddenField'],
	'/',
	['Bold','Italic','Underline','StrikeThrough','-','Subscript','Superscript'],
	['OrderedList','UnorderedList','-','Outdent','Indent','Blockquote','CreateDiv'],
	['JustifyLeft','JustifyCenter','JustifyRight','JustifyFull'],
	['Link','Unlink','Anchor'],
	['Image','Flash','Table','Rule','Smiley','SpecialChar','PageBreak'],
	'/',
	['Style','FontFormat','FontName','FontSize'],
	['TextColor','BGColor'],
	['FitWindow','ShowBlocks','-','About']		// No comma for the last row.
] ;

this way, if there is too little place for buttons, FCKeditor moves another subset of buttons into the next line.
We had one long subset of buttons, thus FCKeditor was unable to split this long array into smaller chunks.

This code:

  var buttons = window.parent.Drupal.settings.wysiwyg.configs.fckeditor[FCKConfig.PageConfig.format].buttons[0];
  FCKConfig.ToolbarSets['Wysiwyg'] = [];
  for (var i=0; i<buttons.length; i++) {
    FCKConfig.ToolbarSets['Wysiwyg'].push([buttons[i]])
  }

creates the correct array of buttons.

There is a little problem with this approach. FCKeditor configuration assumes that buttons are organized into subsets containing around a couple of buttons and adds visual separator between each subset. Unfortunately having subsets of one button each looks awful, there is a separator after each button. The line below removes it.

  FCKTools.AppendStyleSheet(document, '#xToolbar .TB_Start{display:none}');

I'm trying hard to avoid scope creep in this issue...:

- Ordering and placement of buttons: #277954: Allow to sort editor buttons - Any other approach is a waste of time, just adds support requests, and cruft we need to understand (and support) until we fixed the real issue.

- I purposively re-ordered and renamed the buttons a) to make them comparable to other editors (not only code-wise, but also in the profile configuration UI) and b) to use the same strings for t() for all editors, which means that translators are not faced with different strings having the same meaning.

Of course, we should not define settings that are the default settings for an editor.

However, by default, i.e. when a user does not configure an editor, each editor should use its default toolbar and configuration. Even if this might expose additional buttons that are not configurable otherwise, this is not only an easy way to test an editor for users, but also the best way for developers to test whether an editor works with a minimum of custom configuration.

So, I think the only further change I would prefer to see in this patch is the removal of FCKeditor's default settings from the $settings array. If you agree, then I can just remove them from #14.

Ordering and placement of buttons
There is one thing in my patch that I think is worth of committing. It fixes the problem with buttons that are stripped from the end of the toolbar. It is quite an important issue as it makes impossible to use FCKeditor with more than a couple of buttons (by someone with 800px wide screen for example). How about including this fix in a patch?

I purposively re-ordered (the buttons)
Although I understand your intention of making all editors similar to each other, there is a little drawback of such attitude - note that users got used to the specific order of buttons in each editor. Anyway, after implementing #277954: Allow to sort editor buttons this will not be a problem.

and renamed the buttons to use the same strings for t() for all editors
ok, that makes sense.

Applied the same logic, resp. stylesheet override, for the editor UI like for TinyMCE to wrap the buttons on a single toolbar.
But, again, this is a temporary solution - I'd rather invest some time for working on the advanced configuration / sorting issue(s).

Committed the changes we already agreed on separately.

Attached patch just adds the toolbar button wrapping via CSS (temporary, until we have proper placement/position support).

Re-rolled due to #364782: Stylesheet of sub-themes not loaded

The attached patch doesn't work as expected:
- it doesn't work at all in IE 6/7, Safari 3
- in Opera "select" elements are incorrectly resized (higher than they should be)
- in FF2 when selecting font/format/size, the select box appears in wrong position
- it doesn't work properly with silver and office2003 skins when select element is in the toolbar
- height shouldn't be set to 22px; because skins provide buttons with different height
Although it seems to be a correct approach to simply style toolbar buttons with CSS, it can't work, because floating table cells containing nested tables will simply not work due to browsers limitations. It wouldn't be a problem if we had buttons surrounded by divs, nested lists or even tables, but having only table cells it's impossible.

The attached patch works in a similar way as the patch in #15:
- it sends to FCKeditor a set of buttons in a special way, FCKeditor transforms them to separate tables (instead of table cells) with float:left style (it's working in all browsers).
- three FCKTools.AppendStyleSheet calls remove the separator between buttons in three basic skins provided in FCKeditor: default, silver and office2003

applied the patch from #22 to the 6.x-2.x-dev version from Feb-21
and it works for me, the toolbar is now wrapped into three lines

as i understand it the other patches are already committed to the dev version so i wont test those

What is the status of this issue?

I have the same problem. . . FCKeditor buttons don't wrap in the toolbar making FCKeditor very basic since you can only use a small subset of buttons.

I looked at Wwalc's wysiwyg-DRUPAL-6--1.fckeditor.toolbar[1].patch but that doesn't work since I guess I have a later version of WYSIWYG and the code in fckeditor.config.js does not match what's in the patch.

subscribing

I'm with austintnacious: since a patch exists, I thought it would have been integrated a long time ago. Weeks later, I see I still have to patch it. What's the delay here? Too bad that what appears to be such an easy fix leaves an otherwise great project crippled.

I agree that the patch #21 is absolutely necessary when using FCK Editor in a Live Environement.

Because the buttons won't float, the toolbar has only one line. This patch fixes this issue

I'm using the new WYSIWYG API 6.x-2.0-alpha1. I converted the proposed patch for the new version and tested in thouroughly. It works and is ready to be committed to the dev version.

The buttons will float automatically (IE 6/7 / FIrefox 2/3 tested).

I tried the patch - For me FF3 crashes every time I try to go to node/edit and FCKeditor tries to load.

I installed the latest dev version from 6/8/2009 and it doesn't contain these changes. The patch still needs to be applied. fyi...seems to work in FF3 though.

Thanks for reporting, reviewing, and testing! Committed with slight modifications 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.

Verified in latest dev build

This has been committed already.

I've just updated to the latest 2.x development snapshot and the latest version of FCKeditor to try and resolve the issue of the toolbar being only one line, meaning all the tools that don't fit just disappear off to the right. This issue still exists, along with a new one: when I select the buttons for table manipulation (add/delete rows etc) they cause errors when the editor is coming up on screen.

I've tried a little CSS to get the toolbar to wrap, with no joy... Am I missing something or has this still not been resolved?

Cheers for all the hard work on this.

Steve

Yes, also still having this problem (WYSIWYG API 2.x plus FCKeditor 2.6). Why is this still not functioning?

This is a neverending story. You have entered the twilight zone....wysiwyg + fckeditor = one button row no matter how many buttons you choose. patches were supposedly committed to the module...but then suddenly you're back at the cafe and it's 1968 all over again...Rod Stirling just outside the door talking the camera.

If you're still experiencing issues in the latest -dev versions, please reopen the issue (or rather, start a new one since this one is a bit cluttered) or we can't see it other than by chance when looking for something else, like I just did.
Please also provide information about which theme you are using, styles or markup which might be interfering and possibly a screenshot of the problem so we can do something about it.
We can't fix what we can't see and I've not seen this in any browser I'm using.