... to implement something akin to [[Special:RelatedChanges]].
Version: 1.21.x
Severity: enhancement
Description
Description
Details
Details
- Reference
- bz15552
Related Objects
Related Objects
- Mentioned In
- T57377: API: Implement rctitles parameter in query=recentchanges
T121468: Should be able to generate watchlist like results for a generator - Mentioned Here
- T57377: API: Implement rctitles parameter in query=recentchanges
T121468: Should be able to generate watchlist like results for a generator
Event Timeline
Comment Actions
Probably best to support titles= as well as rctitles= so [[Special:Recentchangeslinked]] can be emulated with a generator.
Comment Actions
Closing as "resolved/later"
Will be fixed by bug 14869, and makes the API bug list a bit clearer (as these are essentially duplicates)
Comment Actions
(In reply to comment #4)
RecentChanges is not a QueryPage based special page, right?
That's right and neither is RelatedChanges/RecentChangesLinked. Reopening.
Comment Actions
silas.ropac wrote:
I would like to see this. As a new user the very first thing I wanted to do with the API was get related changes for a page. Maybe there is a workaround today? But would be nice to do it directly with one call.
Comment Actions
shreeshikha21 wrote:
I am new to FOSS and mediawiki how do I start on this bug and how do I replicate the error on my local machine.
Comment Actions
@MZMcBride: Could you provide some implementation pointers for a new contributor who'd like to give this task a try?
I guess mw:API:Query + mw:API:RecentChanges + core/includes/specials/SpecialRecentchangeslinked.php are relevant, but is there any info on adding additional parameters to the codebase?
(Looks like there are no tests for RecentChanges under core/tests/phpunit/includes/api/?)
Comment Actions
Note that T57377 and T121468 are very similar tasks, if not quite duplicates.
The original idea here, to add rctitles, is fairly straightforward and could probably be done without a whole lot of trouble.
The second idea, to have it use titles instead (and be able to take input from a generator), is less straightforward but still should be doable. In that case, you'd need to either make ApiRecentChanges into a prop module rather than a list module (breaking existing clients) or add a "prop" version of recentchanges with a different name to be used for this functionality, much like the situation between list=backlinks|embeddedin|imageusage and prop=linkshere|transcludedin|fileusage.
In either case, it'll take some examination of the resulting database queries to make sure that they're at least not worse-performing than the queries for list=watchlist.
Comment Actions
@MER-C Wondering if this task is too simple, we reserve it for new contributors and not for the developer wishlist? any thoughts?
Comment Actions
If that were so, someone would have picked this task off in the preceding nine years. Either way, "recommended for volunteer developers" and "in the developer wishlist" are not mutually exclusive, they are complementary; just like in the Community Wishlist survey.
Comment Actions
This proposal is selected for the Developer-Wishlist voting round and will be added to a MediaWiki page very soon. To the subscribers, or proposer of this task: please help modify the task description: add a brief summary (10-12 lines) of the problem that this proposal raises, topics discussed in the comments, and a proposed solution (if there is any yet). Remember to add a header with a title "Description," to your content. Please do so before February 5th, 12:00 pm UTC.
Comment Actions
Hello team!
I started researching how api "recentchanges" works and where to add the "rcrelated" parameter.
As a result, I didn't found an implementation for "Special: RelatedChanges / Special: RecentChangesLinked" that should be connected.
Therefore, I wanted to clarify with you a scope of work on this task.
As I understand well I need to add the "rcrelated" parameter, to be supported by API. So in future when "Special: RelatedChanges / Special: RecentChangesLinked" will be implementing they will already have required API?
Looking forward to a reply.
Thank you.
Comment Actions
Hi @RussRogovetz! API / special page logic is often duplicated, in part because it's old code and MediaWiki had lower code quality standards back then, in part because the API's batching behavior can make the requirements significantly different. So you won't be able to reuse the SpecialRecentChangesLinked class directly in ApiQueryRecentChanges - you'd have to figure out how the database query it generates differs from SpecialRecentChanges, and add the same logic to the API.
I think marking this as an easy task was a bit optimistic - it's probably a small task in terms of lines of code that need to be changed, but that doesn't mean it's easy to figure out what those changes are.