Allow configuration of advanced editor settings

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

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

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

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.

drupal_add_js( array(
  "wysiwyg" => array(
    "configs"=> array(
      "wymeditor"=> array(
        "format2"=> array(
          "toolsItems"=> array(
            array('name'=> 'CustomButton', 'title'=> 'Custom Button', 'css'=> 'wym_tools_CustomButton'),
          ),
          "logoHtml" => "",
        )
      )
    )
  )
),'setting');

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.

UPDATE: DON'T use this approach, Wysiwyg 2.1 now has hook_wysiwyg_editor_settings_alter which is much better for this, see #52

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.

drupal_add_js( array(
  "wysiwyg" => array(
    "configs" => array(
      "EDITORNAME" => array(
        "formatN" => array(
          "OPTION_NAME_1" => OPTION_VALUE_1,
          "OPTION_NAME_2" => OPTION_VALUE_2,
          "OPTION_NAME_N" => OPTION_VALUE_n,
        )
      )
    )
  )
),'setting');

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

drupal_add_js("myCustomFileWithMyJavaScriptFunction.js");
drupal_add_js( array(
  "wysiwyg" => array(
    "configs" => array(
      "tinymce" => array(
        "format1" => array(
        "someCallback" => myJavaScriptFunction // myJavaScriptFunction is undefined in PHP. 
        )
      )
    )
  )
),'setting');

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:

// editor JS implementation pseudo code
....
function attach(settings, params) {
 for (var setting in settings) {
   if(settings[setting][isFunction]) {
      settings[setting] = window[settings[setting].functionName]; // References window.myJavaScriptFunction in settings.someCallback;
   }
 }
  theEditor.init(params.field, settings);
}
....

// myCustomFileWithMyJavaScriptFunction.js, a plugin maybe? Must be loaded before the editor is attached or window.myJavaScriptFunction will be undefined.

function myJavaScriptFunction(someArgumentsPassedByTheEditor) {
 alert("Whohoo! My custom callback works!");
}

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:

tinyMCE.init({
	...
	theme_advanced_styles : "Style 1=style1name;Style 2= style2name"
});

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.

Thanks for your reply, I solved it by using the old fckeditor module in the meantime. I really want to use wysiwyg exclusively, but couldnt figure this issue out. I think I'll manage now though.

Coming back to this. I am having serious troubles getting this to work. As a test I wanted to do this:

drupal_add_js( array(
  "wysiwyg" => array(
    "configs" => array(
      "ckeditor" => array(
        "format1" => array(
          "uiColor" => '#FF0000'
        )
      )
    )
  )
),'setting');

But nothing happens whatsoever. What I would love to see is a working example...

edit>>

Ok, I got it to do something at least.
I added 'skin' => 'kama', and something did happen, however now there is no editor and firebug shows:
x.config.skin.split is not a function

I think I will just change stuff in ckeditor.inc, that seems to work.

Oh, I forgot that drupal_add_js() merges values for some reason. Drupal.settings.wysiwyg.configs.ckeditor.format1.skins is a string, but when trying to change it using the method from #30 drupal_add_js simply "adds another value" to it which turns it into an array. The JavaScript doesn't expect an array here, hence the error. Adding just the 'uiColor' option is fine since it's not already in there, but the skin will have to be changed in ckeditor.inc like you say, or overriden on the client using another JavaScript.

@TwoD I tried using the template.php function in #30 to set extended_valid_elements in TinyMCE but no joy. I am trying to disable everything in

tags except for class definitions.

Any ideas?

drupal_add_js( array(
  "wysiwyg" => array(
    "configs" => array(
      "tinymce" => array(
        "format1" => array(
          "extended_valid_elements" => "p[class]"
 
        )
      )
    )
  )
),'setting');

Subscribing

subscribe

Sub.

Can anyone help me add the Templates button to the FCKeditor tool bar using this method? I've tried
drupal_add_js( array(
"wysiwyg" => array(
"configs"=> array(
"fckeditor"=> array(
"format1"=> array(
"ToolbarSets"=> array(
'Templates',
),
)
)
)
)
),'setting');
but it didn't do anything. Any ideas would be appreciated.
Thanks

Try this instead:

drupal_add_js( array(
"wysiwyg" => array(
"configs"=> array(
"fckeditor"=> array(
"format1"=> array(
"buttons"=> array(
0=> array(
'Templates',
),
),
)
)
)
)
),'setting');

