How to use editor in plugins?

[Holger]

Hello,

Comments_XH has an own mini TinyMCE - special configured for the safety concept of Comments_XH, and RealBlog_XH uses the standard TinyMCE.

Hmm, so if I want to use another editor for the content and want to use the polished AdvancedNews, I have to install TinyMCE too.
The flexible editor-integration could be easy made for both of the plugins above .

If that's the statement from a leading "Team" member, I ask myself why we spend hours and hours making our hands dirty on coding a editor - interface .
So XH may stick on TinyMCE, even if some users have problems with it, e.g. table-handling.
I've wrote somewhere that I had trouble with TinyMCE on a bigger project and that I've solved that with a quick & dirty FCKeditor for XH 1.5.
I'm aware how to include an editor to XH. I need no flexible interface. And I must not share time, code and ideas on useless things...

So I should "sit and wait".

And BTW:

for the safety concept of Comments_XH

I know that some of the last updates of the plugin brought more security to the handling of the user-input. But it's still possible to include single malicious characters in the output and the "funny-string" - replacement ( for those who want to play ) fails on combinations of some scripting code.
I told you from the beginning that this concept could never be secure under all circumstances, because it filters only all malicious code you aware about.
And do you really aware about all of them? Hope so.

The PHP developers have created some simple to use functions to sanitize user-input. I don't know only one reason to ignore that. But that's your turn and I don't want to start here a longer discussion on that.


Holger

[Gert]

If that's the statement from a leading "Team" member

That's the statemant of the Developer of the Plugins Comments_XH and RealBlog_XH.

Another statement: There IS no other Editor available for CMSimple_XH yet. So I can't implement one ...

[cmb]

Hi Holger, hi Gert,

RealBlog_XH uses the standard TinyMCE.

That's not quite right. The following code does the editor initialization in Realblog_XH:

Code: Select all

        switch (strtolower($plugin_cf[$plugin]['editor']))
            {
            case 'fckeditor':
                // FCKeditor
                
                require_once ($pth['folder']['cmsimple'] . 'realblog_fckeditor.php');

                break;

            default:
                // default editor of CMSimple_XH 1.5
                init_editor(array('realblog_headline_field','realblog_story_field'));

                break;
            }
 

The FCKeditor is included for downward compatibility. $plugin_cf['realblog']['editor'] defaults to ''. So the user configured editor will be used for the teaser and the story as init_editor(), and not init_tinymce() is called (it works with Textarea_XH 1beta1, Codeeditor_XH 1beta1 and the ckeditor-draft ).

Comments_XH might be another thing. This is delivered with it's own tinyMCE, so no additional editor must be installed. And IIRC Holger wrote, that the editor interface is primarily intended for back-end editors (sorry, I wasn't able to find the post).

Christoph

PS: so I see no reason for quarrel.

[Gert]

Hello Christoph,

that's what I meant (in the first post) ... I wrote "standard editor" and meant the "pre configured editor".

In a german thread perhaps it were not happened ...

Gert

PS: And maybe I have forgotten, that I already have done it (in the second post) ... it's your code - do you remember?

[cmb]

Hi Gert,

In a german thread perhaps it were not happened ...

IMO the usage of the editor interface (and perhaps changing it) is best discussed in an English thread, because not all plugin developers are able to understand german, let alone speaking it.

And of course, misunderstandings might happen when discussing in a foreign language, but at least this one is clarified now.

Christoph

[Holger]

Ok, then let's forget that.

Back to topic:

If it's a config file or string, which could contain the %PLACEHOLDER%s, it basically comes down to calling init_editor() or include_editor() + editor_replace().

If I understand right, placeholders should always parsed in the functions editor_replace() and init_editor() of init.php.

Ok. Then the only difference between init_editor() and include_editor() + editor_replace() is the possibility to activate single instances on demand. Right?
So should we / I write duplicate code in those two functions or is it better to give init_editor() a 3rd. parameter controlling the replace and drop the rest?
That may be possible...
Ahh, and only processing config-strings is fine with me.

KR
Holger

[cmb]

Hi Holger,

