How to use editor in plugins?

[svasti]

Hi Guys,

I somehow managed to put tiny into Calendar following the hints of Christoph and Martin. However the filebrowser doesn't work, no idea why. Tiny is called within the function eventForm, (called in index.php and include'd als includes/eventform.php) so I include'd tinymce/init.php and tinymce/links.php outside the function (in index.php) and I checked that all relevant fuctions are available. Still, no filebrowser. Grrrr

Here is the plugin: http://frankziesing.de/cmsimple/downloa ... _alpha.zip
May be some kindred soul could have a look. (Filesize is big because of some background images, and fckeditor is still part of it)
Tiny is called at the beginning of eventform.php

Code: Select all

    include_tinymce();
    tinymce_filebrowser();
    include_once($pth['folder']['plugins'].'calendar/tinymce/tinymceconfig_for_calendar.php');
    $tinymce = TRUE;

and at the end

Code: Select all

    if ($tinymce) $o .= tinymce_replace("description[$i]",$tiny);

The problem probably is in tinymceconfig_for_calendar.php, where $tiny is defined as configuration.

svasti

[Holger]

Hi Frank,

at the moment I'm busy to publish the first version of the CKeditor plugin. It's 99% finished and will be released together with a compatible KCFinder-plugin this weekend.
So right now I can't have a look on it, sorry.
I guess Christoph is interested in your code too and maybe he can do a quick look on it.
But I want propose that when there will be some more work on calendar, the integration should use the dynamic way
to include the configured editor, not only TinyMCE. I'll help as much as I can, with configuration-files or ready to use code, to see how the new editor-interface is usable.

So calendar can be a good example for other developers and for us to improve the editor-interface.

KR
Holger

[cmb]

Hi Frank,

the problem is the call to tinymce_filebrowser(). This doesn't output something, but it returns the script, that has to be included to $hjs. So basically it's enough to change includes/eventform.php line 28:

Code: Select all

    $hjs .= '<script type="text/javascript">/* <![CDATA[ */'.tinymce_filebrowser().'/* ]]> */</script>'."\n"; 

Christoph

[cmb]

Hi Holger, hi Frank,

But I want propose that when there will be some more work on calendar, the integration should use the dynamic way to include the configured editor, not only TinyMCE. I'll help as much as I can, with configuration-files or ready to use code, to see how the new editor-interface is usable.

+ 1
I've managed to implement this as quick and dirty hack for tinyMCE only:

• remove the call to tinymce_replace() at the end of eventform.php
• after including tinymceconfig_for_calendar.php add:

  Code: Select all

      $hjs .= '<script type="text/javascript">/* <![CDATA[ */CALENDAR_TINY_CONFIG = {'.$tiny.'}/* ]]> */</script>'."\n"; 

• As first line of function openedit(button,hidearea,clicktext,reclicktext,displaytype,antihidearea) add:

  Code: Select all

      new tinymce.Editor("description["+button.substr(6)+"]", CALENDAR_TINY_CONFIG).render();

This will postpone the actual instantiation of tinyMCEs until the + button for the event is clicked. It works (tested on Chrome16), but is a hack, as the tinyMCEs should not be initialized more than once (what will happen, if the user closes the event and opens it again), and perhaps the tinyMCEs should be "removed" on closing the event.

So calendar can be a good example for other developers and for us to improve the editor-interface.

That was a visionary statement While playing around with the dynamic instantiation, I've found a shortcoming of the current specification of editor_replace(). This should return the JS to initialize one editor instance. But this is encapsulated as complete script (<script ...>...</script>). If it would return the actual JS, it could be used in openedit() by calling tinymce_replace(). The advantage: the plugin author must not know, how to actually initialize an editor instance.

So IMO we should consider changing the specification in this regard. If the plugin author needs a complete script, he could easily add the <script> element around it.

Christoph

[svasti]

Hi Christoph,

thanx, it works finally, uff. And it works also with alternative filebrowers ... linke Ajaxfilebrowser, ah.
Only the usual image list is not there. TinyMCE is capricious.

Hi Holger,

at the moment I'm busy to publish the first version of the CKeditor plugin.

looking forward to it.

the integration should use the dynamic way

yes, you are right.

Frank

[Holger]

Just a quick reply:

I wrote above that I not really understand where's the advantage of include_editor();

Is it really not possible to use the ready-to-run function init_editor(); - maybe a extended and more flexible version

I'm worry about how the different editors do their configurations, like filebrowsers, internal-link-extensions etc.
In CK, you only need to set some config-options to run a filebrowser. In Tiny, you have to code your own callback-function...

Holger

[cmb]

Hello Holger,

Is it really not possible to use the ready-to-run function init_editor()

Of course that's possible. Just call

Code: Select all

init_editor(array('class1', 'class2'), 'medium') 

or whatever. 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.

One thing that might be improved, is the possibility to give a path to a config file as $init parameter. But this would be only a convenience to avoid messing around with include_editor(), editor_filebrowser() and editor_replace().

So every plugin developer should consider, if he really needs a special configuration, or if he lets the user decide, which configuration he wants. In the former case, not all editors can be used.

Christoph

[Holger]

Hi Christoph,

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.

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 users.
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.

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.

KR
Holger

[cmb]

Hi Holger,

Perhaps init_editor()'s specification should be slightly extended to allow a full path for $config. This way the plugin could keep the config in it's own folder.

That's a good idea!

Of course init_editor() has to be changed to accept external config-files or arrays.

So I'll add allowing external config-files for $config to the roadmap. But what do you mean with arrays? A JSON config as PHP array?

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 users.

IMO the plugin developer should prefer to call init_editor() with one of the four predefined inits to present the user the accustomed editor. Only if he absolutely needs a special configuration, he should create an own init file and call init_editor() with this file.

And well, editor_replace() -- I just don't know.

Christoph

[Holger]

Hi Christoph,

MO the plugin developer should prefer to call init_editor() with one of the four predefined inits to present the user the accustomed editor.

+1. But CK can't provide the fourth one "sidebar" in a way like Tiny (not yet). Those special configs should come with the plugin . But I'll put a three-button-toolbar to the inits.

Only if he absolutely needs a special configuration, he should create an own init file and call init_editor() with this file.

+1

So only init_editor() should be the preferred way. Fine.
Then let's just stick on config-files and forget about the array (I had an an php-array in mind to hold more things like just the editor-config - but that's oversized, maybe useless and harder to handle).

So I'll code it in CKeditor plugin...

And well, editor_replace() -- I just don't know.

Hehe .


KR
Holger