Allow to configure advanced editor settings

What effect has this property? And which module / plugin / use-case needs it?

Well, I'll explain why I need it and what it does...

Quoting: http://wiki.moxiecode.com/index.php/TinyMCE:Configuration/remove_script_...

If this option is enabled the protocol and host part of the URLs returned from the MCFileManager will be removed. This option is only used if the relative_urls option is set to false. This option is set to true by default.

URL:s will be returned in this format: "/somedir/somefile.htm" instead of the default mode: "http://www.somesite.com/somedir/somefile.htm".

I generate newsletters based on node updated, new or updated notes get automatically included in the newsletters. The node is themed specially for the newsletter and to keep the HTML of the newsletter as standard as possible I use absolute URLs for images.

Now, the newsletter generated can be either sent immediately, which will work just fine, on can be available as a draft for further edition, such as adding some information to that specific newsletter. The problem appears here, as if I edit the newsletter using tinyMCE, once I submit the whole thing, tinyMCE process the HTML and strips out the absolute part of the images urls (if this property is set to true - default), thus,

Changing h**p://example.com/filles/image.jpg to /files.image.jpg. And while the newsletter still looks right as a node within the drupal site, once sent all the images appear broken and I really don't want that.

I would think this might be a rather particular use-case, but it's one nonetheless :).

But the description clearly states this option is for MCFileManager only? Isn't it the relative_urls option you want to change?

Well, if we look at the description of relative_urls at http://wiki.moxiecode.com/index.php/TinyMCE:Configuration/relative_urls

If this option is set to true, all URLs returned from the MCFileManager will be relative from the specified document_base_url. If it's set to false all URLs will be converted to absolute URLs. This option is set to true by default.

It also states that this affects the MCEFileManager, but the fact is, that tinymce handled its HTML the same way, either if you add it through its filemanager or manually. So if you manually type in the HTML window of tinymce or by disabling the rich-text editor the follwing:

TinyMCE will process those URLs as well as if it would have come from the MCEFileMnaager

And, now you pointed out relative_urls property, which is set to false in the module, it will convert it to 'absolute', but it uses another property for converting the urls to absolute, which is document_base_url and in the module is set to:

And base_path() is generally '/' on a regular site, rather than with the host information which is also fine.

So what I really need is remove_script_host: false that works with relative_urls: false (as it is now) so the host part is not removed from the 'absolute' url.

Thanks,
a.=

Just referring back to the original intention of this request rather than the specific TinyMCE setting involved...

It would be very useful to have some extensible way of tweaking the TinyMCE init settings without editing the module code - I didn't spot any obvious method for doing this.

The original TinyMCE module use an overridable theme function for this, but maybe a hook_somename_alter() that works directly on the init array might be an alternative? A Drupal 6 version of the module could possibly use a template preprocessing hook instead.

I don't know enough about other editors to judge how applicable this would be across different editors. Would different editors need different customisation hooks?

Is this something that would be considered? I will write up a feature request if it is, and when I get closer to testing my migration away from the original TinyMCE module I could create a patch or two.

Now that Wysiwyg API has been completely rewritten to support arbitrary editors, we need a way to configure arbitrary editor settings one way or the other - which makes up point #6 of the overall task list on the project page.

My original intention was to

1) Rename existing profile configuration setting names, which might apply to all editors.
2) Add an editor settings callback, so each editor is able to enhance the profile configuration form.

However, when looking at the existing settings, I fear that there will be editors, which do not even support the simple ones. So it might be best to move all editor settings into a callback function, not providing any default settings for all editors.

Of course, this callback function would be able to add a "Advanced settings" fieldset, allowing to configure the complete range of possible configuration options (TinyMCE 3 example).

My uninformed perspective was similar to your "fear" about handling multiple editors.

I kinda expected that each editor will need its own thin shim like module to connect it into the main WYSIWYG API module and that the shim would define the customisation API (as well as implementing hooks to extend/shrink the common UI) that best suits that particular editor. Of course that wouldn't work for the usecase where a single site has multiple editors installed and they all need to share the same config/profiles - but I'm not sure that is a usecase you plan to support anyway.

Yes - support for multiple, different editors on the same page, for example a fully-fledged TinyMCE for a body field and a minimalistic BUeditor (or whatever) for a simple comment field, is envisioned. However, that's a different topic/issue, and we might want to move further, unrelated discussion to http://groups.drupal.org/node/15643 ;)

