Page MenuHomePhabricator

Support Flow changes in Usercontribs API
Open, LowPublic

Description

Compare https://www.mediawiki.org/w/api.php?action=query&list=usercontribs&ucuser=Mattflaschen%20%28WMF%29 to https://www.mediawiki.org/wiki/Special:Contributions/Mattflaschen_%28WMF%29 . See https://www.mediawiki.org/wiki/API:Usercontribs (User contributions API).

ApiQueryUserContributions does its own DB lookups, using the ApiQueryBase infrastructure.

It doesn't call any hooks directly, which is probably why it's not picking up our ContribsPager::reallyDoQuery listener.

This looks like it will either require adding new hooks, or refactoring ApiQueryUserContributions to share code with Special:Contributions.

See also T104083: Include Flow revisions in RecentChanges API.

Event Timeline

Mattflaschen-WMF raised the priority of this task from to Low.
Mattflaschen-WMF updated the task description. (Show Details)
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 5 2015, 10:45 PM
Mattflaschen-WMF set Security to None.

Copied from T93873: action=query&list=usercontribs seems to ignore edits to the Topic namespace:

@EBernhardson:

"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)."

@Anomie wrote:

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.

@EBernhardson wrote:

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.

@EBernhardson wrote:
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.

The consensus seems pretty clearly against that though. For core at least (e.g. this problem) we should probably implement some kind of PHP service/backend controller (people have different terms, basically the place where the database work and logic is done) that both API and Special:Contributions use.

I don't think @Anomie was saying SQL was the right level of abstraction. He said "That, not the other", which I believe means he supports the shared PHP service approach.

I think he was just explaining how we ended up in this boat.

In T88753#1150326, @Mattflaschen wrote:

I don't think @Anomie was saying SQL was the right level of abstraction.

Yeah. SQL was a good level of abstraction when all the contributions were in the 'revision' table, but the ship has sailed on storing Flow information in there.

So now that Flow needs to mix in contributions from its own tables, we need a higher layer of abstraction to do it right, rather than hooks in Special:Contributions that we have now. Which will take someone investigating the requirements of both the special page and the API to design the right interface.

-jem- added a subscriber: -jem-.Jul 13 2015, 11:19 AM
Sitic added a subscriber: Sitic.Aug 4 2015, 12:29 AM
Elitre added a subscriber: Elitre.Jul 25 2017, 9:34 AM
Restricted Application added a project: Growth-Team. · View Herald TranscriptJul 18 2018, 6:56 PM
SBisson moved this task from Inbox to Triaged but Future on the Growth-Team board.Jul 20 2018, 5:52 PM