Ok. Then the only difference between init_editor() and include_editor() + editor_replace() is the possibility to activate single instances on demand. Right?

There are actually 3 differences:

1. editor_replace() doesn't do the instantiation immediately, but instead returns JS (complete script or just the JS code?)
2. init_editor() takes an array of classes as 1st param; editor_replace() takes an ID
3. editor_replace() doesn't call include_editor() (or should that be changed too )

So should we / I write duplicate code in those two functions or is it better to give init_editor() a 3rd. parameter controlling the replace and drop the rest?

Because of point 2 in the list above (and IMO we should stick with this), the third param might not be the best idea (well, would be no real problem to accept an id or an array of classes in one function though). But the problem of not having duplicate code could be solved in the following way:

Code: Select all

function do_all_the_hard_work() {
    // do all the hard work ;)
}

function editor_replace(...) {
    do_all_the_hard_work();
    return $js;
}

function init_editor(...) {
    include_editor();
    do_all_the_hard_work();
    $hjs .= $js;
}
 

But I'm still not totally sure, if editor_replace() should be changed to do nearly the same as init_editor(). Perhaps Martin had a good reason to specify editor_replace() only as minimal instantiation function.

Christoph

[Holger]

Hi Christoph,

so I'll make my changes according to the last posts (again - thought I can release the stuff this weekend).
In short:
- remove the glob-loop
- only strings for $config
- placeholders get processed the same way in editor_replace() as in init_editor().

Beside this, I'll remove the curly brackets around $config in editor_replace() because they 're contained in the config-files (/init/init_*.js).
We should at least handle this everywhere the same.

But I'm still not totally sure, if editor_replace() should be changed to do nearly the same as init_editor(). Perhaps Martin had a good reason to specify editor_replace() only as minimal instantiation function.

If we only integrate the things above, it can be used as the minimal instantiation function like before. It only depends on the given $config, IMO.

But maybe Martin will bring some light into that. So let's see, if he find the time to replay soon.

KR
Holger

[Martin]

Hi Holger, hi Christoph,

hmm, I try to remember: If I am halfway right, we just wanted to split loading of the editor's js-library - include_editor() - from the concrete instantiation to make it possible to have each wysiwyg editor instance in a specific way - editor_replace($editor, $config). The third function - init_editor() - did both in one rush and was meant to be run once, basically to load CMSimple's content editor, but accepted other editor / textarea classes as well. The init_*.js files contained the whole init function of the editor: tinyMCE.init({ //all options});

In the meantime things have changed. As Christoph has rewritten a good part of the TinyMCE-init, it is possible to have specific editors by calling init_editor() several times as well. This makes editor_replace() probably obsolete. There are some minor things, I still like more with this split version - shorter js-code, the plugin author can insert it after the textarea, so we have a shorter $hjs and do not need to use $onload (or its jquery equivalents). (Putting all js to the header, mixing stylesheets and scripts in $hjs is a bad habit of CMSimple, but that's another story.) No good reason to keep two functions that do basically the same.

So I think we can drop editor_replace() - if it is not in use yet, of course. As the "init_*.js" have become "config_*.js" - very good idea - we should just change the init_editor() a little bit to make it accept the short configuration name ("full", "medium", ...), a config string as well. (Maybe the pathname, too, but the plugin author could pass the content of the file as well. We just have to decide or toss a coin.)

LG

Martin

[cmb]

Hi Martin,

thanks for the clarification. So I had misunderstood the initial intention of init_editor(). I thought from the beginning, that it was meant to be possibly called more than once, e.g. as CMSimple's content editor and additionally from the Trabant. If init_editor() could be called only once, this would prohibit its use from plugins that perhaps need editors simultaniously.

This makes editor_replace() probably obsolete.

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 the pathname, too, but the plugin author could pass the content of the file as well.

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. Consider e.g. Whizzywig: the only configuration, that can be done for each editor differently is the layout of the toolbar. So I think it's quite possible to implement the editor interface without any init files, but just using $plugin_cf['whizzywig']['init_*']. Well, writing this to a file wouldn't be a big deal either.

Christoph