It would be awesome if fckeditor.config.js could be loaded from path_to_theme() should it exit, similar to fckeditor.xml

Just throwing it out there ATM for comments.

Files: 
CommentFileSizeAuthor
#11 fckeditor,6.x-1.3.module.patch1.88 KBtavin.cole

Comments

Hi,

I'd just like to add my support to this feature request. It would be very useful for multi-site setups where different toolbars are required for each site. I realise that it should be possible to modify the config.js through the module admin pages, but I've never yet managed to add a whole new toolbar without making a syntax error and causing the whole thing to break. Also, an external config file makes it easier to track changes in a version control system.

So far, I've been hacking the module to check for a fckeditor.config.js file in the theme folder, and fall back to the default one if none is found, but it makes upgrading the module a pain. If I wasn't so useless with CVS, I'd roll a patch, but here are my changes to the D5 (5.x-2.2-rc7) module, if that helps:

Added new function:

function fckeditor_get_custom_config_path() {
  // Check for site-specific fckeditor.config.js file in current theme folder - handy for multi-site setups
  $theme_config_path = path_to_theme();
  $theme_config_file = $theme_config_path .'/fckeditor.config.js';
  if(file_exists($theme_config_file)) { // if there is a site-specific copy of config file, use that
    $fckeditor_config_path = base_path() . $theme_config_path;
  } else { // use default fckeditor.config.js
    $fckeditor_config_path = drupal_get_path('module', 'fckeditor');
  }
  return $fckeditor_config_path;
}

... and then modified the following lines:
960:
". $js_id .".Config['CustomConfigurationsPath'] = "". fckeditor_get_custom_config_path() ."/fckeditor.config.js?". @filemtime(fckeditor_get_custom_config_path() ."/fckeditor.config.js") ."";
1290:
$fckeditor_config_js = fckeditor_get_custom_config_path() .'/fckeditor.config.js';

(I guess I should store the path in a variable, rather than calling the function twice in line 960)

(And I guess I should just return the appropriate value from withtin the if/else condition ... but they don't call them hacks for nothing!)

Status:Active» Fixed

Fixed in CVS. Should be available as a dev release tomorrow.

Hi,

Thanks for including that change. I've just installed the dev version (5.x-2.x-dev from 2009-Mar-12) and it seems to be working fine.

One note though... First, I found the option to use the theme/fckeditor.config.js and set it (and saved the profile). Then I went back to edit the profile again. Under the 'Editor appearance' tab, the 'toolbar' select is showing options from the default (module) fckeditor.config.js so that, for example, I can choose the DrupalFiltered toolbar, even though it's not defined in the custom theme fckeditor.config.js, which then throws an error on the node/edit page. Obviously that's down to user (me!) error, in not making sure that the toolbar was defined, but I just wonder whether the toolbars loaded from the theme fckeditor.config.js should be marked as such (maybe in parentheses after the name?) to warn users. Or, could the admin page only load the custom file, or is the default fckeditor.config.js file required in case elements are missing from the custom one? Just a thought - it's kind of a detail - and otherwise works great.

Version:6.x-2.x-dev» 6.x-1.3
Status:Fixed» Needs work

I'm sorry, but this doesn't work for me. I have my own toolbar settings and I'm using rootcandy as administration theme, as well as my own theme for visitors.
I activated the option and copied the fckeditor.config.js into both theme files, but the toolbar didn't appear in fckeditors toolbar list.

Same by me - fckeditor.config.js is not loaded. It depends not on the language I think, because ist doesnt work in german and english.

It is working for me, I'm just using the one theme though.

Not working for me aswell

I've my own toolbar, but I can't see it under the 'Editor appearance' tab.

Any solutions

Thanks

It doesn't work for me either, using 6.x-2.0-beta1.

I tried to remove the fckeditor.config.js from the module path, but then all the Drupal toolbars disappeared. To me it seems like fckeditor.config.js doesn't load at all from the theme path.

Edit: I was sort of wrong, fckeditor.config.js does load from the theme path, because if I add the same toolbar in both of the fckeditor.config.js files, then it is the one from the theme path that is read. So it seems like the file in the module path decides the list of the toolbars, but the content of the toolbars is decided by the file in the theme path. Weird, right?

I haven't checked it yet, but from what I remember, it now does work this way:
- when editing FCKeditor profile in admin/settings/fckeditor, load available toolbars from fckeditor.config.js located in sites/all/modules
- in all other cases where FCKeditor is used to edit content, fckeditor.config.js is loaded from theme path (if enabled)
Also see comment #3 above to see what I mean.

For now, please define toolbars defined in theme_path/fckeditor.config.js also in global fckeditor.config.js to be able to select them in FCKeditor profile.

Anyway, it is something that needs to be improved.

Marked the older #300000: Protect fckeditor.config.js from being overwritten by mistake as a duplicate of this issue.

StatusFileSize
new1.88 KB

this patch works for me.. the method is to simply iterate through all possible fckeditor.config.js files in all themes as well as the one included with the module.

of course, this could lead to a toolbar choice that isn't available from the active fckeditor.config.js at editing time. it seems like the only alternative would be to make the admin choose a toolbar for every theme that might be active at editing time, which sounds overcomplicated.

Title:load fckeditor.config.js from theme pathfckeditor.config.js in theme path not recognized in admin

I changed the title to reflect the real issue. If you disagree, please reply.

Status:Needs work» Active

IMO allowing overrides in the theme directory is the right idea but the wrong solution. It's definitely right that we should not have to touch the global module files to declare our own custom toolbar configs, but the theme is the wrong place to do it.

FCKeditor configurations should be site specific and theme agnostic. In other words, all of these FCKeditor configuration overrides should live in the top level of the site folder beside settings.php. (In fact, it wouldn't be such a bad idea to actually declare these settings directly within the settings.php $conf array.)

- sites/
- - (all OR default OR sitename)/
- - - fckstyles.xml
- - - fcktemplates.xml
- - - fckeditor.config.js

This way you can still have unique configurations on a per-site basis while preserving theme flexibility.

Furthermore, the FCKeditor library itself should be removed from the module directory. We should follow the
practice used by the wysiwig module and use sites/all/libraries/ instead.

sites/
- - all/
- - - libraries/
- - - - fckeditor

These changes would make FCKeditor less confusing, more portable, and far easier to keep up to date.

Hi,

I like the idea of moving the FCKeditor library to sites/all/libraries, as it makes sense, and might make installation a bit simpler (there are a lot of forum posts asking about whether it should go in sites/all/modules/fckeditor/fckeditor/ or wherever).

I'm not sure I agree about moving the fckeditor.config.js file though. Although the config is, as you say, probably site-specific rather than theme-specific, other files - fckstyles.xml and fck_editorarea.css - are more related to the theme, and splitting things up into different locations might confuse things (even if it makes more sense from the point of view of logical organisation).

Status:Active» Closed (won't fix)

The separation of the FCkeditor sources has been registered as a feature request in #541070: Support Libraries API.

Supporting a per-site fckeditor.config.js is registered in #541072: Allow per-site fckeditor.config.js.

The issues will not be addressed in 6.x-1.x or 6.x-2.x, because they are too far in development. If there ever will be a 3.x, it will be considered for that version.