The attached patch fixes a couple things that in my opinion would make this module more usable.
Frist off, I cleaned the Javascript code added to the textarea. The same code is repeated for every textarea, the only thing that differs is the object. I rewrote that code as a common JS function fck_textarea_replace(oFCK), that is addded only once to the page. For each textarea having fckeditor there's jsut a call to that function, passing the appropriate object. This makes the code clean and lightweight.

I also didn't find much comfortable the exclusion settings with the path/field toggle. I think that 95% textareas in the site don't need to be wysiwyg, so I guess it's better to talk in terms of "visibility" settings, rather than "exclusion" settings. In my case I wanted to have fckeditor enabled only for the node add/edit body. If you enter the node/add path, you get ALL textareas in that page to be fckeditor, and this is not what I want. If you enter the edit-body ID, you get ALL the edit-body textareas in the site to be fckeditor, and this is not what I want (edit-body is the new block body, the message body from feedback module, etc...). The best solution in my opinion is a list of path/ID couples the we want to be fckeditor, so a visibility list. The patch allows admins to enter paths and IDs, separated by a | (* as wildcard). For example:

  • node/add/*|edit-body: allow fckeditor for body in node add page
  • node/*/edit|edit-body: allow fckeditor for body in node edit page
  • feedback|*: allow fckeditor for all textareas in the /feedback page

The minimun rows condition is still verified, and I also added a test on the #wysiwyg parameter, to make coders disable wysiwyg editors by default for a specific textarea.

The attached patch is against version 1.19.2.3 in the Drupal 5 branch.

CommentFileSizeAuthor
fckeditor.module_3.patch16.51 KBstefano73

Comments

ontwerpwerk’s picture

ontwerpwerk commented

Using one function is probably not neccesary, and interferes with the idea of customizable toolbars that's also coming up. And even if its functional - the amount of code that is loaded by the fckeditor dwarfs the amount of code that is saved by placing everyting in one function, I wouldn't bother.

As for the change of exclusion into visibility, what's in a name - but I kind of like the idea and will probably incorporate it.

The idea of path|field-id is also a good one, but I wonder if by then the increased complexity could be handled by a better interface. If you know the form ID you would not need the path in most cases anyway. Unless the same ID is used in multiple different pages, but in that case chances are that the same ID also means that the same kind of input is used - and the same rich text editor setting is needed.

t4him’s picture

t4him commented

Though this is not DIRECTLY related to your issue it does have to do with cleaning up FCKEditor code. I don't know how or where to do this OR who to ask but this is something I have notice.

If you Create a link to a popup window (to view an image) and save it. When you hover your mouse over the hot linked image, all of the javascript code is displayed in the bottom of the browser. How/where can this be removed? suppressed?

Thanks,
t4him

ontwerpwerk’s picture

ontwerpwerk commented

th4im: that would be a separate issue for the mainainers of the fckeditor component at http://www.fckeditor.net

ontwerpwerk’s picture

ontwerpwerk commented
Status: Active » Closed (won't fix)

I changed some wording according to your idea for the current 5x dev

I'm not bothering with rewriting the funtions to be only called once - ususally you only want 2 or less rich text areas per page anyway

the #wysiwyg test is not implemented (yet)