Forked from T132467#2674866:
>>! In T132467#2674866, @Jonesey95 wrote:
> This is a long-standing problem. See T69419 and [[ https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/Archive_128#Recategorizing_articles_when_templates_are_changed_is_taking_about_90_days_currently | this discussion from 2014]].
>
> Here's another example: I created "Category:Pages using invalid self-closed HTML tags" on 14 July 2016 on en.WP after a change to MW started adding a hidden category to articles with a specific kind of HTML error. As of today, 28 Sep 2016, there are pages on en.WP such as "Portal:East Frisia/Region" that have the error in their code and will properly appear in the category after a null edit, but that have not yet shown up in the category on their own.
>
> That means that fundamentally, categories are not being applied to articles in a timely fashion until those articles are edited. By any measure, taking more than two months to properly apply maintenance categories to pages is a bug that needs to be fixed.
>
> Is there some way that we can force all pages to be null-edited (or the equivalent) with a reasonable frequency? It is not happening right now.
>
> [edited to add:] I have been informed that changes to MediaWiki code that result in maintenance categories and changes to templates/modules that result in category changes are processed differently. This may be two different feature requests.
>>! In T132467#3004685, @Legoktm wrote:
> @tstarling, @ssastry, and I discussed this a few days ago in #mediawiki-parsoid. Tim proposed modifying the refreshLinks.php script to support queuing jobs to update pages based on when they had last been parsed (using page_links_touched). After an initial run, we should set this up as a cron job.
In summary: Sometimes code changes will add new tracking categories or something. But until the page is edited, null edited, or purged with links update, the page will not show up in the category. The proposed solution for this is to run refreshLinks.php on a regular basis.