Last modified: 2007-07-11 06:08:18 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 9936 - Per-edit suppression of "preview-on-first-edit" preference
Per-edit suppression of "preview-on-first-edit" preference
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-05-17 14:17 UTC by Huji
Modified: 2007-07-11 06:08 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Patch which enables the required feature (496 bytes, patch)
2007-06-29 17:01 UTC, Huji
Details
Second patch, which applies Simetrial suggestions (879 bytes, patch)
2007-06-29 18:10 UTC, Huji
Details
Recoding the same thing (529 bytes, patch)
2007-06-29 18:26 UTC, Huji
Details

Description Huji 2007-05-17 14:17:20 UTC
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.

Thanks
Comment 1 Huji 2007-06-29 17:01:01 UTC
Created attachment 3848 [details]
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.
Comment 2 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-29 17:22:07 UTC
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.
Comment 3 Huji 2007-06-29 18:10:27 UTC
Created attachment 3850 [details]
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.
Comment 4 Huji 2007-06-29 18:26:56 UTC
Created attachment 3852 [details]
Recoding the same thing

This newer patch, created with regard to Simetrical's comments on IRC, makes the code easier to read.
Comment 5 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-29 20:32:31 UTC
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).
Comment 6 Huji 2007-06-30 03:19:01 UTC
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.

2) 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.
Comment 7 Huji 2007-07-01 15:05:38 UTC
So all in all, is this patch going to be implemented, or do we have to make more considerations about it?
Comment 8 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-03 03:01:50 UTC
Brion said, "I don't see much purpose in it.  Yet another magic parameter... :P"
Comment 9 Huji 2007-07-05 13:10:27 UTC
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 MediaWiki.org 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.
Comment 10 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-05 19:37:54 UTC
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.
Comment 11 Huji 2007-07-10 12:14:37 UTC
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?
Comment 12 Brion Vibber 2007-07-10 17:27:59 UTC
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.
Comment 13 Huji 2007-07-10 18:02:48 UTC
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.
Comment 14 Rob Church 2007-07-10 19:23:45 UTC
Fixed in r23972; use "preview=no" or "preview=yes" as desired.
Comment 15 Huji 2007-07-11 06:08:18 UTC
Thank you.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links