Last modified: 2014-11-20 09:14:00 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 14261 - Extension can't pass error information back to user in API call (tracking)
Extension can't pass error information back to user in API call (tracking)
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
1.13.x
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
: tracking
: 35331 (view as bug list)
Depends on: 22922 35300 20524 22226 29261
Blocks: tracking 61736 14210 35331
  Show dependency treegraph
 
Reported: 2008-05-25 17:36 UTC by Max Semenik
Modified: 2014-11-20 09:14 UTC (History)
10 users (show)

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


Attachments

Description Max Semenik 2008-05-25 17:36:24 UTC
I'd like to know the reason why the action was aborted, because different reasons for abort mean different strategies to fix that. For example, if action=edit was aborted due to spam blacklist hit (less frequent nowadays after it had been tweaked, but still possible), the bots should skip that page, but if it was aborted due to assert=user, the bot should relogin and try to edit again.
Comment 1 Roan Kattouw 2008-05-27 14:43:04 UTC
This was fixed for action=move in r35393
Comment 2 Marco 2008-07-28 10:47:13 UTC
have you a link for assert=user ready?
Comment 3 Roan Kattouw 2008-08-26 11:42:38 UTC
(In reply to comment #0)
> I'd like to know the reason why the action was aborted, because different
> reasons for abort mean different strategies to fix that. For example, if
> action=edit was aborted due to spam blacklist hit (less frequent nowadays after
> it had been tweaked, but still possible), the bots should skip that page, but
> if it was aborted due to assert=user, the bot should relogin and try to edit
> again.
> 

This is because these extensions use the "old" EditPage hooks that allow for adding HTML to the edit form, but lack a mechanism to communicate with the API (simply because those hooks were created when the API didn't even exist). All extensions should use the new APIEditBeforeSave hook to handle API edits, but only one (ConfirmEdit) does that so far. I'll convert the other extensions enabled on Wikipedia to use APIEditBeforeSave as well. Meanwhile, you can check whether assert=user triggered the hookaborted error with api.php?action=query&meta=userinfo
Comment 4 Roan Kattouw 2008-10-09 21:03:57 UTC
Closing this bug as WORKSFORME since there's a clear solution already: extensions should migrate to the APIEditBeforeSave hook if they want to provide the API with useful information.
Comment 5 Max Semenik 2008-10-10 16:53:05 UTC
The problem remains: I can't use write API on Wikimedia wikis until I get a clear indication of what went wrong in EACH and EVERY situation, regardless of what failed, the core or an extension - this bug could be turned into a tracking bug, if you like, but simply closing it makes no sense.
Comment 6 Roan Kattouw 2008-10-13 17:27:38 UTC
(In reply to comment #5)
> The problem remains: I can't use write API on Wikimedia wikis until I get a
> clear indication of what went wrong in EACH and EVERY situation, regardless of
> what failed, the core or an extension - this bug could be turned into a
> tracking bug, if you like, but simply closing it makes no sense.
> 

If you want this bug to be a tracking bug, then reopen it, change its summary, and file at least one bug to be tracked by it (preferably a bug complaining about a specific extension's ignorance of the APIEditBeforeSave hook).
Comment 7 Marcin Cieślak 2010-01-22 02:38:34 UTC
One example of extension that fails with API edit for me is AntiBot (pretty generic MediaWiki installation, now at r61343). I have described this under bug 22226. In this case I was lucky enough I could enable debug log and trace the problem down.

There are, however, some reports like this pywikipedia bug http://sourceforge.net/tracker/index.php?func=detail&aid=2892593&group_id=93107&atid=603138 where it is difficult for the requester to track down the problem; as this concerns a Wikimedia wiki.

Maybe wfRunHooks could report names of extensions that fail? Or maybe hooks (and their documentation!) should be re-engineered to provide clear indication whether they are being called on API or during interactive use? 

For example EditFilter/EditFilter hooks provide a whole EditPage instance, that - in case of API edit - may be different than the typical object instance.
Comment 8 Sam Reed (reedy) 2011-02-09 15:19:24 UTC
Triggering the AbuseFilter also provides a non descriptive "hookaborted" error back to the api whilst editing
Comment 9 Mark A. Hershberger 2012-03-19 20:43:27 UTC
*** Bug 35331 has been marked as a duplicate of this bug. ***
Comment 10 Niklas Laxström 2012-05-29 12:52:44 UTC
Roan did https://gerrit.wikimedia.org/r/#/c/7154/ but we are also using EditFilterMerged hook which gets executed before ArticleSave, we still get hookaborted error because errors from that hook are not propagated.
Comment 11 Niklas Laxström 2012-05-29 12:53:54 UTC
Above comment was meant for bug 29261. But the problem is that EditFilterMerged has the same issue which was fixed for ArticleSave.

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


Navigation
Links