Add support for custom configuration files

Do you plan the same setting to be available through both ways?

Wouldn't it introduce a possibility that the admin will make some change through the interface, forgetting about the expert configuration, and spend time later wondering why things are not working as expected...?

I mean, now we test and change and replace module files a lot. But, when the new production site will finally be up and running, I have to focus more on content and other things, not so much about Drupal file system on the server... And, in such case it is relatively easy to forget some detail about some module (considering there are many, theoretically each with something particular...).

LUTi, I'm not sure I understand your concern. You want to use the the advanced option, but don't want to be required to remember that you've used it? Are you really afraid that you are going to spend hours turning buttons on an off in the GUI button selector without checking the collapsed "Custom configuration (expert use)" settings?

I'm fairly confident that user who take advantage of the advanced settings are going to know exactly what they did and why.

If you don't feel you can remember that you've configured the advanced settings, I'd suggest you avoid using it.

kreynen, maybe I didn't understand well the idea. I was not afraid of overlooking something being in one place (weather this are settings on admin screen, or settings in some file in drupal filesystem), but being afraid of forgetting that there exist something else somewhere what is not there where I am at the moment adjusting some setting. It seems nedjo understood my concerns, and - yes, nedjo, I like your suggestion.

Maybe to explain better, having the same setting in 2 places could be the a similar problem as having the same program installed in linux through an "rpm system", and at the same time to have it installed in a "traditional" way. So, some files can be duplicated (but in different locations) and definitely you have installed them both by yourself, but after some time you've forgotten that there exist another copy (as we are forgetting many other things...). Correcting some issue in such case later can mean not only to spent quite some time on it, but maybe also to screw many other things which (you believe could anyhow influence to the behavior) during the resolving process.

With many custom modules in Drupal, the issue (or, the root of a problem) is sometimes also not where it seems to be the first moment, or? It happened to me already that I've had to switch off many modules, to find out which one is causing some problem...

In principle, I support nedjo's idea, of course. I am just suggesting to make a system so that administrator is warned that he has to go somewhere else to change something, as the setting he expects to do that will not do the job.

This is exaclty what I had in mind. Let's get the major jQuery one in and then rework this :-)

This patch has created an odd behavior on one of my laptop installs. If I use the "Custom configuration (expert use)", I get two TinyMCEs toolbars for each textbox using it. Turning it off with the "disable rich-text" turns off one of the toolbars. Clicking "enable rich-text" will then turn off the second toolbar. Enable/disable works correctly after that.

The script is loaded twice in the HEAD portion of the page.

<script type="text/javascript">
  tinyMCE.init({
      mode : "exact",
  theme : "advanced",
  elements : "edit-body",
  relative_urls : false,
  plugins : "style,table,media,searchreplace,paste,fullscreen,contextmenu,xhtmlxtras,visualchars",
  theme_advanced_buttons1 : "bold,italic,underline,|,link,unlink,|,justifyleft,justifycenter,justifyright,bullist,|,styleselect,|,image,media,|,fullscreen,|,help",
  theme_advanced_buttons2: "pastetext,pasteword,cleanup,|,indent,outdent,|,search,replace,|,sub,sup,|,cite,abbr,acronym,del,ins,|,charmap,anchor",
  theme_advanced_buttons3 : "tablecontrols",
  theme_advanced_toolbar_location : "top",
  theme_advanced_toolbar_align : "left",
  theme_advanced_path_location : "bottom",
  content_css : "example_full.css",
  plugin_insertdate_dateFormat : "%Y-%m-%d",
  plugin_insertdate_timeFormat : "%H:%M:%S",
  file_browser_callback : "fileBrowserCallBack",
  theme_advanced_resize_horizontal : false,
  theme_advanced_resizing : true,
  nonbreaking_force_tab : true,
  apply_source_formatting : true
  });
</script>
<script type="text/javascript">
  tinyMCE.init({
      mode : "exact",
  theme : "advanced",
  elements : "edit-body",
  relative_urls : false,
  plugins : "style,table,media,searchreplace,paste,fullscreen,contextmenu,xhtmlxtras,visualchars",
  theme_advanced_buttons1 : "bold,italic,underline,|,link,unlink,|,justifyleft,justifycenter,justifyright,bullist,|,styleselect,|,image,media,|,fullscreen,|,help",
  theme_advanced_buttons2: "pastetext,pasteword,cleanup,|,indent,outdent,|,search,replace,|,sub,sup,|,cite,abbr,acronym,del,ins,|,charmap,anchor",
  theme_advanced_buttons3 : "tablecontrols",
  theme_advanced_toolbar_location : "top",
  theme_advanced_toolbar_align : "left",
  theme_advanced_path_location : "bottom",
  content_css : "example_full.css",
  plugin_insertdate_dateFormat : "%Y-%m-%d",
  plugin_insertdate_timeFormat : "%H:%M:%S",
  file_browser_callback : "fileBrowserCallBack",
  theme_advanced_resize_horizontal : false,
  theme_advanced_resizing : true,
  nonbreaking_force_tab : true,
  apply_source_formatting : true
  });
</script>

Any idea what could cause that?

On another site running 5.0, I get a strange issue with enable being on originally even when the TinyMCE's default state is set to true. Clicking enable actually disables the toolbar. Clicking enable again enables it and changes the enable text to disable like it should.

The duplicate toolbar was being caused/called by the Nodeteaser module, but appearing on the main textbox. Nodeteaser is collapsed by default. Disabling Nodeteaser eliminated the problem. Unfortunately, I need that functionality.

I'm not opposed to only implementing custom roles in the JQuery version of TinyMCE, but have the issues with the JQuery patch been addressed?

I don't like the idea of replacing some of the existing configuration GUI with a code box (I you have to code it up what is the point of a module?!).

However if we do have a normal and expert mode then I think this would be a handy addition to the expert mode!

The expert mode has been "added" to the admin interface of the module. You are free to continue using the GUI button picker with all its limitations.

I've installed the latest 5.1-1.x-dev release and can't find the expert mode mentioned, kreynen? Or at least the Advanced fieldset available in previous (4.7) versions.

Nedjo's expert configuration patch hasn't been rolled into the current version. I've been using the expert config and JQuery patches in my projects for a few months, but I wanted to make sure these patches wouldn't make it more difficult to solve some of the other Top TinyMCE Issues before we rolled them out. I've been busy at work and it has been all I could do to answer TinyMCE questions about installs and basic features. I didn't want to introduce a feature that would generate a whole new group of expert config questions until I had time to clean up the TinyMCE documentation and would be able to answer these questions.

Whoops - that's a little funny that the issue tracker let's commenters change the issue title... anyhow my bad.

With this patch custom configuration settings can be supplied by any contrib module. That might affect this patch.

hook_wysiwyg_plugin() is currently limited by tinymce_config() only. tinymce_config() could be altered, so that modules (for example tinymce_expert.module) were able to alter theme_advanced_buttons and other settings that are exclusively controlled by tinymce module currently.

I have a need to modify theme_advanced_buttons because once you get alot of buttons on the toolbars it start to get really confusing. By adding separators and moving buttons around we solve this problem.