Last modified: 2013-01-15 22:38:24 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T9851, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 7851 - Proper ajax patrolling functionality in core
Proper ajax patrolling functionality in core
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Patrolling (Other open bugs)
unspecified
All All
: High enhancement with 9 votes (vote)
: 1.21.0 release
Assigned To: Marius Hoch
:
: 11002 18191 20422 (view as bug list)
Depends on:
Blocks: ajax
  Show dependency treegraph
 
Reported: 2006-11-09 11:25 UTC by Martin Manscher
Modified: 2013-01-15 22:38 UTC (History)
12 users (show)

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


Attachments

Description Martin Manscher 2006-11-09 11:25:38 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.
Comment 1 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-11-09 22:22:28 UTC
[[Ajax]] would be good for this.
Comment 2 Rob Church 2006-11-09 22:58:23 UTC
Just use the Patroller extension. AJAX does not make the world go 'round.
Comment 3 Aaron Schulz 2008-08-03 19:37:16 UTC
*** Bug 11002 has been marked as a duplicate of this bug. ***
Comment 4 Mike.lifeguard 2008-10-21 20:42:39 UTC
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.
Comment 5 Melancholie 2009-03-27 04:36:36 UTC
*** Bug 18191 has been marked as a duplicate of this bug. ***
Comment 6 Alexandre Emsenhuber [IAlex] 2009-08-27 14:49:26 UTC
*** Bug 20422 has been marked as a duplicate of this bug. ***
Comment 7 Krinkle 2010-11-16 20:49:41 UTC
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).
Comment 8 Krinkle 2011-02-24 12:30:06 UTC
(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
Comment 9 Bawolff (Brian Wolff) 2011-02-25 17:37:10 UTC
>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).
Comment 10 Krinkle 2011-03-09 00:48:27 UTC
(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.
Comment 11 Helder 2011-09-29 21:40:04 UTC
(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?
Comment 12 Marius Hoch 2012-10-03 01:47:13 UTC
Done in Gerrit change #26440

Waiting for review...
Comment 13 Nemo 2012-11-08 21:53:53 UTC
(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?
Comment 14 Marius Hoch 2012-11-08 22:11:14 UTC
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).
Comment 15 Krinkle 2012-11-13 23:57:21 UTC
Change-Id: I472357566dda0ab572c20e2e4b87508b0f2f4c73

Merged.
Comment 16 Nemo 2013-01-15 22:38:24 UTC
Note that an additional core AJAX patrol feature on RecentChanges itself could also be a workaround for bug 8697 comment 12.

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


Navigation
Links