Hi folks,
the last weeks I had to upgrade some old SE-Installations to 1.5.
At the end the biggest problem was the new editor (I've posted my problems elsewhere).
So I made a really quick & dirty solution for the old FCKeditor in XH 1.5 and all my problems are gone (for now).
I've talked about that with Christoph and we've discussed if it would be a good idea to provide that code.
So upon this discussion I had now a closer look again:
IMO it's not a problem to integrate / connect a filebrowser to (F)CKeditor with the todays codebase.
But I stumbled about this:
cmb wrote:Well, even that could be done without too much additional work. You might have a look at plugins/tinymce/init.js tinyMCE_instantiateByClasses(). That's basically what does the trick. And it even works, if the textareas have no IDs at all -- they're given a unique ID dynamically!
AFAIK that's not possible by default with CK / FCKeditor and we have to code something like tinyMCE_instantiateByClasses() for CKeditor.
But I really not see an advantage to initialize the editor by classes (and I'm happy that the default id "text" is still in the core
).
@svasti:
svasti wrote:and calling the textareas by ID is kind of unpractical in my case, so I'd rather avoid that
Why? You need in both cases a <textarea> and, if you need more than one editor at the page, unique selectors.
IMO you'll end up in a code like the core:
Code: Select all
'<textarea name="some_name" class="some_class ....">' . htmlspecialchars($some_content). '</textarea>';
or
Code: Select all
'<textarea name="some_name" id="some_id" ....">' . htmlspecialchars($some_content). '</textarea>';
(the core uses both, ID and CLASS, in the textarea)
So could someone explain me the advantage of using classes instead id's?
I would prefer (or in other words, I see no other way for CK
) this way:
Code: Select all
function init_editor($ids = array(), $config = false)
$config can always be provided as a .js-file by the plugin IMO. So if a plugin has to use special configs, like calendar, it only has to check if there is one existing for the configured editor.
But it's no problem to use IDs for CK and classes for Tiny
as long as every plugin uses the same code for the textarea like the core (ID
and CLASS!):
Code: Select all
'<textarea id="some_id" name="some_name" class="some_class ....">' . htmlspecialchars($some_content). '</textarea>';
To include a (default-configured) editor to a plugin is then just copy & paste the code from adm.php and rename the name, class, id and $content variable.
At the end a question to Christoph / Martin:
what's the secret behind function editor_replace($elementID = false, $config = '')?
I can't understand in which case this function is usefull.
IMO we only need include_editor() as a separate function and init_editor(...).
KR
Holger