Document requirement of certain editor _init.js files

[manu37]

Shop's product editing fails if in editor no init_minimal.js(on) and init_medium.js(on) file exist.
Please add system check accordingly.
Or is this rather an editor problem/missing fallback?

[cmb69]

Ugh, that is indeed hard-coded:

xhshop/classes/CmsBridge.php

Lines 59 to 63 in e3fafe7

	$bjs .= '<script>'
	. editor_replace('xhsTeaser', 'minimal')
	. editor_replace('xhsDescription', 'medium')
	. '</script>';
	}

Not sure if a system check is the best solution; maybe config options? And of course, documentation.

[cmb69]

Or is this rather an editor problem/missing fallback?

That is at least partially related to cmsimple-xh/cmsimple-xh#546. Without a respective fix, TinyMCE 5 will not work, regardless of the chosen init. With the fix, at least existing inits will properly initialize the editor.

Please add system check accordingly.

That would require the shop to look up the existing init files of the configured editor, what would require the shop to know about the details (where they are stored, and the exact filenames). I don't think this should be the job of extensions using the editors.

Okay, there would be a loophole, namely that such extensions could call editor_replace(), and checking its result; after the TinyMCE 5 issue mentioned above, the result would be an empty string, indicating that a missing init is referred to. Unfortunately, the would be different with TinyMCE 4, since that would return the given init string unmodified. Not sure how other editors would behave (there is at least Codeeditor_XH, which I would need to check, but there may be others).

So this looks too fiddly. A clean solution would be to add a new function for editor to implement, which allows to check whether certain inits are supported. Basically, something like tinymce_getInits(), but that would need to be standardized.

Not sure if a system check is the best solution; maybe config options?

Config options would have the same problem as mentioned above, so that doesn't look like a reasonable solution for now.

And of course, documentation.

I think this is the only remaining option for the time being.