Author: wikimedia.org
Description:
When you are using Live Preview, the preview of the edit summary doesn't reload along with the page - you have to do a normal, non-live preview for that
(and there is no way to do a page-reloading preview without unsetting that prefrence checkbox anyway).
Version: 1.11.x
Severity: normal
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T41272 Bugs in "Live preview" feature (tracking) | |||
| Resolved | None | T10618 Live Preview doesn't reload Edit Summary preview; no way to use standard preview when Live Preview is enabled |
MediaWiki wrote:
I can confirm this from my own installation of MW 1.11.0. The Live Preview function only updates the page content. Also, the ability to use standard preview when Live Preview is enabled would be a good thing to have.
In my opinion Live preview should be moved to an extensions or removed altogether. It just cannot work properly with the current state of technology and MediaWiki code.
MediaWiki wrote:
In my experiences with Live Preview, it renders things quite well, just like the normal preview would. I don't think it should be enabled by default, by any means, but moving it to an extension would be removing functionality that needs only a few small improvements. The Ajax Watch script wasn't really working well in version 1.9, but it's become the default to "on" in version 1.11. Another script that nobody really knew much about until a Bugzilla discussion decided to fix it up and make it work.
(In reply to comment #3)
"current state of technology"? elaborate?
I agree; what "current state of technology"?
I don't think it should be enabled by default, by any
means, but moving it to an extension would be removing functionality that needs
only a few small improvements. The Ajax Watch script wasn't really working well
in version 1.9, but it's become the default to "on" in version 1.11. Another
script that nobody really knew much about until a Bugzilla discussion decided
to fix it up and make it work.
I disagree. The improvements are not few and small but quite big. First of them being working back button and otherwise consistent browser behavior with normal preview. As far as I know there is no easy way to accomplish this without pulling in some JavaScript toolkits.
Second improvement would be identical behavior compared to preview, which means that categories, edit summary previews, language links etc are all updated on preview. This is impossible without altering the skins and other code.
MediaWiki wrote:
(In reply to comment #5)
I disagree. The improvements are not few and small but quite big. First of them
being working back button and otherwise consistent browser behavior with normal
preview. As far as I know there is no easy way to accomplish this without
pulling in some JavaScript toolkits.Second improvement would be identical behavior compared to preview, which means
that categories, edit summary previews, language links etc are all updated on
preview. This is impossible without altering the skins and other code.
Why would we need identical behavior to the standard preview? Most modern browsers keep an undo history for each textbox/textarea, and the user could step back and forth in this, clicking preview if desired, to look at previous versions of their edits. And why would we need that? Going back to a previous version of a page, making edits, and standard previewing that page erases all future versions from the browser's cache; using one page with Live Preview keeps the browser undo history all nicely bundled on one page, uninterrupted. It should make it easier to undo things, because users won't need the back button.
Another idea is to have a second, small button that calls a normal preview (created by the Live Preview JS, say, only if that script can function, since browsers that don't support LP fall back to normal anyway). That button could be labeled "View final" or something, and would display a preview that has all changes, including language links. Returning categories is something that needs to be added to the server-side code, to render the box and its links below the main content. Language links and edit summary preview need the script to update multiple divs with different sections of the data. It can be done. If Gmail and Yahoo! Mail beta can use AJAX the way they do, MediaWiki can definitely pull off this Live Preview thing.
PS
enwiki's wikEd editing tool by Cacycle has a good preview algorithm we could start with, and maybe use the diff script, too, since it's easier to read.