Page MenuHomePhabricator

When #ifexists target page is created/deleted, does not update links tables
Open, MediumPublic


Consider a page "SourcePage" containing wikitext like this:

{{#ifexist:TargetPage|Exists.[[Category:Foo]]|Does not exist.[[Category:Bar]]}}

Assume that when the above is first added to SourcePage, TargetPage does not exist. SourcePage is therefore categorized in Category:Bar.

Then create TargetPage. SourcePage is correctly purged, showing "Exists" and showing Category:Foo at the bottom of the page. But if you actually look at the two categories, SourcePage remains in Category:Bar and is not found in Category:Foo.

This same thing happens with image links (the list at the bottom of the image page is wrong) and template transclusion links (the list in the template's Special:WhatLinksHere output is wrong). I haven't tested external links, interwiki links, language links, or the like, but they are probably wrong too.

A null edit to SourcePage will, of course, fix all these problems, but it shouldn't be necessary.

See also T14019 for a detailed analysis of the underlying problem.


TitleReferenceAuthorSource BranchDest Branch
Update airflow to version 2.6.3repos/data-engineering/airflow-dags!450btullisbump_airflow_hive_connectormain
Update airflow to version 2.6.1repos/data-engineering/airflow-dags!385btullisupdate_airflow_2_6main
Customize query in GitLab

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:53 PM
bzimport added a project: MediaWiki-Parser.
bzimport set Reference to bz31628.
bzimport added a subscriber: Unknown Object (MLST).

Is this on a local test install or on one of the Wikimedia sites? IIRC we run cleanup of referenced pages through the job queue, so there may be some delay before everything gets invalidated.

Tested mainly on enwiki, but I just ran the same test on my local install (currently r99582) and observed the same behavior.

Is the job queue currently behind by ''hours'' when dealing with simple sandbox pages not linked from anywhere else?

joedecker wrote:

Speaking from my experiences on ENWIKI, there is a general feature/bug/behavior that template-inserted categories don't update until there's a null edit or better, as a rule. This impression seems confirmed to me by my reading of

I have been told by a knowledgable user (as I've been pursuing a BRFA for a bot to deal with the trouble this is causing a single particular maintenance category at ENWIKI) that this relates to purge, etc., not updating the "categorylinks table."

I'd be interested in knowing if that is in fact the case, if so if this is a problem that can/will be fixed, or if instead the performance implications of fixing it would be prohibitive. I can suggest/create workarounds at varying degrees of cost, but first, if this is just a general bug that's easily fixed, that'd be useful data. Thanks.

This seems related to bug 12019 ("ifexist function uses pagelinks table in lieu of better options"). Since ifexist is using the pagelinks table, I'm not sure why updates aren't working properly.

(In reply to comment #4)

This seems related to bug 12019 ("ifexist function uses pagelinks table in lieu
of better options"). Since ifexist is using the pagelinks table, I'm not sure
why updates aren't working properly.

I guess when a page is created/deleted, pages with pagelinks to it are only cleared from parser cache, but not reparsed (with linksupdate). Because traditional "pagelinks" change doesn't need linksupdate.

I found examples of this error on is.wikipedia by using Quarry on Labs. Those are:

pagelink frompagelink to

There was an link from these page as the template "Bókaheimild" used to link the parameter "titill". In 2007 these links where removed, as the template then used the template "ekkirauður" which removes redlinks by using the parserfunction "ifexist". As these links where redlinks when they where removed in 2007, these pagelinks should not be present in the pagelinks database table.

I have just tested this on and found out that the same issue affects both when the #ifexist target page is deleted and when it is moved without redirect (two actions that cause a blue link to become a red one).