matthiasmullie added a comment.
Here's a simplified example:
Add `{{Sandbox/Mmullie_(WMF)/CheckIfHasStatement}}` to a file (e.g.
https://commons.wikimedia.org/wiki/File:2019-09-16-tenerife-icod.jpg)
That will add a category (`[[Category:No statements]]`) if there are no
statements (see Lua at
https://commons.wikimedia.org/wiki/Module:Sandbox/Mmullie_(WMF)/my_module), or
remove that category once there are.
Now try editing that file (removing all statements, adding new one) and
you'll find that the categorylinks aren't immediately updated - not until the
page is (null-)edited once more.
In T237991#6597542 <https://phabricator.wikimedia.org/T237991#6597542>,
@Addshore wrote:
> Trying to get a view of this ticket and the issue described in the
description without much context and I'm finding it hard to follow.
> Would someone be able to write out some more fleshed out steps? not just
the order but also the content that is changing where, and what exactly is the
expected outcome of this?
These are usually categories that get created via a Lua script evaluating a
condition.
E.g. if a file has (or lacks) a certain statement, it'll add a certain
category for tracking purposes.
When a property is added/removed, this prompts the script to re-evaluate and
update categories accordingly.
What currently ends up happening is that these pages (where the Lua script
ends up running and is supposed to update the categorylinks for) need another
(null) edit to reflect the change - they're always one behind.
What happened is that the process of storing a new revision used to parse the
old page once more right before the data actually ends up being stored.
Because the data is not yet in storage at that point, things are rendered
under the pre-save conditions (with the *old* categorylinks)
The render itself is not necessarily a problem, but anything related to
rendering the page might end up caching bits, which will be based off of
outdated information.
Later on, post-save, categorylinks etc. are updated as well based off of
(newly) rendered content, but parts of that content may have been filled in by
incorrect data in cache, as a result of the earlier render.
There already was a patch to get rid of core's pre-save render. It resolved
the problem on my local machine, but not on Commons.
There are pre-save hooks in this area as well, though, so I suspect that an
extension hooks into the process and also triggers a render.
(I need to look into this in more detail, but I suspect `PageContentSave` is
the one, and it's deprecated, so the remaining problem might eventually end up
going away automatically)
To replicate this on a local setup, try subscribing to `PageContentSave` and
call `$mainContent->getParserOutput();` - that causes the same behavior we see
on prod.
TASK DETAIL
https://phabricator.wikimedia.org/T237991
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: matthiasmullie
Cc: Keegan, Cparle, Multichill, matthiasmullie, Ramsey-WMF,
AntiCompositeNumber, Tgr, Addshore, Jarekt, Aklapper, CBogen, Akuckartz,
Nandana, JKSTNK, Lahi, PDrouin-WMF, Gq86, E1presidente, Anooprao, SandraF_WMF,
GoranSMilovanovic, QZanden, Tramullas, Acer, LawExplorer, Salgo60, Silverfish,
Poyekhali, _jensen, rosalieper, Taiwania_Justo, Scott_WUaS, Susannaanas,
Ixocactus, Wong128hk, Jane023, Wikidata-bugs, Base, aude, El_Grafo,
Dinoguy1000, Ricordisamoa, Wesalius, Lydia_Pintscher, Fabrice_Florin, Raymond,
Steinsplitter, Mbch331
_______________________________________________
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
