Last modified: 2014-11-20 09:14:00 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.
This was fixed for action=move in r35393
have you a link for assert=user ready?
(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
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.
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.
(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).
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.
Triggering the AbuseFilter also provides a non descriptive "hookaborted" error back to the api whilst editing
*** Bug 35331 has been marked as a duplicate of this bug. ***
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.
Above comment was meant for bug 29261. But the problem is that EditFilterMerged has the same issue which was fixed for ArticleSave.