I recently came across this issue when I wanted to change the default skin of TinyMCE 3 to the 2k7 look alike. Would it be possible to have an "Advanced User" section where we can edit the inits as a field until an interface comes along, or even some function I can edit in my template.php? I would prefer not to directly edit the module if I can help it.

This also came up in relation to MarkItUp support.

MarkItUp isn't a true WYSIWYG editor; rather it's a toolbar to make it easy to add HTML (or Markdown, or BBCode, or...) to the textarea, similar to BUEditor, but this is a jQuery plug-in.

sun whipped up support for the basic editor in record time, but there are some features missing over http://drupal.org/project/markitup :
1. You can't select the skin of the editor, which means it gets branded as "markitup" by default which is kinda meh.
2. More importantly, you can't change the "set" of buttons, which means you can't use MarkItUp to insert BBcode, for example.
3. You also can't create multiple "profiles," each of which contains a set/skin pair. For example, 'default' for Filtered HTML, 'html' for Full HTML, and 'bbcode' for BBcode.

I am not quite sure how to represent this in the UI without something like a hook_form_alter() that's specific to the wysiwyg edit form and doesn't require a full-on module, but can instead be implemented in the .inc file for a given editor, similar to how the various .profile functions work. But then again, this creates two ways of doing essentially the same thing, which might be confusing and not worth the effort to avoid module-itis.

Subscribing, interested in this all
I think the Wysiwig editor modules should handle the settings and wysiwig module handles the usage.
greetings, Martijn

Subscribing. Correct me if I'm wrong, but at this moment there is no way to change the default Wysiwyg profile form.
"Editor appearance", "Cleanup and output", "CSS" are editor specific settings. By default there should be only "Basic Setup" and perhaps "Buttons and plugins" sections, because these are the only things common to all editors.
Ideally, we need something like hook_form_alter so that this form could be adjusted by each editor.

Yes, that is correct. Most of the current settings need to be moved into tinymce.inc, and each editor needs to define a "settings form callback" to *add* elements to the profile configuration form.

However, there is a reason why this issue languished for a longer time than actually needed: Not only the editor has additional or different settings. There are also plugin-specific settings, which have to be configured when the plugin is enabled. I'm currently trying to find some spare time to investigate CTools, merlinofchaos' new, generic abstraction of Views' and Panels' ajaxified solution to allow contextual forms for configuring statically cached objects. -- What I imagine for Wysiwyg's profile configuration page is a similar page to the views configuration page in Views 2: An editor can add arbitrary "configuration categories" which are added to the basic profile configuration. Each of those categories lead to a form that allows to configure editor settings. And, instead of filters/relationships/arguments, we would have two button toolbars: one that contains all not (yet) used buttons, and another one, where the user can drag'n'drop buttons into (to enable and position them). This is why this issue has some considerable overlap with #277954: Allow to sort editor buttons.

Subscribing - I'm using markItUp! editor and markdown input filter. Needed to use WYSIWYG module instead of the markitup module because it attaches to multiple text fields on the same form.

However I've had to hack the .inc file to provide the buttons I need :(. After reading this issue I see there are much grander plans in store, so I won't try make a patch. Thanks for all the hard work! :)

Hi Mark,

You never know when the plans come to conclusion, so please still provide patches!

Greetings,
Martijn

Subscribing

Subscribing as well. I'm also interested in markitup + markdown.

Subscribe.

subscribe, same as many others with markitup +.

Subscribe

If I add an image without alt text I get a warning box that says "Are you sure you want to continue without including an Image Description".

http://wiki.moxiecode.com/index.php/TinyMCE:Configuration/accessibility_...

If I could configure these settings I could suppress this.

Subscribe

subscribe

subscribe. Hope this will provide a way to increase TinyMCE's tiny display font size.

I would also like to see support for markItUp button sets.

If that was supported you could also provide a "Drupal" set, a set of buttons that exactly mirrors all the HTML tags allowed by default by Drupal for Filtered HTML: a, em, strong, cite, code, ul, ol, li, dl, dt, dd

subscribe

Subscribing. I needed to add 2 custom settings for WYMeditor, and saw that WYSIWYG seems to submit its settings to editors using the Drupal settings js object.

This is a dirty solution, but I stuck this code into my theme's template.php file (not inside a function), and they got merged into the settings sent to the editor.

I'm not saying this is a good way of doing it, just that it worked for me and it didn't require me to hack the module itself.

