Page MenuHomePhabricator

action=query&list=usercontribs seems to ignore edits to the Topic namespace
Closed, DuplicatePublic

Description

I replied to some Flow topic and then ran a usercontribs query with my own name:
https://www.mediawiki.org/w/api.php?action=query&list=usercontribs&format=json&ucuser=Amire80

I saw other edits made before and after the Flow edits, but not the flow edits themselves.

If I explicitly request the topic namespace, I don't see anything at all:
https://www.mediawiki.org/w/api.php?action=query&list=usercontribs&format=json&ucuser=Amire80&ucnamespace=2600

Is this by design? If it is, then it's strange, because the usual Special:Contributions page does show Flow edits.

Event Timeline

Amire80 raised the priority of this task from to Needs Triage.
Amire80 updated the task description. (Show Details)
Amire80 added subscribers: Amire80, Anomie, EBernhardson, IKhitron.

Flow is using hooks to inject extra revisions into Special:Contributions, but as far as I can tell did not consider API list=usercontribs.

This is because core does not have any standardized data access, every bit of code that talks to the database just invents its own way. Rather than having a single data model that both the API and on page contributions talk to, each of them do their own database queries. It would make a lot of sense for two parts of the website that output the same basic information to use the same code, but sadly this is not the case in mediawiki.

The first steps of making this possible, adding a templating language to mediawiki and doing a separation of the query logic and the display logic is starting, but it will be a long and hard path. I'm personally a fan of rejigging things such that pages like Special:Contributions query the api rather than do their own query logic. This was discussed a bit at one of the previous RFC's but is still up in the air as we all negotiate over where the correct points of integration are (special page calls api, or api and special page use a shared php class for collecting the information).

Rather than having a single data model that both the API and on page contributions talk to,

Well, there used to be a single data model: SQL database tables. Then people decided they didn't like the existing structure, and added hooks to Special:Contributions to inject their own different stuff on top of the existing structure instead of adding an abstraction layer then.

or api and special page use a shared php class for collecting the information).

That, not the other.

I personally find it crazy that sql is considered the right level of abstraction for serving the exact same information over multiple channels, it all but ensures that code is duplicated in multiple places. But as with all things, intelligent people can disagree.

As to the api vs shared php classes, I also personally find that if we actually want to ensure the same functionality is available over both the API and the standard pages, having the standard page use the API is a great way to accomplish this. It provides not just a hope, but a guarantee that whatever is done in the web interface is doable via the api without duplicating any code.