Last modified: 2013-01-15 22:38:24 UTC
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.
[[Ajax]] would be good for this.
Just use the Patroller extension. AJAX does not make the world go 'round.
*** Bug 11002 has been marked as a duplicate of this bug. ***
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.
*** Bug 18191 has been marked as a duplicate of this bug. ***
*** Bug 20422 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?
Done in Gerrit change #26440 Waiting for review...
(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).
Change-Id: I472357566dda0ab572c20e2e4b87508b0f2f4c73 Merged.
Note that an additional core AJAX patrol feature on RecentChanges itself could also be a workaround for bug 8697 comment 12.