Likeless, that´s actually a pretty clever workaround IMO. Yes, the settings object is submitted to the editor, but sometimes we add our own settings or alter the format a bit. The general idea is that settings are generated on the server in the format required for each editor and everything not used by the Wysiwyg implementation is passed on to the editor library as is, so adding new settings/parameters is pretty much trivial. What's missing now is a good GUI and some way to version control which settings are available for an editor.

Another great feature would be a way to submit javascript functions to the editors, too.

WYMeditor takes js functions as values in its settings object as a way of defining custom buttons. I expect there are other editors that use js functions as values in their options too.

As I understand it, drupal_add_js($array,'setting') does not support js functions as values, but if there were some way to pass them in, it would be an aid to editor configuration.

As a temporary workaround until this is fixed (which will take som time) here's a generalisation of the method in #27.

Add this to your template.php file.

Where EDITORNAME must be all lowercase and not contain a version number, just like the .inc files in wysiwyg/editors.
formatN should match the numerical id of the Input format for which the editor is enabled, prefixed by "format". You can have different settings for each one of your input formats. Then you'd have keys like "format1", "format2", and "format5" with different settings even if formats 1,2 and 5 all use TinyMCE.

An option can have values of the types Object, Array, Number, String and Boolean. Functions are not supported due to limitations of drupal_add_js().

If we need to reference a function in for example the editor init parameters, we'd hardcode that function into the editor implementation or some other .js file which is loaded together with it and just give its name as a String in the options above. We'd also have to hardcode the editor implementation to take out that string and replace it with an actual reference to the function.

Perhaps we could make all the editor implementations loop through the settings array and look for Objects/Arrays containing keys like "isFunction" = TRUE and "functionName" = "myFunc", and then replace that that with an actual function reference to the function using settings[settingName] = window.[settings[settingName].functionName] instead?

That would also make it easier to specify a function in an "Advanced editor settings GUI".

TwoD, that would be great. Having the support for functions would really benefit certain editors that take functions in their options arrays/objects.

I'm not 100% clear from your post whether the looping through the settings array would be done server or client side? I would imagine the ideal solution would be server side to give a faster web page, but I don't think it's a big priority.

What really matters is having the support there, and the way you describe would certainly be clear to code with.

It would have to be done on the client, inside the attach or init methods (at least in Wysiwyg 2.x). Inside the browser is the only place the JavaScript functions are actual Objects so they can be referenced, and we can't do

Unless there are a huge amount of settings for an editor, the replacement shouldn't take long to run. It could look something like this:

Yep, I see what you are saying. I think that would be great :-)

Likeless' solution doesn't seem to work quite right for the sort of TinyMCE configuration described at http://wiki.moxiecode.com/index.php/TinyMCE:Configuration/theme_advanced... . This requires setting:

But when I add 'theme_advanced_styles' => "Style 1=style1name;Style 2= style2name", I just get "Style 1=style1name;Style 2= style2name" as one unsplit entry in my TinyMCE styles menu.

While this solution is in progress, is there somewhere we can manually insert our javascript? Using drupal_add_js?

Setting the advanced styles options should work fine since it's a string, but there's already a GUI option for that called 'CSS classes' under the 'CSS' fieldset on the profile page. It's left over since this module supported only TinyMCE but it should still work for it.

You can insert your scripts using template.php just like in the example above, see drupal_add_js for documentation. I think you can also include the scripts in the theme's .info file but I haven't tried that.

Making your scripts interact with the init process of an editor will be hard though, as that is fully controlled by Wysiwyg module.

subscribe

To get rid of the troubles when pasting from other programs once and for all I would like to set "ForcePasteAsPlainText = true ;" for fckeditor. I changed the default setting in fckeditor itself but it simply won't work for drupal. My guess is this setting is somehow being reverted to false (fckeditors normal default). How can I change this?

dagomar, see comment #30 on how to inject a setting like that until there's a GUI for it.
The priority order for FCKeditor settings have the original settings file at the bottom, then comes the custom configurations file (wysiwyg/editors/js/fckeditor.config.js in our case) and at the top are the settings sent directly on the editor instance. We don't explicitly set the 'ForcePasteAsPlainText' option in our files, but doing like comment #30 means you're basically injecting your setting along with the rest of the settings sent from the server at the same 'priority level'. Wysiwyg module loops through all those settings in fckeditor.config.js and actually sets them to the FCKConfig object there, so anything sent from the server overrides the original settings file.