Page MenuHomePhabricator

Per-edit suppression of "preview-on-first-edit" preference
Closed, ResolvedPublic


We have a feature right now, where by adding redirect=no to the full url of a page, a redirect is prevented and we see the redirect page itself, rather than the destination.

I want to request a similar feature: preview=no

This is because I usually set mediawiki to show the previews on first edit. However, on some situations (trying to add something to the end of a long page with no sections) I prefer the preview not to be shown. These are rare exceptions, so it wouldn't be ok with me to change and rechange my preferences. If a preview=no feature would be added, I could have a piece of code in my monobook.js file, adding a link to the caption of the pages to edit them without preview. :)

I understand I'm asking a not-so-important feature, but I would be grateful if it would be implemented some day.


Version: unspecified
Severity: enhancement



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:43 PM
bzimport set Reference to bz9936.
bzimport added a subscriber: Unknown Object (MLST).

Created attachment 3848
Patch which enables the required feature

I created this patch and tested it on my local wiki. It is working as desired. I hope you apply it with no issues.

attachment diff.diff ignored as obsolete

ayg wrote:

Wouldn't it make more sense to allow the preview parameter to have either "no" or "yes", overriding the preference either way rather than only one way?

Also, use $wgRequest (the global WebRequest object) to obtain request parameters. This handles things like magic quotes cleaning, etc., in a nice and consistent manner.

Created attachment 3850
Second patch, which applies Simetrial suggestions

I created this new patch, which applies your suggestions, i.e. it understand preview="yes" in the url, and uses $wgRequest to get the url parameters.

attachment Diff.diff ignored as obsolete

Created attachment 3852
Recoding the same thing

This newer patch, created with regard to Simetrical's comments on IRC, makes the code easier to read.


ayg wrote:

That looks good. The only concern I have is whether we want to add secret URL parameters that can't be accessed through the interface. Maybe a "hide preview" button at the top if the preview is displayed. Although it would probably be expected to preserve whatever was entered into forms, too, which would be marginally trickier without just deleting the preview via JS. But I guess this is okay as a first step, assuming it works (haven't tested it but don't see why it wouldn't).

Simetrical, I look into it from two points of view:

  1. Documentation: This feature should be mentioned in the documentation. I'm just looking to find similar items on MediaWiki web site, so I can modify/add the required page with respect to the available practice.
  1. User interface: I cannot find a place in user interface which is logically suitable for adding a link/checkbox for using this feature. This is a per-preview feature, and the only use of it, as far as I understand, is when someone has enabled preview on load, but wants it to be off on rare ocasions. Perhaps someone may add an item for himself to the page captions using user js, with a link to edit with no preview (I will do myself, as soon as this feature is enabled) but this is not what every body wants to use, so I see no point in showing this option to every one. That is my point of view though.

So all in all, is this patch going to be implemented, or do we have to make more considerations about it?

ayg wrote:

Brion said, "I don't see much purpose in it. Yet another magic parameter... :P"

I emailed Brion but he has probably forgotten to reply to me. I said "Setting up that new feature takes only a second... You can see there is at list one good reason for doing so... I afforded to describe the feature on appropriate place on Meta and/or web sites, so it doesn't remain a hidden magic parameter..."

I still cannot understand why we should avoid setting up this new faeture. Others' may have useful comments in this regard.

ayg wrote:

Adding features that only a couple of people want is bad in the long term. It leads to too many features that nobody uses or has heard of, and consequently nobody maintains, which may duplicate functionality in some way, etc. Secret options are also bad, they should be accessible through the interface. Simplicity is often a virtue. If you had a button at the top of the screen saying "Hide preview" that's a patch worth considering.

Simetrical, thank you for your comment. I don't fully understand what that button should look like. Do you mean adding a new item to the page caption (for example next to the Edit this page link) which leads to the edit page without a preview?

I don't think that dismissing the preview after it's shown really is in the spirit of the request. You still have to sit there while it renders, downloads, and shows on screen, and then hide it?

The point, presumably, is to not have to sit through it in the first place. It's too late to dismiss it once shown.

I agree with Brion here. All in all, if you think this feature is not necessary, we can close this as a WONTFIX or something.

robchur wrote:

Fixed in r23972; use "preview=no" or "preview=yes" as desired.