Inline editing is currently only implemented in the ExperimentalBranches ckeditor4. However, a port to trunk should occur soon.
Inline editing has just been ported to trunk .
Test sites
Inline Editing in Tiki
End-user Documentation
This is how it currently works..
{flash type="url" movie="display306" width="771" height="302"})
The 3-second typo-fix is here! (if your system is responsive)
[+]
About inline editing
The Tiki inline editor is based on Ckeditor4. The editor can be quickly turned on/off. All processing is done client side.
Editing is done per "section". Sections that Tiki cannot handle editing of (e.g. sections containing plugins) are marked as not-editable. The user must use the standard editor to alter such content.
An inline editing session is "sticky", meaning it remains on until it is explicitly turned off. The user can thus visit multiple wiki pages in a single session. However, if changes are done to a page, these changes must be commit or cancelled before moving on to the next page.
When an inline session is ended, all pending changes (on the current page) are saved discarded.
It is not possible to create new sections inside the inline editor. It supports only editing of existing sections. They can however be freely edited.
After a section is edited, the user can choose top save or cancel the changes. Or, simply click somewhere else, and the section editor closes, but the (unsaved) changes remain. This way a number of sections can be edited, and reviewed, without actually committing the change. The system will mark the "dirty" sections for eay user recognition. At the end, commit all by saving from any section edit toolbar closing the inline editing session.
Beware of session timeouts. There is no auto-save.
Access to inline editing is controlled by the standard "edit" permission.
Inline editor limitations
The inline editor works on sections of the content, and it has some limitations
- New sections cannot be created. Thus, headings (H1..) cannot be created (it would create a new section)
- Sections containing plugins cannot be edited.
- It is not possible to edit the HTML source code
Page format issues
Wiki pages can be in wiki format or HTML format. Inline editing will save the content in the original format. Thus, for an HTML page, inline editing will save in HTML format. For a wiki page, inline editing will save in wiki format
Inline editing uses HTML , and the content must be converted to wiki format in order to save wiki format.
The wiki format has several limitations compared to HTML. The conversion process html-to-wiki may cause loss of data, due to these limitations.
Here is a list of known differences
- Tables will map 1-to-1 in HTML format. In wiki format the table scaling and formatting may get lost.
- HTML tags in the content (not active, but as a part of a description, is OK when saved in HTML format. The tags are correctly HTML encoded in the database. The wiki format will strip content that looks like HTML. Note: the standard HTML editor also cannot handle "HTML tags" in the content. It will convert the description tags to actual HTML elements.
References and Resources
Resources for testing
Tracker-based list of Wishes
Open
Pending
Closed
Wiki-based list of Open issues
-
Inline editing "eats" plugins
- As of r46852 elements containing plugins are no longer editable inline
-
The inline editor tags are saved along with the HTML content. This one has returned
-
Opening the regular wysiwyg-html editor, when the inline editor is open, will use a different toolbar
- Fix up inline menu.
- Should use max 2 rows.
- Must not use any plugins (since plugins are not supported at the moment).
- Help menu with the plugin selector should also be removed.
- The ckeditor4 image dialog should be used (with the "Browse Server" button)
- Possibly should be the ability to customise toolbars for inline editing for each type of object? Like you can for comments
Would make it possible to solve most of the issues above i think (can be done when back in trunk)
- Toolbar for the table element contains the paragraph format drop down (H1..6). Should be removed.
-
Inline editing a top-level table tag (not in a div or p) works, but no menu is displayed.
-
User is not warned, when leaving a page with uncommitted inline changes.
- Before starting an inline edit sessions, it must be checked if another editor is active. Similarly, when the inline editor is active, it should not be possible to start another editor (except by override)
-
Possible performance issue with large pages. The Lorem Ipsum page can be used for testing
-
It is possible to have uncommitted content displayed on the page. It should be visually easy to spot these sections, e.g. a red border. The "page-data" itself should also show that it has "dirty data".
-
On the wysiwyg wiki test server inline editing does not work. OK on the HTML test site.
-
Inline Edit: False positives visible in wiki diff after edit. They are not false positives. Check the difference in length between the sections. The problem is that an extra image is being inserted when inline editing.
-
"Rich Text Editor, editwiki" tooltip should be removed / changed. Occurs when inline editor is active, with mouseover an editable area.
-
HTML syntax in wiki pages. See below for steps to reproduce.
-
When closing the inline editor unsaved changes are lost. The user should get a warning, like when trying to leave the page.
HTML syntax in wiki pages
To reproduce..
0) set system in html mode (use wysiwyg-html as default)
1) create a new wiki page with very basic content, e.g. bla bla
save it (in html)
2) Reopen the editor and switch to wiki mode.
save the page (in wiki syntax)
3) now make some inline changes and save.
... wiki mode page has HTML tags
Tested in ckeditor4 exp branch. "Allow HTML" was not set.
Would be nice
-
The admin wysiwyg panel should make the 3 editor choices clearer. One of ("wysiwyg-html" or "wysiwyg-wiki") and possibly "inline editing". Now that wysiwyg is a basic feature, the selections look fine in the "basic" view.
- Auto save for inline editing / a way to recover unsaved content, due to a "lost" editor.
-
sections containing plugins are not editable, but the edit plugin button is showing an "edit frame". Clicking on it works fine, and the plugin dialog opens.
- to be able to add an edit comment
- Faster paste operation. Pasting works well, but is very slow
- Any chance of getting jcapture to work with inline editing.
Open Questions
Saving inline changes
Should saving inline edits be a regular save, or a minor save? For regular saves, an email may be sent to users monitoring the page. This may not be wanted for a tool that is "ideal" to fix typo's.
There is currently no way to select the type of save. A regular save is always done. Thus monitors can receive an email for every typo fixed.
All saves create a new version of the page. Each version keeps a full copy of the page data. Having 10 new versions, due to 10 typo fixes, is far from ideal. This would be the case if the user chooses save in the inline toolbar.
If the user left the changes uncommitted and did a final commit by turning the inline editing off, only one commit would be done. Thus only 1 new version of the page.
An excessive number of page versions can become an issue, depending on the use pattern.
Maybe inline saving should work more like auto save, i.e. write to a draft version until a commit/save is done. The commit can be when the inline editor is closed. If no commit is done, and the page is reloaded, the draft is still there and can be worked on even more before a commit is done.
This would limit the number of page versions.
Based on jonnyb's comment in Chat
"one main issue i think with getting plugins working is that it's not using the auto_save plugin, and most of the parsing etc for plugins is done by that ".
Sounds like we should re-introduce the auto-save function, somehow.
As a user I find it good to be able to save the content immediately after fixing (e.g. a typo).
This "save" could update the draft version.
A "commit" (a save of a new page version) should also have an explicit button, which the user can trigger. I assume the draft can be loaded by the standard editor and saved there.
Maybe the scheduled auto-save should be disabled. So, saving inline draft is only user triggered.
When a page is loaded and a draft exists for that page, the inline editor should then load the draft instead of the saved page.
Page in html syntax
[+] Page in wiki format
[+] Notes etc
[+]
Full commit info for phase 1 merge 24/july/13
Copy to clipboard
Merged from ckeditor4
[MOD] Make all wiki content inline editable, all the time, for now; just to test how inline editing feels.
No edit menu yet. [from revision 45106]
[NEW] Add "Inline edit" command button. Not ideal, there's still a "slight" context switch, but it's possible to turn inline edit mode on and off.
[NEW] Add a small popup menu for inline editing.
No save button yet. [from revision 46511]
[ENH] Mark the page-data outline as being in inline-edit mode [from revision 46746]
[ADD] missing file [from revision 46747]
dos2unix [from revision 46748]
[NEW] Popup menu with a save when using inline edit.
Still no contact to the background save. [from revision 46749]
[FIX] ckeditor path is moved from lib to vendor [from revision 46760]
[FIX] Integrate saving of inline changes.
[ENH] Inline edit outline color changed to light red [from revision 46761]
code cleanup [from revision 46762]
[FIX] warning
[FIX] shutdown inline editing, if the option is off [from revision 46763]
[FIX] Always initialize wysiwyglib
[FIX] Use wiki page section [from revision 46764]
[FIX] inline editor is only initialized if the current user has edit permissions [from revision 46765]
[NEW] Saving inline edit changes saves in allowed format.
Page is saved in HTML format, if it is enabled.
Otherwise the page converted to wiki format and saved [from revision 46775]
[ENH] Added some more buttons to the inline edit toolbar
[FIX] Handle empty referrer [from revision 46776]
[FIX] If page is saved as html, also set wysiwyg = y [from revision 46777]
[NEW] ckeditor plugin inlinecancel.
Adds a cross to the inline toolbar. When selected the inline editor is closed [from revision 46778]
[FIX] Declare variables to avoid JS warnings [from revision 46779]
Remove commented out code [from revision 46780]
[FIX] Kill ckeditor instances when the inline editor should close
and some code cleanup [from revision 46781]
dos2unix [from revision 46782]
[FIX] Use specified editor skin for the inline editor toolbar [from revision 46783]
[FIX] Use page is_html property when saving as it could be either [from revision 46784]
[MOD] rename tikiinline to inlinesave for consistency
[ENH] Create an inline editor for each top level element inside #page=data and change ajax inline_save to collect the whole page (some issues with ul - no toolbars and don't get saved) [from revision 46785]
[FIX] Kill all instances of the editor when terminating inline editing. [from revision 46786]
[FIX] Cascade contenteditable=false to all sub nodes on inline cancel [from revision 46787]
[MOD] Change the way the cancel button works - restore the original html and close the editor (allowing it to be re-opened) [from revision 46788]
[MOD] Close the editor after saving [from revision 46789]
[FIX] Wrap lists in a div so they can be edited (and join several bits of js together) [from revision 46790]
[CSS] Make inline elements border only appear on hover and be a little more subtle [from revision 46791]
[FIX] Make save button animations work - needs to be on a per-editor basis as the plugin is shared between many (needs fixing in other plugins too) [from revision 46792]
[ENH] toolbars: Use tiki-defined toolbars inline and remove irrelevant tools from headings. More tuning to be done... (and format_tags needs fixing) [from revision 46797]
[FIX] toolbars: Obey $params['switcheditor'] == 'n' so switch editor tool can be hidden for inline editing [from revision 46798]
[FIX] toolbars: Restore inlinesave and cancel buttons [from revision 46800]
[FIX] Inline edit command must be visible like regular edit for flagged revisions [from revision 46801]
[FIX] inline editor shutdown [from revision 46804]
[FIX] Check if latest version is viewed, before opening the inline editor when a flagged revision is active. [from revision 46808]
[MOD] Warn that Wysiwyg inline editing is experimental [from revision 46809]
[MOD] Change switching inline edit mode on and off from server to client-side (new blue page icon in the wiki topline actions) [from revision 46849]
[MOD] Change the pref name and move into the wysiwyg pref file and admin panel [from revision 46850]
[FIX] Prevent elements containing plugins being inline editable - not an easy one to fix... [from revision 46852]
[FIX] Don't use inline edit when editing [from revision 46855]
[FIX] textarea: Default to having the switcheditor button following logic correction in function.toolbars [from revision 46856]
Full commit info for phase 2 merge 30/july/13
Copy to clipboard
Merged from ckeditor4
[MOD] autosave: Move to a Service - wiki only so far, wysiwyg next (and tidy up) [from revision 46881]
[MOD] autosave: Move to a Service - wysiwyg [from revision 46882]
[MOD] autosave: Use html5 data attributes instead of temporary elements and global vars (more) [from revision 46883]
[MOD] autosave: Change the text for auto saved toggle so the link stays in more or less the same place [from revision 46884]
[FIX] autosave: Remove a load of code doing timeouts - not needed and probably duplicating server calls [from revision 46885]
[FIX] autosave: Add and deploy checkReferrer routine and some phpdocs [from revision 46888]
[REF] autosave: Convert autosave.php into a proper "lib" (finally) [from revision 46889]
[REF] autosave: Move and tidy edit ajax functions into a new service "Edit" - preview and much cleanup still to do
[FIX] Clean cke attributes & classes from html returned to server
[ENH] Generally nicer :) [from revision 46892]
[FIX] inline: rogue function call [from revision 46893]
[FIX] inline: leave out empty params (parser artifacts - needs fixing in parser) [from revision 46896]
[REF] More ajax preview function into the edit service, and finally remove tiki-auto_save.php [from revision 46902]
[FIX] inline: Partial revert of r46868 & 71 - rendering plugins for viewing and inline editing at the same time doesn't work with nested plugins.
Need to go back to a server-side re-parsing for inline editing with complicated plugin content (somehow) [from revision 46909]
[MOD] inline: Change inline editing switch from totally client-side to ajax calls [from revision 46911]