cmb wrote:Of course that's possible. Just call
Of course, I know how that's working
But back to the special configuration of calendar:
At the moment he must mess around with three functions. That's IMO a bit bad and not easy to do for everyone.
Ok, let's say he only want to enable TinyMCE. Why isn't he (in future) using
- Code: Select all
init_tinymce(array('class1', 'class2'), $calendarConfig)
As far as I understand, I had no look on the code yet, he has to create special configurations together with the other functions anyway.
But IMO there is no need to mess around with include_editor(), editor_filebrowser() and editor_replace() - if there is a ready to run editor.
He could create a config.js file for TinyMCE and handle it like init.php ( file_get_contents() + str_replace() ) -> really simple!
IMO that's possible with the todays interface in most or all cases, at least with CKeditor it is / should.Of course init_editor() has to be changed to accept external config-files or arrays.
And if he then switch to include_editor() he can enable every other (compatible) editor, if a config for this editor is available.
If there is no config for the active editor, he can switch back to TinyMCE.
cmb wrote:But this would be only a convenience to avoid messing around with include_editor(), editor_filebrowser() and editor_replace()
IMO that's not a small issue. The plugin-author has to write the complete functionality of the whole init_editor function, which is IMO not easy to do for a developer who never before made that. And he must do all that work again and again for every editor he want's to enable. Even if there is a working available.
And what about the filebrowsers? At the moment there are three??? Think about the possible combinations! But the active editor of the user should always have a working filebrowser adapted.
So if we not change init_editor() to get it more flexible, the plugins will only use default or the author - preferred editors / filebrowsers...
We've managed to find a way to flexible combine the editors with filebrowsers.
So I think it would be possible to change the init-function to accept external configurations.
At the end maybe the editor-developer can help or can create configs for often used plugins to give them to the plugin-author. I'll do that for CK as good as I can.
And for sure for other editors will be a way too.
But when plugins only use hardcoded editor-names, it was a waste of time to change the editor-interface at all.
The old one worked well too. Just moving the files to /plugins had been enough...
From my POV function init_editor() should be the only function used by plugins. That would be - in my opinion - the best and easiest solution for developers and
So if I today start to use calender, I must mess around with two different editors. It's an option, but no good one
. And I hope that another good plugin not comes with the next editor.
cmb wrote:But if any plugin author needs a special configuration, this is not compatible to any other editor. Consider Textarea_XH: no config options possible (they're simply ignored). Or Codeeditor_XH: currently all the config is done via the back-end, so the $init parameter is ignored. Or Whizzywig: it doesn't allow any configuration besides the toolbar individually for different instances.
Those editors are then not compatible. Where's the problem? The plugin does not provide a config for those ones.
In this case the user must install a compatible editor.