Adding an editor... question about the documentation

[s_mack]

whereas, if I do this:

<?php
define("EDITOR_TEST", "Test");
 $editors_list['TEST']  = array('desc' => EDITOR_TEST,  'handler' => 'test.php',  'special_needs' => '');

It works. And that shouldn't be the case. Do you think this warrants a bug report? I feel this proves that this function is called in the wrong order. The define should be read in before the function, but clearly (to me) it is not.

[s_mack]

When I wrote "and that shouldn't be the case", I meant I shouldn't be putting that in there, not that it shouldn't have worked. Of course it would work. Its the wrong way to fix it.

[s_mack]

Of course, there is more than one way to skin a cat. If I do things against the documentation/comments and instead override the init_html_editor.php file (by overriding I'm still playing within module rules), I can "hardcode" my editor in the same way ckeditor, et al are. Its a heavy handed way to do it, but it solves the problem. And I think doing it that way is better than previous and/or hardcoding the language.

Anyway, I'm convinced it is a bug. But a self-solvable one, so I've posted a bug report along with solution and a suggestion that they save themselves work and only address it for 1.6 because clearly not many people are bothered by this.

[s_mack]

Hopefully whatever editor you're either developing or planning to incorporate may be worth providing back to the community and that you consider packaging it for others as a plugin.

That is the idea. I found a really nice one but I have no idea how well it will play with ZC. I didn't think it would take this long just to get a skeleton :)

[mc12345678]

The system loader: admin/includes/auto_loaders/config.core.php

loads general functions (which includes the functions/extra_functions directory) before the language information, so yes the guidance provided in the file admin/includes/init_includes/init_html_editor.php is not exactly applicable any longer...

Ages ago, the suggestion was to modify other locations in the fileset, with the "solution" being the init_html_editor.php file...

Suggestion would be to simply load the new editor in the init_html_editor.php file as performed with the other editors and then add the language file as suggested... Yet again, I was wrong using the guidance of the init_html_editor.php file to try to explain the situation, but it's really looking at how the code goes and loads that shows that a new editor is "best" incorporated into the init_html_editor otherwise need to use some form of loader that would trigger before action point 180 but after action point 70 to capture the language define in order for the html editor list to be populated.

[RodG]

It works. And that shouldn't be the case. Do you think this warrants a bug report? I feel this proves that this function is called in the wrong order. The define should be read in before the function, but clearly (to me) it is not.

You are correct

I was actually looking into this problem and came back to report my findings only to see that you've got here ahead of me.

The extra_functions are being loaded by the /init_includes/init_general_funcs.php file and the extra_definitions are being called by the /init_includes/init_languages.php file.

These files need to be loaded in the reverse order for it to function correctly.

Hard coding the 'define' eg
$editors_list['TEST'] = array('desc' => "Menu text" , 'handler' => 'test.php', 'special_needs' => '');

.. is a way around the problem - and it won't have any detrimental effect (or affect whether the editor will work or not). This is purely a textual/display issue rather than a functional issue <g>

Nonetheless, it does appear to a be 'legitimate' bug that should be reported, as this is sure to affect any other 'extras' that may be added.

Cheers
RodG

[mc12345678]

A solution could be to create an admin/includes/auto_loader/config.EDITOR.php file that loads the "editor" into the array. I'm thinking just before 180 (ie. at 179) instead of loading it as a function.

So:
admin/includes/auto_loader/config.neweditor.php would contain:

<?php 
$autoLoadConfig[179][] = array('autoType'=>'init_script',
'loadfile'=>DIR_WS_FUNCTIONS . 'extra_functions/editor_neweditor.php');

Otherwise it would seem that the idea is/has become that functions would not contain language defines in them... Don't know if that is case/expectation, but it is the sequence of loading that is currently in place.

[mc12345678]

A solution could be to create an admin/includes/auto_loader/config.EDITOR.php file that loads the "editor" into the array. I'm thinking just before 180 (ie. at 179) instead of loading it as a function.

So:
admin/includes/auto_loader/config.neweditor.php would contain:

<?php 
$autoLoadConfig[179][] = array('autoType'=>'init_script',
'loadfile'=>DIR_WS_FUNCTIONS . 'extra_functions/editor_neweditor.php');

Otherwise it would seem that the idea is/has become that functions would not contain language defines in them... Don't know if that is case/expectation, but it is the sequence of loading that is currently in place.

Well "dumb" me... That won't exactly work, as the array will have already been loaded with the non-assigned constant, resulting in two listings in the dropdown, one with the "correct" text, the other not... Sigh.. So perhaps instead place the array data in a file in the functions folder instead of the functions/extra_functions folder with the auto_loader pointing to the functions folder and the new "function" that is adding the new editor to the list:

<?php 
$autoLoadConfig[179][] = array('autoType'=>'init_script',
'loadfile'=>DIR_WS_FUNCTIONS . 'editor_neweditor.php');

With admin/includes/functions/editor_neweditor.php as:

<?php
$editors_list['NEWEDITOR']  = array('desc' => EDITOR_NEWEDITOR,  'handler' => 'neweditor.php',  'special_needs' => '');

and the define still in the languages directory as previously.. ( admin\includes\languages\english\extra_definitions\neweditor.php)

<?php
  define('EDITOR_NEWEDITOR', 'New Editor');

[mc12345678]

Geez would be nice to be able to test this rather than just "think" about it... Actually the assignment would be fine either way because of using the key 'NEWEDITOR'... Make a choice. :) or rearrange the loading sequence of the files allowing constants to be incorporated into functions, or even modify how the html_editor load code functions so that it loads/populates the value of the constant at process time rather than as a an added value in the array when loading the function(s)...

Number of ways to address...

[s_mack]

Yes, absolutely... number of ways to deal with it. None of which is consistent with the documentation in the file :) I guess that was my point... not that anything needs to be "fixed", per-se... just that the documentation is incorrect. I mean, that really through me for a loop because I trusted the file's commentary to be at least somewhat accurate. But wrong paths and, really, wrong concept entirely. I'm sure it was correct at one point, so I understand how that happens. Really, shame on me for relying on comments rather than looking at what the code was going. When I eventually did that, I came up with a solution.