, or help test #628110: Allow to alter profile and editor settings and we'll have a much better way to modify the settings using code.

Thanks for the suggestion TwoD, that did work in that the template button shows up now. Unfortunately, it appears to have removed all of the other buttons I had selected through the checklist in the configuration interface. Is there a way to make it add the template button but not wipe out all the others? If not, I guess I can add them all in through javascript if I need to. Thanks again for your help.

When I view source on the page, I do see the other buttons listed in the javascript, they just don't display on the page. Here's what I see: "wysiwyg": { "configs": { "fckeditor": { "format2": { "buttons": [ [ "Templates" ], [ "Bold", "Italic", "Underline", "StrikeThrough", "JustifyLeft", "JustifyCenter",..."

Here's a screen grab to go along with comment #48.

Since #628110: Allow to alter profile and editor settings got in not long ago, I'm going to suggest implementing the new hook_wysiwyg_editor_settings_alter(&$settings, $context) to insert the button instead.
When $context['profile']->editor=='fckeditor' do $settings[''buttons'][0][] = 'Templates';.
EDIT: typo fix

I'm using version 6.x-2.0 on a production site. I just did a search to find the hook_wysiwyg_editor_settings_alter function in the module and it doesn't seem to be there. Would I need to use a dev version in order to do that? Also, I'm a little confused about how to use/call the function. Is there an example showing how to call it and pass 'fckeditor' and 'Templates' to it? I'm sorry that I don't understand this better. I'm more of a front end developer, but I'm trying to learn. Thanks for all your help.

Yes you need to use 2.x-dev (or wait for 2.1). This is getting off topic, but might still be useful for other people wanting to change advanced settings while there is no GUI.
You can create your own module (let's assume it's named 'custom') and implement the hook like this in custom.module (with reservations for errors due to untested code, this is all which should need to be in the module):

EDIT: $context is not meant to be passed by reference.

function custom_wysiwyg_editor_settings_alter(&$settings, $context) {
  if($context['profile']->editor == 'fckeditor') {
    // All buttons are currently in a single group, so let's append the new button to it as well.
    $settings['buttons'][0][] = 'Templates';
  }
}

What's in the $settings argument depends on what was added by the 'settings callback' in editor/editorname.inc. $context will have the keys 'editor', 'profile' and 'theme', their exact contents will also depend on what is returned by the callbacks in the editor .inc files.

Fixing awkward title wording.

Thanks so much. I'll give it a try.

trying to configure markitdown with a wiki syntax I came here

subscribing

#52 works with DEV version 6.x-2.x-dev (2010-Mar-12)

I could implemented this :

function MYMODULE_wysiwyg_editor_settings_alter(&$settings, &$context) {
  if($context['profile']->editor == 'tinymce') {
    $settings['forced_root_block'] = 'false';
    $settings['force_br_newlines'] = 'true';
    $settings['force_p_newlines'] = 'false';
  }
}

This method resolves this : #553516: Disabling TinyMCE's default 'force paragraphs'

Thank you

hook_wysiwyg_editor_settings_alter can be used with the Wysiwyg 2.1 release as well, no need for -dev.

Thank you TwoD very nice.

I used this to force cleanup of Word in ckeditor:

function MYMODULENAME_wysiwyg_editor_settings_alter(&$settings, &$context) {
  if($context['profile']->editor == 'ckeditor') {
    $settings['pasteFromWordRemoveFontStyles'] = 'true';
    $settings['pasteFromWordRemoveStyles'] = 'true';
    $settings['forcePasteAsPlainText'] = 'true';
    $settings['pasteFromWordPromptCleanup'] = 'false';
  }
}

Hi TwoD nice work,

While I have to try config the "protectedSource" to keep the ckeditor not toughting the source code for syntax highlighting. But I can't get the hook to work. Here is my code.

<?php
  //
  function ckeditor_custom_wysiwyg_editor_settings_alter(&$settings, &$context) {
    if ($context['profile']->editor == 'ckeditor') {
      $settings['pasteFromWordRemoveFontStyles'] = 'true';
      $settings['pasteFromWordRemoveStyles'] = 'true';
      $settings['forcePasteAsPlainText'] = 'false';
      $settings['pasteFromWordPromptCleanup'] = 'false';

/*      $settings['protectedSource'][] = '/<\?[\s\S]*?\?>/g'; // PHP Code
      $settings['protectedSource'][] = '/<%[\s\S]*?%>/g';   // ASP Code
      $settings['protectedSource'][] = '/(]+>[\s|\S]*?<\/asp:[^\>]+>)|(]+\/>)/gi'; // ASP.Net Code
      $settings['protectedSource'][] = '/<code[\s\S]*?<\/code>/g';                 // GeshiFilter
 */     $settings['protectedSource'] = '/\[code.*?\[\/code\]/g';              // GeshiFilter [code][/code]
  /*    $settings['protectedSource'][] = '/<blockcode[\s\S]*?<\/blockcode>/g';       // GeshiFilter <blockcode></blockcode>
      $settings['protectedSource'][] = '/\[blockcode[\s\S]*?\[\/blockcode\]/g';    // GeshiFilter [blockcode][/blockcode]
      $settings['protectedSource'][] = '<pre\ .*?<\/pre>/g';                       // wysiwyg-geshi
*/
      $settings['justifyClasses'] = array('rteleft', 'rtecenter');
      $settings['uiColor'] = '#9AB8F3';
//      dsm($settings);
    }
  }
?>

I have tried the $settings['protectedSource'][] and $settings['protectedSource'] = '/\[code.*?\[\/code\]/g', both not work on my side, and I also found that others seems get the $settings['justifyClasses'] = array('rteleft', 'rtecenter'); to work, but on my server, the ckeditor still shows 4 options on the toolbar, so the $settings['justifyClasses'] not work too?

And $settings['uiColor'] = '#9AB8F3'; it does work, I may change the toolbar's color without problem.

So could you help me with the protectedSource config from my custom module?

Thanks.

Please don't hijack the issue. ;)

Note that to make the final JavaScript settings have the right type, you must use the corresponding PHP types. So in the code above, 'true' and 'false' should be TRUE and FALSE.
According to http://docs.cksource.com/ckeditor_api/symbols/CKEDITOR.config.html#.prot... the protectedSource settings must be passed an array of RegExp objects. I'm afraid drupal_add_js() (which the settings object is passed via) is not able to convert a PHP regular expression to the JavaScript equivalent, and CKEditor doesn't accept them being passed as strings.

Translating regular expressions between PHP and JS would be quite complex, but maybe we can get around that by using a method similar to what I described in #32. That is, we define the RegExp as a string similar to how you have it now, but in such a way that Wysiwyg knows it should be transformed to a real RegExp object before being passed to the editor.

That's a rather special case though, and we need to get this issue back on track.
Sorry I can't help you more, wqmeng, but we're currently limited to using the types easily converted from PHP to JS. (Bool, Number [int/float], String, Array, Object).

Hi twoD
Sorry, I don't know that my select may change all the issue's setting.
Thank you for the clarification, yep the drupal_to_js makes the trouble to transfom a php RegExp string to js. Then I have checked the #32 solution for it, And I created a js file, wrote a callback function, added the js to the edit page from drupal_add_js, also add a custom setting in format1 array to refer the function. All seems just done as you said in #32. But the callback function never been called.
So In #32 you said that the editor should init the settings and when a setting is function, the editor invoke it, So my function been called, And I have a chance to set the RegExp to the config, Right?
And actully my function never been called, so I should tell the editor that my setting is a plugin or anything else that the editor should invoke it? Then if so How to get it?

Thanks for your time.
Best regards.

So In #32 you said that the editor should init the settings and when a setting is function, the editor invoke it...

No. If the value of a setting is identified as a 'serialized function reference', Wysiwyg should only replace that 'value' with an actual reference to the function in question. The function would only be called by the editor when it alone decides to do so (when depends on what setting it is and how the editor uses it).
A custom setting with a 'serialized function reference' as value would never be called because the editor wouldn't know what to do with it, just as it wouldn't know what to do with any other custom setting ('custom' as in not used by the editor itself or one of its plugins).
Wysiwyg couldn't call your custom function either because it doesn't really know which settings the editor expects, or when to call it and with what parameters.

The explanation of this method actually begins at #30, my bad.

In the case of RegExps, we'd do something similar to #30/#32, but instead of a function name in the 'wrapper object', we have a regular expression as a string (and one more string with additional options like 'i' or 'g'), which is passed through decodedRegExpValue = new RegExp(regExpValueAsString, regExpAdditionalOptions).

Note, the drupal_add_js() calls in #32 were only used in the example because we didn't have hook_wysiwyg_editor_settings_alter() yet.

This is getting a bit off track (again hehe). We should refocus on trying to figure out the basic requirements/coding steps needed to allow our editor implementations and '3rd party' plugin hook implementations to extend the profile administration GUI.
Some points have been raised earlier here, and recently more in #277954: Allow to sort editor buttons.

An alternative in javascript which should works for all configuration types:

Drupal.behaviors.customWysiwyg = function (context) {
  if (typeof Drupal.settings.wysiwyg == 'undefined') {
    return;
  }
  var editor = Drupal.settings.wysiwyg.configs.tinymce;
  for (var format in editor) if (format != 'global') {
    editor[format].OPTION1 = VALUE;
    editor[format].OPTION2 = function(){};
  }
};

@twoD
I got the point, then wysiwyg not implement to transform the regexp string from php to js for now. So If I would like to do this, I need to hack the wysiwyg module and js to keep the regexp work when it runs from the browser side.

As drupal_add_js can only transfer simple type, to let it know what's we transfering is regexp, we need additional field append to the value with type and attributes as an array even it's a float type? And from the js side, we need to rollback the regexp to the raw one from the module's setting and set it to ckeditor.

Seems we need talk more with it before the action.

Thanks a lot.

Now I have get the regexp setting to work with append them to a plugin of ckeditor, the plugin was loaded by wysiwyg which you may download it here. http://drupal.org/project/wysiwyg-geshi
It seems that the plugin always loaded after the wysiwyg code to set the cofig, so you may change a setting without removing by wysiwyg.

@draebb

Thanks, maybe it's annother solution for it, just I am not sure when the behaviors been called if it is after the wysiwyg's js.

Hello,

I use wysiwyg module 2.1 and tinymce

I want to know how I can do the modication posted on comment #52

What are the files I need to modify

Thanks for your responses

Best regards

Re #67, You don't need to modify any of Wysiwyg's files. You need to create a very simple module containing a hook implementation similar to the one in #52. See http://drupal.org/node/231276 for module howtos.

ThanKs for your response TwoD,

The big problem is that I never write a module for drupal.
I have modify some modules for my own need, just only.

I try to do...

Hi, interesting with the option of altering editor settings in a hook.
I am using tinymce and looking for a way to remove empty paragraphs after pasting, which I think by default is inserted by tinymce with the '#p' setting (pad empty elements) in the 'valid_elements' option: http://wiki.moxiecode.com/index.php/TinyMCE:Configuration/valid_elements

Any suggestions as to how to change that setting in the hook?

Another possibility I was looking at is to add a callback funcion to the [paste_postprocess] option of the paste plugin. Would it be possible with the hook to add a function like the one described here: http://blog.o-x-t.com/2010/03/06/extra-spacing-in-tinymce-after-pasting-...

Thanks.

Questions about specific options should really go in their own support requests as this issue is already too bloated.

I'm feeling nice tonight though so I'll answer it anyway. ;)
The basics are the same as in the code from #52 but we need to consider that the value is a comma separated string and that it may already have values.

function custom_wysiwyg_editor_settings_alter(&$settings, $context) {
  if($context['profile']->editor == 'tinymce') {
    // Original definition is '#p' in valid_elements. extended_valid_elements overrides valid_elements;
    // Note: Will cause problems if extended_valid_elements already contains a definition of p.
    $elems = explode(',', $settings['extended_valid_elements']);
    $elems[] = 'p';
    $settings['extended_valid_elements'] = implode(',', $elems);
  }
}

See #30 for why we can't add function JavaScript function references via PHP. #63 could be used as a workaround for that, but then you must be sure that behavior runs before Wysiwyg's, which you often can't. Altering your module's weight might help.

Thanks for being nice. I tried the code you suggested (adding a comma between the parameters to implode), and have done some testing with drupal_set_message. I manage to get 'p' added to $settings['extended_valid_elements'], but it has no effect. I guess 'p' will only override 'p' and not '#p'. If this is the case, would there be any way to supply 'valid_elements' as a key in the $settings array of the hook in order to remove it directly from there?

Whoops, thanks. Fixed the comma typo.

Hmm, according to the TinyMCE wiki, that override should have worked, not sure why it didn't.

Wyswyg module doesn't set the 'valid_elements' key because its default value usually works for us, but you can override that as well simply by removing the 'extended_' part above and adding all the element definitions you need. The $settings array is passed to the editor instance almost as-is when it's created - some Wysiwyg-specific keys are just removed first.

Hi again, sorry if this getting a bit off topic...

Yes, I think you are right, it should work. As an alternative approach, I even tried hard-coding the value into tiny_mce.js, but with no apparent effect.

So it's probably because I haven't understood very well how Tinymce uses those settings: p, -p and #p. What I want is to prevent Tinymce from inserting "<p>&nbsp;</p>" when there is an empty line. It seems to be unavoidable...

Perhaps I could get rid of them writing a custom filter.

Subscribing...

Do the wymeditor function settings work yet? I've read through the whole thread but I still don't understand how difficult it would be to make it work so that we have a 100% function wymeditor. You can reply in this issue:#682940: WYMeditor: Add support for native plugins .

My understanding is that hook_wysiwyg_editor_settings_alter() wouldn't be of any help here for custom wymeditor plugins, am I right?

What is left to do as far as this issue is concerned?

Please don't hijack this issue, it's already unfocused enough. This issue will be about creating a set of hooks, or similar, to be used by the editor and plugin implementations so they can extend the Profiles configuration with new form elements. Each editor implementation will than have to be given implementations of these hooks so when you're configuring the editor, you'll have GUI options for as many of the editor-specific settings as possible.

I'll reply to #682940: WYMeditor: Add support for native plugins when I get back from work.

Regarding MarkItUp: The Sets are really pre-populated JavaScript objects in the structure MarkitUp accepts its settings. Wysiwyg currently passes in its own settings object created from the settings you do in the editor profile. To be able to switch between Sets, our implementation would need to be able to change the profile GUI to remove/disable the Buttons/plugins controls when a predefined Set has been selected as well as detect, include and use the files on its own. That may be possible after this issue has been resolved, or at least it'll bring us a huge step closer. Even if you use drupal_add_js() somewhere now to include the Set file, MarkItUp would ignore it because Wysiwyg wouldn't know it's there, and MarkItUp doesn't have a parameter you can set to tell it "use this set instead", it's all or nothing.

However, using an implementation of hook_wysiwyg_editor_settings_alter(), you can pass a "translated" Set file to MarkitUp via PHP and override what Wysiwyg sends to it. If you can recreate a Set object using only PHP arrays, objects, strings, booleans and numbers (functions and regular expressions can not be automatically translated to JavaScript), you can do $settings = $my_php_markitup_set in the hook and Wysiwyg will give those settings to MarkItUp instead, as a JavaScript object.

In light of webchick's comments (#10 re MarkItUp with BBCode), I am wondering what is required for BBCode support to be added?

What level of sponsorship would be required to get this implemented (including D6)?

Giving this a bump. Someone have the time to add BBCode support to WYSIWYG — I can sponsor this (6.x +).

BBCode support would mean a plugin for each editor, if they don't already include one on their own. As far as I can remeber, at least TinyMCE has such a plugin bundled with the editor itself and you can activate it under "Buttons and Plugins". Just beware that you need a BBCode input filter - like the one provided by BBCode module - in order to make Drupal translate the stored BBCode to HTML during rendering.

At this time, we won't bundle such plugins (or metadata wrappers for them) with the module itself as we have enough on our hands with the core module. There's been recent talk about a possible wysiwyg_contrib module which could be a good place to collect various things like that. (Small modules implementing hook_wysiwyg_plugin() and/or hook_wysiwyg_editor_settings_alter() and maybe providing specialized GUIs for additional features.)
That is not to say we won't do all we can to get a good framework for handling plugins and settings available in the standard editor packages, we just haven't had the time to deal with these larger issues yet. They are absolutely a blocker for any Wysiwyg 3.x release though.

subscribing

subscribe

subscribe

Coming from #544032: Add iframes via TinyMCE...

Vimeo has switched to using an iframe to embed videos, and I'm sure a few other places use iframes as well. The ability to set advanced tinymce settings (among others) should be in wysiwyg's core plugin settings, as it's a major head-scratcher when you paste in the code then it disappears... :)

Subscribing

@ Lars Kramer

What I want is to prevent Tinymce from inserting <p>&nbsp;</p> when there is an empty line. It seems to be unavoidable...

Did you ever find a fix for this?

I tried

      $settings['forced_root_block'] = FALSE; 
      $settings['force_br_newlines'] = TRUE;
      $settings['force_p_newlines'] = FALSE;

inside the settings alter hook, but that doesn't seem to change things.

subscribe

subscribe

I have problem copy and paste editor in tinyMCE. I can view but when i sa
ve the image it turn-out into txt.

@jazclick, please don't hijack feature request issues with support requests, create a new one instead. Check your format settings in Drupal so they don't filter out the image tags.

I tried implementing the code from #56 with no success, then I realized that php doesn't see those values in the quotes as boolean, so it was just getting set to a string value. I removed the quotes and emptied the forced_root_block value to get it to add br's when I hit return.

function MODULENAME_wysiwyg_editor_settings_alter(&$settings, &$context) {
  if($context['profile']->editor == 'tinymce') {
    $settings['forced_root_block'] = '';
    $settings['force_br_newlines'] = true;
    $settings['force_p_newlines'] = false;
  }
}

Thanks for the code, super helpful!!

@weekev: this was mentioned in #60

you should use uppercase TRUE and FALSE though, as this is the way php wants it :)

Subscribing.

Just a code to restrict font colors used in TinyMCE:

<?php
function MYMODULE_wysiwyg_editor_settings_alter(&$settings, $context) {
  if($context['profile']->editor == 'tinymce') {
    $settings['theme_advanced_text_colors'] = 'EB732B,73735C,2D3437,62B5Cf,BCBD0D,FABB00,102655,000000,FFFFFF';
  }
}

And a warning:

if you use "&" before context like: "&$context" it will give an error, for example as the code in #92...

TinyMCE stuff disappearing not panicking.... Subscribe.

Cant' get the module code to work, does nothing to my tinyMCE install at all: Using WYSIWYG and TinyMCE 3.2.7 in libraries.

Is this correct:

name = "Lightflows Fix"
description = "Fixes BR and P in tinyMCE WYSIWYG"; 
core = "6.x"

function lightflowsfix_wysiwyg_editor_settings_alter(&$settings, &$context){

  if ($context['profile']->editor == 'tinymce') 
  {
    $settings['forced_root_block'] = '';
    $settings['force_br_newlines'] = TRUE;
    $settings['force_p_newlines'] = FALSE;
  }
 }

Would love to get rid of those <p>'s

update: I've added some watchdog statements inside the if - so this code is being executed but doesn't affect the wysiwyg settings at all.

@hixster: what exactly are you trying to do?
"This option enables you to disable/enable the creation of paragraphs on return/enter in Mozilla/Firefox."
http://tinymce.moxiecode.com/wiki.php/Configuration:force_p_newlines

place a drupal_set_message('something'); in your code to see if your module works.

Hi RV0,

I'm trying to disable <p> tags getting added for newlines and replacing them with <br/> instead. (we're trying to get the shortcodes module to play nicely with tinyMCE)
Also I don't want a <p> tag wrapping the whole content which is what i thought this setting did:

    $settings['forced_root_block'] = FALSE;

I'd just updated the post above to say that i've added a watchdog message to the logs from inside the if statement - so the code is being executed.
I'm using wysiwyg6.x-2.4

<?php 

function lightflows_fix_wysiwyg_editor_settings_alter($settings, $context){
  if ($context['profile']->editor == 'tinymce') 
  {
  	dpm('in the wysiwyg IF');
  	watchdog('Lightflows_fix','setting the settings');
    $settings['forced_root_block'] = FALSE;
    $settings['force_br_newlines'] = TRUE;
    $settings['force_p_newlines'] = FALSE;
  }
  
}

@hixter

i dont think those settings will do it

if you are talking about <p>&nbsp;</p> tags being added, have a look at http://drupal.org/project/emptyparagraphkiller and change the code to insert br instead of removing them.
if not, well, just ignore my reply ;)

FYI: We've just added #1650416: Allow editor specific changes to be made to the profile settings form

Not in the 6.x-2.4+19-dev release, did you?

rv0 i also thought about that approach but adding some regex input filter to solve something that the api of the editor provides is an ugly way. i am trying something like this with ckeditor myself and try to use the api.