Introduction
This page was initiated in June 2011 after a discussion on the dev mailing list (CKEditor breaks links to wiki pages). There, Bernard made an excellent statement:
Hi all,
From discussion to discussion we can conclude that most of us use Wiki (and certainly Source) to full fill properly our need when come to editing.
The all point of the Ckeditor is to give formatting capabilities to non-techi.
This is where start the headache.
There is no doubt that we need like any decent CMS/Wiki/etc_and_more a way for non-techi to edit new page or existing page (built under wiki by a dev).
Making dozens of Tiki Wiki vs WP/Sharepoint/Joomla/etc presentation (great work by the way !!!) won't help. Today the non-techi user want access, control and editing capabilities.
The "word" like toolbar is one solution. I have nothing against CKeditor on the contrary it is very neat and impressing.
But we have to make a way for to work like a charm no matter what are the condition (only wysiwyg, wiki + wysiwyg, wysiwyg after wiki, before, etc...).
From my point of view this should be one of our priorities.
I understand that it is easy to say that and it require resources and there is nothing in my message than encouragement and common sense.
Cheers
Bernard
Basically, it is all about context specific syntax transformation. When discussing different approaches, we should also consider, that during import/export operations, syntax transformations may be needed also.
Prior starting coding, a baseline study is required and basic decisions must be taken.
Baseline Study
Concurrent Usage of HTML and WIKI Syntax
Today, a page is stored using either HTML or WIKI syntax. This is a potential for inconsistencies and errors, because some of the data processing needs to be implemented for both syntax peculiarities (example: backlinks).
Status Editor Switch WYSIWYG
All pages are stored in WIKI syntax exclusively.
What do you think?
| Date | Name | Opinion | Remark |
|---|---|---|---|
| 11.05.2011 | Mauriz | agree | |
| 11.05.2011 | Torsten | too early to say, as the technical concepts of both editors and pontential of comatibility must be reviewed first |
Proposal: it would be a better solution to improve the UI and features to allow for selected editable sections within a page to open with the wysiwyg editor. This can be done using the section edit function or the INCLUDE plugin. These wysiwyg sections will always be opened with wysiwyg, by power users (techies) and by "regular" users. It is typical that wysiwyg is required mainly for text, paragraphs, formatting and other basic html stuff.
specifically, i think a variation of the INCLUDE plugin should be created and named the SECTION plugin. The main difference between INCLUDE and SECTION is the edit page link goes directly to the included page, and then returns the user to the "parent page" after editing.
Benefits:
- translation/syntax errors
- removes permission and usability issues related to allowing end users to see/edit plugins and other "not user serviceable" elements in a page
- both wiki and wysiwyg editor can develop according to the need of that kind of user (get better at what they do)
- allows a way forward to "in place editing" without being bogged down by editor compatibility issues.
Costs:
- costs should be minimal by adapting already existing functionality.
Security Considerations
We are talking about changing some code around editing and maybe around importing/exporting. This leads to some questions concerning possible security impacts.
Who can answer the following questions without any doubts?
| Question | Answer | Who? |
|---|---|---|
| Is potentially malicious content filtered somewhere in Tiki? | ||
| When is potentially malicious content filtered (prior or after writing to the database)? | ||
| If changing code around editing/importing/exporting, do we need to take some measures concerning security? |
Remote or Local Syntax Transformation?
The syntax transformation can be performed locally by the Tiki, remotely by the editor or by a mixture of both.
Editor Today
When it comes to change some code, it is elementary to know where the syntax transformation is performed. The question is, how the duties are distributed between the Tiki and the editor today.
Where are the following transformations performed?
- by the Tiki?
- by the Editor?
| Use Case | Answer |
|---|---|
| loading data into the WIKI editor | ??? Tiki:editlib.php ??? |
| loading data into the WYSIWYG editor | ??? Tiki:editlib.php ??? |
| pasting data into the WYSIWYG editor | ??? editor ??? |
| switching from the WIKI to the WYSIWYG editor | ??? Tiki:editlib.php ??? |
| switching from the WYSIWYG editor to the WIKI editor | ??? Tiki:editlib.php ??? |
| auto saving while using the WIKI editor | ??? Tiki:editlib.php ??? |
| auto saving while using the WYSIWYG editor | ??? Tiki:editlib.php ??? |
| saving data from the WIKI editor | ??? Tiki:editlib.php ??? |
| saving data from the WYSIWYG editor | ??? Tiki:editlib.php ??? |
| preview generation | ??? Tiki:editlib.php ??? |
Editor in the Future
The question is, what should be implemented in the editor (client side) and what should be implemented in the Tiki itself (server side). There are several issues to be considered:
- responsiveness of the UI
- server load
- common source for all kind of input (WYSIWYG editor, WIKI editor, import from file, ...)
- editor independence
- other?
- What are the priorities (minimizing server load, etc.)?
- Is there a guideline?
Issues
Links
- If using WYSIWYG, the links are stored using the HTML syntax. This leads to the following problems:
- If the target page of the link is deleted, the page is not listed in {WANTEDPAGES} and it is not shown using a '?' linking to tiki-editpage.php
- WikiParser_OutputLink is not invoked. This fact makes it difficult, to implement WYSIWYCA for links.
- other?
- If switching to from WYSIWYG to WIKI, links to wiki pages are converted to external links. This leads to the following problems.
- The table tiki_links will not be updated, i.e. backlinks do not work anymore.
- other?
All kind of links must be stored in WIKI syntax exclusively.
What do you think?
| Date | Name | Opinion | Remark |
|---|---|---|---|
| 13.06.2011 | Mauriz | agree |
Fixes Versus Revamp
There are two approaches to solve the issues:
- Implement fixes using the current implementation
- Complete revamp
Who has the knowledge to judge the situation?
Scratch Board
This section is intended to list missing issues concerning the baseline study.
- ???
Useful Links
Related
internal
- dev: WYSIWYG Status/Roadmap
(last edit 09, Aug. 2010, as of 07, June 2011) - doc: WYSIWYG documentation page
(last edit 27, Mai. 2011, as of 07, June 2011) - Why Wiki Syntax is Important
external
- Inline wiki syntax using jquery_19 on bjdodson.blogspot.com
- 10 jquery and non-jquery javascript rich-text-editors on queness.com
- http://mediawiki.fckeditor.net/ <- inspiration of the WYSIWYG wiki Project
- 2169 Copy-Pasting Word to Your Web CMS
Projects
- WYSIWYG wiki WYSIWYG editor generates Wiki syntax
(last edit 01, Dec. 2009, as of 07, June 2011) - WYSIWYG-ish wiki improve wiki interface
(last edit 26, March 2010, as of 07, June 2011)
;){kind=link}
;){kind=link}
;){kind=link}
;){kind=link}