::Text::

!More Heading 
Wiki Syntax
{DIV()}Some Stuff Seen Only When Using Wiki-editor{DIV}

{WYSIWIG(id=“wysiwyg_area_01, group=“editors“)}<p>My Wysiwyg</p>{WYSIWIG}

Wiki Syntax again
{SPLIT()}{SPLIT}

Problem 1: Wiki formatting entered in wysiwyg don't survive save.

Most notably !hello enclosed in para tag does not become a header.

- Solution used by nkoth (he needs to port this from his now deprecated 1.9/TinyMCE to 1.10/FCKEditor): Create a parse_wysiwyg_onsave() function that is called whenever something is saved from wysiwyg editor.

- Roadmap: nkoth has only basic things in his stuff. Others can help in adding to this. The goal is not necessarily to replace all HTML with wiki syntax. Stuff going into the parse_wysiwyg_onsave() function will be classified either as "mandatory" (i.e. will cause bug otherwise), or "optional" (i.e. optional feature with the aim to replace all html tags with wiki syntax on save), so that people who don't care about the optional stuff can turn it off (since more parsing likely == more bugs).

Problem 2: Wiki tags appearing in wysiwyg mode.

This is caused by someone else using non-wysiwyg causing introduction of undesired wiki syntax. Not all wiki syntax is undesired, for example, links are obviously desired.

- Solution used by nkoth (he needs to port this from his now deprecated 1.9/TinyMCE to 1.10/FCKEditor): Parse data before passing it to wysiwyg editor. This is done by modifying parse_data() to receive an additional parameter "$for_wysiwyg = true/false" to limit the parsing done before edit. In other words, this is a subset of the current parse_data(). Obviously, some stuff like {...} and wiki links (or anything that creates an internal url) should not be parsed for wysiwyg editing but only for viewing/previewing.

- Roadmap: nkoth had this working in his deprecated setup. To test after his port.

Problem 3: Html tags appearing in non-wysiwyg mode.

This is caused by someone else using wysiwyg causing introduction of html tags.

- Solution so far: Ignore problem. For some sites, the non-wysiwyg mode is disabled and is no problem. Otherwise, it is used only by advanced users who don't mind.

- Roadmap: Persevere with the solution to problem 1 in using those "optional" parsing on save to indirectly solve this. For sites where wysiwyg is mandated - this problem is not an issue.

Problem 4: Html tags appearing in between wiki syntax breaks stuff.

Just try creating a link e.g. ((Link to Page)) in wysiwyg, but before saving, highlight the word "Page" and make it bold, and then save. You will see the problem.

- Solution so far: Tell my users they cannot format stuff within wiki syntax.

- Roadmap: Add strip_tags to the patterns that are matched by stuff in parse_data(). It will check for $is_html first, of course. But this will have to be selectively applied to problem cases, because there may be cases where html tags may be desired and may not cause any problems.