Well, I have to say the results were not what I expected. Nearly every developer had ‘their’ own way of doing this and there wasn’t one single example that used the same method or methods and the more I looked, the more I got so confused with it all. I hate to think what someone with little knowledge of Xoops and PHP must be thinking, I really do dread.

The problem stems from all the different editors that are actually available right at this moment and the fact that no one has bothered to consult each other over what would be the best approach (Myself included) to bring some uniformity and compatibility to the whole issue, well expect for DJ that is and kudos to him for doing so too.

For me, XoopsEditors should become the standard de facto for all developers and if users want a specialist editor, seek the developers who do these instead and users should install these themselves.

Anyway, back to the XoopsEditors issue. Originally, this class was written for Xoops 2.2 and not the 2.016 branch, and this is where lays the issues for all developers. If you look at the Xoops 2.2 package, especially the XoopsEditors Class and compare it with the class that DJ has made public, there are certain differences between them; mainly files included in the 2.2 version that are missing from the XoopsEditors package.

In the sampleform.php example it states the following for adding this class to your own module:



Yet if I do this on the on the 2.018+ branch I get the following error:

Quote:

Well this is really to be expected. Because no where in the XoopsForm class there is a ‘hook’ to include this class at all. Sure I could add the following line:

Require_once XOOPS_ROOT_PATH.’/class/xoops_editor.php’ before calling this line:

Quote:

But in reality we shouldn’t need to do that. If the XoopsForm class requires XoopsEditor to work correctly, then we should have the mechanics already within the XoopsForm class without the developer having to worry about additional lines of code to make it work. The XoopsForm class should handle this.

So bear in mind, the XoopsEditor class was originally written for Xoops 2.20 and the Xoops editor will work correctly as above, but, I want it to work on Xoops version 2.18+ without having to resort to having to add loads more code that just break compatibility.

Lets look at an example within the news module, the workaround by Herve wouldn’t have been required if the class was written for both 2.00 and 2.20 branches.



As you can see, First there is a check to which version of Xoops is being used, then there is a check to see if there is another Koivi editor installed, then if both fail we use the default. This is not the best solution for a developer anyway. In reality we shouldn’t need to have two different Editor Classes installed. This is where all the confusion comes from, what works with what?

I am quite sure I am not alone when I say this from a developers point of view, but I dread when someone asks me to add a WYSIWYG editor to my modules. Why? Because there isn’t no standard within the Xoops frame work to do so. Well until now.

Actually the answer is quite simple and it gives all developers one way of including the many different editors within the XoopsEditor framework on 2.00, 2.20 and now 2.30 thus having compatibility across all versions of Xoops and without having to resorting to creating their own hooks to do so.

Here is how:

First we have to modify the following file:

Quote:

And add the following lines at the end:

include_once XOOPS_ROOT_PATH . '/ class/xoopsform/formeditor.php';
include_once XOOPS_ROOT_PATH . '/ class/xoopsform/formselecteditor.php';

Then copy the above files from the 2.20 version over into the 2.00 branch that you use.

Hopefully DJ will include these within his excellent XoopsEditor class and developers start to use the above method of including Editors within their own modules and bring back some uniformity and lessen the impact of compatibility issues within Xoops.

Hope this helps everyone a little.