Calls to plugins which are inside a call to the WYSIWYG plugin produce no output (which usually means that their effect is invisible). Some plugins, such as FOOTNOTE, have effects other than causing output, so calls to these may keep part or all of their effect.
This bug was introduced by the changes to wikiplugin_wysiwyg.php in r50752. Tiki versions 14 to 18+ are affected.
The following call to WYSIWYG demonstrates:
{WYSIWYG(use_html="n")} This dummy content is visible.{FOOTNOTE()}Note which is invisible, but should be indicated by a number which is actually invisible{FOOTNOTE} {GROUP(groups="Admins")}This should be visible for admins{GROUP} {FADE(label="This should be visible")}Hidden{FADE} {WYSIWYG}
This happens because plugin_execute() calls ParserLib::convert_plugin_for_ckeditor() since ck_editor is true, and therefore returns an empty string to parse_first(), and therefore to parse_data(). That parse_data() has its ck_editor option true, since it is called by parseToWysiwyg(), called by wikiplugin_wysiwyg().
Unfortunately, the revision bringing this regression also fixes WYSIWYG edition. So going back to the previous situation breaks edition again. One can only choose between working visualization and working edition.
I believe the way to fix is to go back to parse_data(), but re-parse the plugin call's content differently when editing.
To help developers solve the bug, we kindly request that you demonstrate your bug on a show2.tiki.org instance. To start, simply select a version and click on "Create show2.tiki.org instance". Once the instance is ready (in a minute or two), as indicated in the status window below, you can then access that instance, login (the initial admin username/password is "admin") and configure the Tiki to demonstrate your bug. Priority will be given to bugs that have been demonstrated on show2.tiki.org.