How to use editor in plugins?

[Martin]

Hi Christoph,

IMO there should be possibility to delay the instantiation of the editors ("instantiation-on-demand"). This might be done most easily with editor_replace().

Maybe you are right. Even if the function is not necessary anymore to have different editors, keeping some javascript from the html-header might be reason enough to keep it. In the long run we should think about establishing a "$fjs" - footer javascript. Faster buildt pages and no more "onloads" and "document.readys"!

The config string gives the plugin author the chance to do without an init file (or to use a basic init file and add some options dynamically, without writing those back to another file). I would prefer that.

Me too. That was, what I was trying to say ... Hmm, English!

Martib

[Holger]

Hi Martin & Christoph,

so what would we do now? Someone must make an decision

Holger

[cmb]

Hi Martin, hi Holger,

so what would we do now? Someone must make an decision

We just have to decide or toss a coin.

<EDIT>
Well, I guess we can do better than tossing a coin. So here's my suggestion:

Code: Select all

/**
 * Writes the basic JS of the editor to $hjs. No editors are actually created.
 * Multiple calls are allowed; all but the first should be ignored.
 * This is called from init_EDITOR() automatically, but not from EDITOR_replace().
 *
 * @global string $hjs
 * @return void
 */
function include_EDITOR()


/**
 * Returns the JS to actually instantiate a single editor on the textarea given by $element_id.
 * $config can be 'full', 'medium', 'minimal', 'sidebar' or '' (which will use the users default configuration).
 * Other values are editor dependent. Typically this will be a string in JSON format enclosed in { },
 * that can contain %PLACEHOLDER%s, that will be substituted.
 *
 * To actually create the editor, the caller has to write the the return value to the (X)HTML output,
 * properly enclosed as <script>, after the according <textarea>, or execute the return value by other means.
 *
 * @param string $element_id  The id of the textarea that should become an editor instance.
 * @param string $config  The configuration string.
 * @return string  The JS to actually create the editor.
 */
function EDITOR_replace($element_id, $config = '')


/**
 * Instantiates the editor(s) on the textarea(s) given by $element_classes.
 * $config is exactly the same as for EDITOR_replace().
 *
 * @param string $element_classes  The classes of the textarea(s) that should become an editor instance. An empty array means .xh-editor.
 * @param string $config  The configuration string.
 * @return void
 */
function init_EDITOR($element_classes = array(), $config = '')
 

Remarks

1. N.B.: EDITOR in the function names above must be replaced by the (folder) name of the editor plugin.
2. <DEL>$element_class was simplified to take only 1 class instead of an array. Martin came up with the idea in a PM tonight. IMO that's a simplification for editor integrators, and should suffice for editor users (i.e. plugin authors).</DEL>
3. I've intentionally left out the specification, who's resonsible for calling include_EDITOR(), if EDITOR_replace() is used: the caller or the callee. IMO the latter should be flexible enough, and will save the caller an additional call.<EDIT>As tinyMCE and CKEditor leave the responsibility to the caller, we should stick with it.</EDIT>
4. I've mentioned JSON format in the description above for brevity. Actually it's an object in JS syntax (JSON is more restricted).
5. The allowed syntax of the $config parameters has to be specified by the editor integrator. And of course he should specify, which placeholders (if any) are allowed, and what they stand for. Editor integrators are encouraged to implement this as similar as possible to the upcoming reference implementation of tinyMCE and CKeditor. But anyway: the values 'full', 'medium', 'minimal', 'sidebar' and '' must be accepted and should result in editors with appropriate tool bars: full should result in an editor with all the bells and whistles the editor provides; minimal will give an editor with a toolbar thats common for typical front-end editors; medium will result in something in between; sidebar should result in a toolbar, that is so small, that it could be used in a typical sidebar without overflow.
6. About the implementation: the editor integrator is free to implement the specification as he likes. IMO it's not necessary to restrict him doing it in a special way. E.g. it should be his decision, if he uses a glob loop to check for the existance of an init file, or file_exists(), or even having no init file at all. And it is not mandatory to implement EDITOR_filebrowser(), as this doesn't have to be called by editor users.
7. Editor users should prefer to use the common values for $config as far as possible, as they will be implemented for all editors, and so they can call init_editor() or editor_replace(). If they need specific configurations, they must make sure that the correct editor is called, e.g. by calling init_EDITOR() resp. EDITOR_replace() directly.
8. The editor's should be usable from the front-end too, but in this case they have to restrict access to the filebrowsers and similar functionality (e.g. insertion of download links).

