Hi @DL2204 ; Thanks for the report but I am unable to reproduce this issue.

Looking through your examples of where it failed these are all now clickable. See this screenshot of the first one.

Can you confirm it's still an issue? Perhaps it took some time to happen after adding the statement or adding the formatter url property or something?

Could you confirm if you added the mapping on the platform dashboard before or after you imported all the data?

Hi @Tarrow ,

I have had an experiment: On May 19, I manually edited one of the properties where formatter URL did not work, and now, three days later, it does work. Another one (P20) I left unedited, and it still not works, as seen here: https://eneoli.wikibase.cloud/wiki/Item:Q276#P17, where there is a P20 qualifier in the statement.

That means, that edits to the formatter URL property value somehow trigger the process to make the value clickable. Apparently, for some properties the process was triggered from the beginning, while for some others, that got stuck and had to be re-triggered by editing the value on the formatter URL property.

Hi @DL2204 ,
Is this still reproducible?

Just observed this being reproduced on my own test instance.
Relevant Telegram group conversation

Reproduced again: https://anton12.wikibase.cloud/wiki/Item:Q10

Another thing came up:
formatter URL template was updated, but on the statement that was created afterwards the URL still follows the old template.
This was resolved after ?action=purge on the external identifier property

@Lydia_Pintscher Have you seen reports from Wikidata users for a similar problem? (Identifiers not becoming clickable until you purge the cache for them)

Yes this is known. You'll have to purge the page, make an edit or wait until the cache expires. I don't think we can/should change that as the page caching is quite important.
What you can maybe do is add a little note to the configuration area saying that this will take up to X hours to take effect?

@Lydia_Pintscher
In response to the comment above ^^^
'Making an edit' does not help.
The purge does help sometimes (yesterday I encountered a situation where even a purge of the Item, the external ID property and the formatter URL property didn't help at first, until it did in several hours).

I just created a fresh instance with a fresh example to see whether it will become clickable by itself in 24 hours.:
https://anton3.wikibase.dev/wiki/Item:Q1
UPD: it did

In T364744#10525608, @Lydia_Pintscher wrote:

Yes this is known. You'll have to purge the page, make an edit or wait until the cache expires. I don't think we can/should change that as the page caching is quite important.
What you can maybe do is add a little note to the configuration area saying that this will take up to X hours to take effect?

I think you additionally have to wait up to wgWBRepoSettings['sharedCacheDuration'] seconds (1 hour by default, 24 hours in Wikimedia production) for the property info cache to expire – only after that will purging individual pages start to have any effect. I think that shared property info cache is what’s causing the additional confusion here. (This is a known-ish annoyance on Wikidata, but I don’t know if there’s a separate issue for it – it’s mentioned e.g. in T323470#8409733.) That probably represents a bug somewhere – the code looks like CacheAwarePropertyInfoStore is supposed to do something so that CachingPropertyInfoLookup will quickly start to see the new property info after a property has been edited, but I don’t think it’s working correctly. (In November 2022, Clean up CacheAwarePropertyInfoStore attempted cache sets removed a ->set() call that was apparently already non-functional, under the assumption that “getWithSetCallback() is fast enough without the need to push a fresh value” – wild guess: maybe the getWithSetCallback() runs from a replica connection and thus hasn’t seen the property edit, and so it puts stale data right back in the cache? Maybe we should try calling ->set() in CacheAwarePropertyInfoStore instead of ->delete()?)

In T364744#10531812, @Lucas_Werkmeister_WMDE wrote:

This is a known-ish annoyance on Wikidata

Example: https://www.wikidata.org/w/index.php?title=Wikidata:Project_chat&diff=prev&oldid=2312665824

We got another report from a user where URLs are not formatted despite the mapping is set correctly.
https://blackbibliog.wikibase.cloud/wiki/Item:Q645
In this case, it has been more than 24 hours, but it still doesn't update.
I just purged the cache on the pages, so let's see if something changes in 24 hours.
I see this as another reason to prioritize this bug fix.

I was just investigating why SortedProperties do not work as expected on my test instance and it looks like it's also related to cache not being purged as expected, so I created another bug report for this: T404451