History: EditorDev

The Wiki, comment, blog, forum, etc. editors, even the "WYSIWYG" ones, aren't suitable for content authoring.

There must be a better way to modify content than using a Textarea.
ML: Let's find it.

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.

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.

userPagesylvie: There is a hard coded timeout in tiki : after 5 minutes of "inactivity", you will be logged out as soon as another user loads a page. (inactivity defined as you don't load a page but you can be typing in your textarea input). Before this problem is repaired (external parameter + ....) (I will work on it as soon as possible), it seems there is a possibility not to loose nothing by using "remember me".
ANother solution can be to go in lib/tikilib.php, function update_session and to change the 5 for 5 mn to a bigger value.
I don't think it is a IE problem (perhaps there is another problem)

• No matter how big your monitor is, it's always the same height

ML: PHPwiki has a nice feature where you can resize the text entry box

• UserPagebpfaffenberger textarea sizes are hard-coded. Why not insert variables in place of the hard-coded textarea sizes values, and enable users or admin to modify as desired?
• Although this will be fixed soon (hopefully), Mozilla Firebird 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.

• 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

• 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
  • userpageterris: 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.
• Could the text area "rows" be configurable via a per-user setting?
• 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.
• 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.