</EDIT>

Christoph

PS: Changed according to the following discussion and some PMs.

[Holger]

Hi,

to be honest, I'm not sure if I understand right.

In short:

1. include_editor() is doing the same as before

2. editor_replace() gives us one (1) full configured and working editor and does not write to hjs / onload etc.

3. init_editor() will now replace multiple textareas defined by a class-name (that might be easier than an array of classes, but you'll loose the advantage of the different css)

So if I'm right here, I don't understand why that (the single class) should be better than the definition before?
And I do not understand why you're using classes at all (not id's, or an array of id's)?

But I think there is some missunderstandig or I have missed something

Holger

[cmb]

Hi Holger,

So if I'm right here

Yes, you are.

but you'll loose the advantage of the different css

AFAIK that's no problem these days, as multiple classes will (at least partially) be understood even by IE6. And: do editors need any CSS besides their "themes"?

I don't understand why that (the single class) should be better than the definition before?
And I do not understand why you're using classes at all (not id's, or an array of id's)?

The single class might suffice for many purposes. And init_editor() can be called many times (if it's well implemented, it shouldn't cause any overhead besides some function calls). IMO ids or an array of ids are fine too; I just wanted to change too much. And of course, we can stick with the array of classes as well.

Christoph

[cmb]

Hello Developers,

one additional point that has to be clarified: should the editors be usable from the front-end? This is currently not possible with tinyMCE, and IMO for good reasons: the editor gives access to the filebrowser(s) on the configured folders!

Probably we should stick with this for securtity reasons. What's your opinion?

Christoph

[Gert]

should the editors be usable from the front-end?

Never

Frontend editors have their own laws, it's not so easy to make them safe,

Gert

[Holger]

Hi,

IMO at the moment we should first finish the work on the "normal" editor interface...

Never

Frontend editors have their own laws, it's not so easy to make them safe,

In general: I can't follow why it should be hard to integrate a save frontend editor?
You only need a adjusted configuration.

But I agree with Gert that it's not a good idea to provide frontend-editing by default!

KR
Holger

[cmb]

Hi Holger, hi Gert,

IMO at the moment we should first finish the work on the "normal" editor interface...

Yes, that's the most urgent need.

In general: I can't follow why it should be hard to integrate a save frontend editor?
You only need a adjusted configuration.

Yes, of course. But are all potential plugin authors are aware of the pitfalls, e.g. that the "normal" filebrowser will give access to functionality, that might better not be available for front-end use? I'd rather avoid that Ajaxfilemanager_XH would be used from the front-end (currently it's not possible).

And please note: front-end access doesn't mean public access in all cases. The editor might be used on protected pages (Memberpages, Register), what's currently possible from Calendar for example. If the editors will be protected by means of $adm, such usage won't be possible anymore.

So we have to decide, what to do. The editors as well as the filebrowsers could be protected against front-end use. Should they? IMO: yes (at least for now).

Christoph

[Holger]

Hi folks,

after that long discussion I have now finished the CKEditor-Plugin. It's available from my Homepage.

I have made all the changes like discussed above:

• include_editor() brings the editor.js to $hjs
• editor_replace() gives us one (1) full configured and working editor and does not write to hjs / onload etc. It'll look for the pre-configured configurations in /inits but accepts a configuration-string in $config too. The curly brackets are removed, they should be part of the init-file or of $config
• init_editor() will now replace multiple textareas, defined by a class-name or an array of classes, with full configured editors

All functions are working for frontend-editors too***, as mentioned by Martin. But I have, for security reasons, disabled the "internal-features" for CKEditor.
When not in admin-mode

• the filebrowser is disabled
• the combo-box for internal links and download-links is removed

***

one additional point that has to be clarified: should the editors be usable from the front-end? This is currently not possible with tinyMCE, and IMO for good reasons: the editor gives access to the filebrowser(s) on the configured folders!

That's not true - as we've find out. At the moment (XH 1.5.1) TinyMCE is usable in the frontend. The filebrowser is disabled but the internal-link list is usable.

I hope TinyMCE will be changed according to the new defined interface with the next release of XH too.


KR
Holger