History: EditorDev

The Wiki editors, even the "WYSIWYG" ones, have several issues.

• Ability to set background color via ~~ quicktag
• See "Plug-ins and other magic", "HTML and Wiki Pages", "Previewing Wiki Pages", "Saving Wiki Pages", and "QuickTags" below

• userpageterris

IE users commonly lose their work if, say, mysql has crashed before they press the save button. Clicking the back button (if mysql is back up) results in a warning that the page has expired. Clicking OK results in the page being reloaded from disk in editpage.php, resulting in the loss of the last edits. However, Mozilla doesn't exhibit this behavior.

More commonly, sessions can time out while users are typing for a prolonged period of time. This leads to lost work on IE which causes extreme frustration followed by compensating behavior of saving pages too frequently which leads to a lot of bogus revisions and change notifications. Note that the session time is configuable in the "general" admin menu.

This behavior is by far the worst behavior exhibited by Tiki Wiki and has a very negative user impact. This issue must be dealt with as soon as possible.

ML: I agree: Losing work by using the back button is a big pain. Also can happen if you take lots of time to write an article. If there is a time-out, Tiki should offer to save data as a note or something... (offer relogin)

userPageterris: It's more than a big pain. My users are ready to give up on Tiki after having lost several documents. Why does IE think the page has expired? I guess IE doesn't want to cache the page.

userPageisotopp: Because PHP session management goes to great pains to have IE not to cache the page. See http://msdn.microsoft.com/workshop/author/perf/perftips.asp#Use%20Cache-Control%20Extensions and http://php.net/sesssion_cache_limiter.

userPageterris: I discovered the "session" settings in php.ini. These helped me tremendously. For example, I was able to increase the session timeout length and specify "none" (blank) for cache expiration. Just search for the text "session" in php.ini. On Windows, php.ini is located in c:\winnt or c:\windows. There are other settings in php.ini that deal with the browser cache. I was eventually able to fix most of the problems by altering php.ini and setting the TW session timeout to a huge number.

• Although this will be fixed soon (hopefully), Mozilla Firefox is unable to find/replace text
• You don't know what you're going to get until you click preview, and you lose your last caret position after you do so
• The Wiki markup is great shorthand, but it's wacky in many ways. XML would be a welcome change to using curly braces and ~'s. For example, why is __ for bold and === for underlining? _ should be for underline. Why are there two _'s and three ='s? This weirdness makes Tiki markup difficult for ordinary people. The only saving grace are the quicklink icons.
  • userpageterris: Unless there is a viable WYSIWYG editor, Tiki is unlikely to have widespread appeal for large-ish documents

• The WYSIWYG editor is ignorant of CSS styles and if used will pollute pages with repetitive font and other style information, which can't be changed via the themes or styles
• Existing text doesn't come up in the editor automatically; users get confused and overwrite their work
• Creating tables doesn't work very well

Preview causes the caret position and other settings to be lost. How about showing preview in a new window?

1. The Save button in the wiki editor needs to also be on the top and bottom of the textarea/htmlarea box
2. Need ability to Save wiki page and stay in edit mode

• The Allow HTML checkbox in the wiki editor needs to be stored on a page per page basis. Currently, if you check the box and edit the page again, the box will be unchecked and if you save the page, the HTML tags will appear instead of being displayed as HTML.
• When Allow HTML is checked, the page can't display XML tags. The only way to display XML tags with Allow HTML is to put a space after the leading bracket (<). A module is needed that can turn < into < at runtime.

• The "wiki quick help" has a link to "Show Plugins Help". Is this a dynamic list? e.g., if a new plugin is added, will it appear in this box?
  • Why isn't this list sorted alphabetically by plugin name?
• Ironically, it takes a very long time for authors to discover other useful magic incantations like { maketoc} and
   Plugin disabled

  Plugin banner cannot be executed.
  which demonstrate the true power of non-wysiwyg editing. The "wiki quick help" should also provide this information.

• ~~ QuickTag should be able to also set the background color
• Need a QuickTag for "in-line" proportional font

• CSS support — wouldn't it be nice if you could select a style and start typing in a WYSIWYG environment?
  • See WysiwygDev
• Could the Mozilla editor be used?
  • See WysiwygDev
• Could XML be used?
  • See WikiXML
  • What if TikiWiki supported embedded XSLT references and used them on the fly to convert xml to html? Then I could use docbook or whatever I wanted. However, there are plenty of opportunities to launch a denial of service attack on Tiki Wiki with XSLT. Perhaps Tiki should only support XSLT files that are located on the Tiki server. Perhaps Tiki would even "modify" the XSLT to suit the theme.
  • The slideshow functionality probably wouldn't work with XML. What is needed is an XML description of a slide show. This overlaps with Open Office's documents.
• Is it possible to return to the last caret position after clicking preview?
• Plug-ins are a challenge — open-ended rendering means that it will be impossible to write an editor that can render everything
• UserPageterris: I would be happy if Tiki could open my favorite editor containing the text, so I can edit it there. Upon closing my browser, the new text would appear in the textarea so I can decide whether to click Save or not. This is how Microsoft FrontPage deals with text files.
  • If there was a hyperlink to a .txt file, browsers would do this automatically; however, there's no automatic way to "post" the editor's contents back to the textarea or back to TikiWiki
  • Java could be used as a basic text editor. Web services or regular http could be used to get and post content.
  • A Java applet could act as a go-between via your text editor of choice and the textarea control
• Tarlbot: When I'm editing large tiki pages I often copy the whole Textarea and paste it into BBEdit, do my edits there and move the text back into the textarea and preview and commit. External editors could be cool.