Background
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.
Problem
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.
More generally, "ChangesList" does 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.
Proposal
//Formatters for rc_source types//
The recentchanges table now has a newish column, rc_source, which allows specifying the type of change and for more flexible for specifying different types of RecentChange entries. For example, 'mw.edit', 'mw.log', 'mw.new' for core RecentChange types and 'wb' and 'flow' provided by extensions.ChangeLine formatting
A more flexible approach would be to define ChangeLineFormatter interface and allow registering ChangeLineFormatter implementations for each rc_source 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. This could be done by registering formatting callbacks or formatter classes per source type.rc_source allows specifying the type of change, If a formatter is not registeredsuch as 'mw.edit', then the default formatting (e.g.'mw.log', current stuff) can be applied'mw.new' for core RecentChange types and 'wb' and 'flow' provided by extensions.
//ChangesListFormatter//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:
- https://github.com/wikimedia/mediawiki-extensions-CleanChanges
- https://github.com/svn2github/wikia/tree/master/extensions/uniwiki/FormatChanges
- https://github.com/wikimedia/mediawiki-extensions-SimpleChanges
- https://github.com/wikimedia/mediawiki-extensions-RecentActivityFeed
Related RFCs:
- https://www.mediawiki.org/wiki/Requests_for_comment/Linker_refactor
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.