Author: martinmanscher
Description:
It would be nice to be able to mark an edit patrolled without receiving the
confirmation - this way one could work faster partrolling edits, and/or not
having to open the "mark as patrolled" link in a new tab, which needs to be
closed later.
Version: unspecified
Severity: enhancement
robchur wrote:
Just use the Patroller extension. AJAX does not make the world go 'round.
mike.lifeguard+bugs wrote:
This doesn't depend on bug 11002 - it's a duplicate.
(In reply to comment #2)
Just use the Patroller extension. AJAX does not make the world go 'round.
Then why don't we use the patroller extension? I actually think it's not better than our current system; this is simply a request to improve the interface.
Wiki.Melancholie wrote:
*** Bug 18191 has been marked as a duplicate of this bug. ***
I've ported a gadget on the English Wikipedia for new page patrol to a more general script that works on any wiki (not just en.wikipedia) and works for edit-patrol aswell:
http://meta.wikimedia.org/wiki/User:Krinkle/Scripts/AjaxPatrolLinks
Can be put in userscript, gadget or sitewide Commons.js of a wiki.
Should work on non-WMF wikis aswell.
Could be used as a base if and when this comes to core. It's just a few lines of javascript really.
Could be made even shorter with jQuery (will do that soon).
(In reply to comment #7)
I've ported a gadget on the English Wikipedia for new page patrol to a more
general script that works on any wiki (not just en.wikipedia) and works for
edit-patrol aswell:
http://meta.wikimedia.org/wiki/User:Krinkle/Scripts/AjaxPatrolLinks
Can be put in userscript, gadget or sitewide Commons.js of a wiki.
Should work on non-WMF wikis aswell.Could be used as a base if and when this comes to core. It's just a few lines
of javascript really.
Could be made even shorter with jQuery (will do that soon).
Done that a few weeks ago.
This script (and many others like it) float around on 100s of wikis. The thing they have in common is that they turn the index.php call into an ajax request and if it has code 200 they indicate in the link that it's succeeded.
In the coming weeks I'll work in a script to do this through the api instead.
We can't do an index.php ajax call in the core imho, to save resources (since calling index.php will return the entire HTML page with all the messages, preferences etc. on it – all redundant stuff not used and wasting processing time).
It will also be faster for the client (since index.php takes longer to load and returns more data) and allows for better error reporting as well (depending on the status code is not reliable since a 'patrol error page' is (and should be) also code 200.
Some of the ajax patrol scripts out there look through the returned HTML to see if it cointains certain words to indicate succesful/error state but this is both language dependant and prone to breakage whenever those messages are changed (either by the software or by the local wiki).
When this script is ready and tested as a gadget I'll most likely add it to core as a preference (to acompany "preview.js" / livepreview).
Krinkle
When this script is ready and tested as a gadget I'll most likely add it to
core as a preference (to acompany "preview.js" / livepreview).
Why as a preference? As long as it degrades gracefully for text browsers and weird people who don't like js, I can't imagine anyone wouldn't want this. We don't have a preference for the ajax watch feature (afaik).
(In reply to comment #9)
When this script is ready and tested as a gadget I'll most likely add it to
core as a preference (to acompany "preview.js" / livepreview).Why as a preference? As long as it degrades gracefully for text browsers and
weird people who don't like js, I can't imagine anyone wouldn't want this. We
don't have a preference for the ajax watch feature (afaik).
Sure, sounds good. But only when it uses the API and has proper (internationalized) error reporting. Else it would be a regression.
So far I haven't found any existing ajax patrol script that does this "The Right Way", so I'll write it myself.
(In reply to comment #10)
So far I haven't found any existing ajax patrol script that does this "The
Right Way", so I'll write it myself.
Any progress on this?
(In reply to comment #12)
Done in Gerrit change #26440
Waiting for review...
Wonderful! This is something MediaWiki needs so badly, quite unbelievable that we still don't have it.
Does you patch include both diff and new page patrol? Is the patrol AJAXy feature displayed in any other place?
It indeed includes both new page and diff patrol.
It basically works on top of all "old" patrol links as it's invoked every time those are created (happens in includes/Article.php and includes/diff/DifferenceEngine.php).
Note that an additional core AJAX patrol feature on RecentChanges itself could also be a workaround for bug 8697 comment 12.