Page MenuHomePhabricator

RFC: More flexible and modernized ChangesList formatting for Recent Changes
Closed, ResolvedPublic



The list of changes on the Special:Recentchanges, Special:Watchlist and Special:RecentChangesLinked ("Related changes") are formatted using the ChangesList class or derivatives of it.

There are several formats for ChangesList, including OldChangesList, EnhancedChangesList, as well, as CleanChanges provided by an extension and perhaps others. ChangesList generally take a list or RecentChange records and one-by-one format them in a standard way, with special casing for log entries.


The current system for formatting recent changes is not flexible for integrating new types of changes, such as Wikibase or Flow entries. Integrating with the "Enhanced Changes" format is especially problematic, as we need to integrate with how it groups the changes as well as formatting of various bits in the change lines.

For the OldChangesList, there is a hook for each change line, at the end, after formatting it in the standard way, where extensions can modify it or replace it. There is no equivalent hook for EnhancedChanges, or for handling the grouping. Flow developers did introduce some new hooks for modifying some of pieces of the EnhancedChangesLine, but not sure they are sufficient or so nice.

Integrating and showing Wikidata changes relevant to a Wikipedia (or other client wiki) page in the Enhanced Changes format has been blocked on some of these issues. We currenlty only show related Wikidata changes in the "OldChangesList" format.

"OldChangesList" format is the default for Wikimedia wikis, but "EnhancedChangesList" is now the default in MediaWiki. There is some interest in making EnhancedChangesList the default also for Wikimedia wikis, and it is widely used already as a preference. There is some hesitation to change the default whilst Wikidata changes are not integrated into the EnhancedChangesList format.


ChangeLine formatting

In general, "ChangesList" and derived classes do a lot more than just handle formatting of a list of RecentChanges, but also handles line-by-line formatting, when really these responsibilities should be split up.

Instead, I propose there to be a ChangeLineFormatter interface and implementations based on rc_source types. rc_source is a newish column added to the recentchanges table, which is intended to replace rc_type. rc_source allows specifying the type of change, such as 'mw.edit', 'mw.log', '' for core RecentChange types and 'wb' and 'flow' provided by extensions.

This could be done by registering formatting callbacks or formatter classes per source type. If a formatter is not registered, then the default formatting (e.g. current stuff) can be applied.

To ensure consistent formatting in these formatters, the formatting code in the ChangesList class needs to be split out into a utility class that is not an abstract class, as it doesn't make sense for the formatters to be subclasses of ChangesList.

RecentChange class

The RecentChange class also has a mix of functionality, including being a factory and a data access layer (for saving and retrieving from the db) and also is a value object. It would be helpful, for more testability and ease of use, to also split these three things up.

See also - related extensions:

Related RFCs:

At the summit, I would like to discuss the issues generally of how we want to modernize the recent changes system and get further feedback on any implementation proposals.

At the moment, I propose just to try to improve the backend code for formatting the existing ChangesLists formats that we have and not make too many or any user-facing changes.

Should we be inclined to make any substantial user-facing changes, then we would need a bit more input and consensus from the community, and discussion on how to go about introducing such change. (e.g. introduce a super enhanced awesome format that people opt into, and then eventually make it default and then eventually drop one of the other formats?)

Status of the RFC:

based on previous RFC discussions, I think there is some consensus but we need a more detailed proposed implementation now,and in doing so more issues and questions may come up.

Event Timeline

aude raised the priority of this task from to Medium.
aude updated the task description. (Show Details)
aude added a subscriber: aude.
aude set Security to None.

T592 was the initial RFC about specifically having formatters for each rc_source type.

I want to move this forward and work on implementation, and also consider how the RecentChange system works on a broader level and how we might want it to be in the future in order to be more flexible and modern.

aude renamed this task from More flexible and modernized Recent Changes formatting code to More flexible and modernized Recent Changes code.Oct 2 2015, 10:30 AM
aude edited projects, added Wikimedia-Developer-Summit-2016; removed Proposal.
aude added a project: Wikidata.
aude updated the task description. (Show Details)
aude added subscribers: daniel, Addshore, matmarex.
aude updated the task description. (Show Details)

Congratulations! This is one of the 52 proposals that made it through the first deadline of the Wikimedia-Developer-Summit-2016 selection process. Please pay attention to the next one: > By 6 Nov 2015, all Summit proposals must have active discussions and a Summit plan documented in the description. Proposals not reaching this critical mass can continue at their own path out of the Summit.

Discussed this briefly with James F. and it's something to coordinate with his team, at the least. The inflexibility and issues with the recent changes code is problematic for development of both Flow and Wikidata, among other things that people want.

Discussed this briefly with James F. and it's something to coordinate with his team, at the least.

@Jdforrester-WMF, could that team (or whoever needs to be involved in this discussion) be subscribed here?

There is some related high-level discussion about recent changes and page history as event streams in T107595. One idea is to layer event streams, which would potentially let us integrate related events like edits to corresponding Wikidata items.

@aude: Which questions would you like to resolve at the summit? Do you think this topic could also be reasonably discussed in a regular RFC meeting?

Wikimedia Developer Summit 2016 ended two weeks ago. This task is still open. If the session in this task took place, please make sure 1) that the session Etherpad notes are linked from this task, 2) that followup tasks for any actions identified have been created and linked from this task, 3) to change the status of this task to "resolved". If this session did not take place, change the task status to "declined". If this task itself has become a well-defined action which is not finished yet, drag and drop this task into the "Work continues after Summit" column on the project workboard. Thank you for your help!

the topic was discussed as part of T122813 and work should continue

Although the focus of rMWaa063f4c5a19: Back-end of new RecentChanges page, refactoring was the filter system, there was some overlap at the edges, regarding isRowApplicableCallable/applyCssClassIfNeeded (the latter affected the formatters).

Addshore updated the task description. (Show Details)
Krinkle renamed this task from More flexible and modernized Recent Changes code to RFC: More flexible and modernized ChangesList formatting for Recent Changes.Jan 26 2019, 6:53 AM
Krinkle closed this task as Resolved.
Krinkle updated the task description. (Show Details)
Krinkle moved this task from Untriaged to Implemented on the TechCom-RFC (TechCom-RFC-Closed) board.
Krinkle removed a subscriber: wikibugs-l-list.
Krinkle added a subscriber: Krinkle.
In T592#9728, @Qgil wrote:

approved by consensus -> kick back to aude for implementation