History: WYSIWYG
Source of version: 51 (current)
Copy to clipboard
Please see ((WYSIWYG and Markdown)).
{REMARKSBOX(type=note, title=Note)}''This pages seems outdated and needs a revision {img src=img/icons/page_edit.png}''
''Torsten''{REMARKSBOX}
doc:((doc:WYSIWYG))
!! Idea for solving some of the WYSIWYG issues:
{CODE(caption="EXAMPLE")}::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}
{CODE}
WYSIWYG plugin can "protect" the wiki syntax from being messed. Additionally by having an id and groups we could achieve pages with different edit permissions per section. Done for Tiki9 with ((doc:PluginWYSIWYG)).
!! Status/RoadMap
For Tiki 6 see new notes here: ((wysiwyg editor update to CKEditor)).
''The rest of this page is probably mostly obsolete...''
Since Tiki 1.10, Wysiwyg in Tiki is implemented using FCKEditor. It is tagged as experimental as it's not as reliable as it should.
!!!Some further (recent - July 2009) observations and issues
A short description on trying to use the WYSIWYG editor in a new site deployment using Tiki 3.0 are available ((WYSIWYG observations|here))
!!!-Old reports of issues
!!!!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. ~np~((Link to Page))~/np~ 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.
!!Wishlist
!Open
{wishes filtervalue="74" status="o"}
!Pending
{wishes filtervalue="74" status="p"}
!Closed
{wishes filtervalue="74" status="c"}
!! Interested community members
{LIST()}
{filter type="trackeritem"}
{filter field="tracker_id" exact="2"}
{filter field="tracker_status" content="o OR p OR c"}
{filter categories="74"}
{sort mode="modification_date_ndesc"}
{pagination max="20"}
{OUTPUT(template="table" pagination="y")}
{column label="Login" translatelabel="y" field="f_39" sort="tracker_field_f_39" mode="raw"}
{column label="Full Name" translatelabel="y" field="f_11" sort="tracker_field_f_11" mode="raw"}
{column label="Interested in features" translatelabel="y" field="f_61" sort="tracker_field_f_61" mode="raw"}
{column label="Last Modif" field="modified"}
{OUTPUT}
{FORMAT(name="f_39")}{display name="tracker_field_f_39" format="objectlink"}{FORMAT}
{FORMAT(name="f_11")}{display name="tracker_field_f_11" default=""}{FORMAT}
{FORMAT(name="f_61")}{display name="tracker_field_f_61" format="trackerrender" default=""}{FORMAT}
{FORMAT(name="modified")}{display name=modification_date format=date dateFormat="%d %b %y %H:%M"}{FORMAT}
{LIST}
! Related links
[http://www.mediawiki.org/wiki/WYSIWYG_editor|"In 2009, there is no available 'ready-to-go' package for incorporating full WYSIWYG into the MediaWiki software. The problem is that any WYSIWYG editor would have to know wikitext grammar, and no full grammar for wikitext exists - the "parser" doesn't parse, it's a twisty series of regular expressions. So present WYSIWYG editors either have to (a) reverse-engineer as much of a grammar as they can, or (b) forget wikitext and just write HTML."]
* https://wiki.mozilla.org/Support/WYSIWYG:PRD
* http://help.wikia.com/wiki/Help:Rich_text_editor (nice!)
* http://www.economist.com/blogs/babbage/2011/12/changes-wikipedia
* [http://ghosted.it/|GhostEdit]
* http://markitup.jaysalvat.com/examples/wiki/
* http://visop-dev.com/blogpost12-WYSIWYG-Edit-Tiki-s-wiki-syntax-A-lesson-on-keeping-it-simple
* https://groups.google.com/d/msg/codemirror/BMdcRPweWGY/3g8jrUG6xLEJ
* https://editorjs.io/
! HTML5 WYSIWYG
* https://github.com/xing/wysihtml5/
* http://www.wix.com/
* https://getsatisfaction.com/aloha_editor/topics/can_aloha_editor_be_used_as_an_xml_editor
! jQuery & WYSIWYG
http://www.queness.com/post/212/10-jquery-and-non-jquery-javascript-rich-text-editors
http://www.jacmoe.dk/what-you-see-is-what-you-mean
! Projects
* ((WYSIWYG wiki)) WYSIWYG editor generates Wiki syntax
* ((WYSIWYG-ish wiki)) improve wiki interface
* ((Quasiwyg))
!! Summernote
{HTML()}<iframe src='https://openhub.net/p/summernote/widgets/project_factoids_stats' scrolling='no' marginHeight='0' marginWidth='0' style='height: 220px; width: 370px; border: none'></iframe>{HTML}
!! ProseMirror
{HTML()}<iframe src='https://openhub.net/p/prosemirror/widgets/project_factoids_stats' scrolling='no' marginHeight='0' marginWidth='0' style='height: 220px; width: 370px; border: none'></iframe>{HTML}
https://www.indiegogo.com/projects/prosemirror/
!! Squire
https://blog.fastmail.com/2014/12/08/squire-fastmails-rich-text-editor/
{HTML()}<iframe src='https://openhub.net/p/Squire-WYSIWYG/widgets/project_factoids_stats' scrolling='no' marginHeight='0' marginWidth='0' style='height: 220px; width: 370px; border: none'></iframe>{HTML}