Change #1320679 had a related patch set uploaded (by Mszwarc; author: Mszwarc):

[mediawiki/extensions/CheckUser@master] Extract UIC button renderer from hook handler

https://gerrit.wikimedia.org/r/1320679

Change #1320680 had a related patch set uploaded (by Mszwarc; author: Mszwarc):

[mediawiki/extensions/CheckUser@master] UIC: Add support for content pages

https://gerrit.wikimedia.org/r/1320680

Change #1321514 had a related patch set uploaded (by Mszwarc; author: Mszwarc):

[mediawiki/core@master] Make Parser implement MessageLocalizer

https://gerrit.wikimedia.org/r/1321514

Change #1320679 merged by jenkins-bot:

[mediawiki/extensions/CheckUser@master] Extract UIC button renderer from hook handler

https://gerrit.wikimedia.org/r/1320679

Change #1321514 merged by jenkins-bot:

[mediawiki/core@master] Make Parser implement MessageLocalizer

https://gerrit.wikimedia.org/r/1321514

Change #1320680 merged by jenkins-bot:

[mediawiki/extensions/CheckUser@master] UIC: Add support for content pages

https://gerrit.wikimedia.org/r/1320680

Thank you to everyone who made this happen!!

Would someone smarter than me be able to add #uic to https://www.mediawiki.org/wiki/Help:Magic_words? (I don't know which section it belongs in, nor do I know the technical details to add an appropriate blurb.) Thanks in advance :)

In T424466#12214223, @HouseBlaster wrote:

Would someone smarter than me be able to add #uic to https://www.mediawiki.org/wiki/Help:Magic_words?

Documented it on https://www.mediawiki.org/wiki/Help:Extension:CheckUser#User_Info_card_in_page_content

The Help:Magic_words page seemed to me like it's primarily about the core's magic words and I couldn't find a good place on that page to include the UIC function.

I've added a notice about this task to the next Tech News issue:

User Info card is a feature that helps patrollers see information about user accounts. So far, it has been available only in places such as page history, logs and recent changes. Now, it's possible to place it in the page content as well, using the {{#uic:}} parser function. It can be particularly useful in templates like {{Userlinks}} (or their speciaized variants), as it will make it easier to see the context about a user on various noticeboard pages. The card will be displayed only to users who have it enabled in their preferences.

Thanks a lot, it's great! Is there a way to add something like {{#uic:|enwikisource}}, to show the data from different wiki site?

In T424466#12230632, @IKhitron wrote:

Thanks a lot, it's great! Is there a way to add something like {{#uic:|enwikisource}}, to show the data from different wiki site?

UserInfoCard doesn't support querying remote wikis and we don't have it in our current plans to add such a functionality.

In T424466#12230650, @mszwarc wrote:

In T424466#12230632, @IKhitron wrote:

Thanks a lot, it's great! Is there a way to add something like {{#uic:|enwikisource}}, to show the data from different wiki site?

UserInfoCard doesn't support querying remote wikis and we don't have it in our current plans to add such a functionality.

A pity. Thank you for your answer.

There is a tracking category there. Please consider excluding the old IP addresses from it, as missing the target of its creation.

In T424466#12235303, @IKhitron wrote:

There is a tracking category there. Please consider excluding the old IP addresses from it, as missing the target of its creation.

Yes, it's tracked in T435169: {{#uic}} parser function should allow to skip tracking category when invoked with IP address. We'll split the tracking category into two (one for IP targets, and other for everything else). Then, the wiki will be able to disable the former if they want (using Special:TrackingCategories, by changing the relevant message to -).

Great, thanks.

There is a notable delay and movement from having these elements on a page like https://ru.wikipedia.org/wiki/Википедия:Запросы_к_администраторам/Быстрые
Can some mitigation for that be added so that, if a user has these cards enabled, they don’t get a visible change to layout after the button gets rendered? For instance, by always reserving some space for it when .client-js class is present? I’ll note that it’s not a problem with watchlist etc., so there’s something specific to this implementation that gets delayed rendering.

In T424466#12249539, @stjn wrote:

There is a notable delay and movement from having these elements on a page like https://ru.wikipedia.org/wiki/Википедия:Запросы_к_администраторам/Быстрые
Can some mitigation for that be added so that, if a user has these cards enabled, they don’t get a visible change to layout after the button gets rendered? For instance, by always reserving some space for it when .client-js class is present? I’ll note that it’s not a problem with watchlist etc., so there’s something specific to this implementation that gets delayed rendering.

Hi! When I open the page, I see that the user icons are added immediately to the page content, and the only thing that causes a reflow is the "Show IP" button. Is it the same to what you see?

I think there’s some sort of discrepancy between the skins: in Vector 2022 I do see it added immediately, but in old Vector I see it added a few seconds after the page has loaded.

Change #1331507 had a related patch set uploaded (by Mszwarc; author: Mszwarc):

[mediawiki/extensions/CheckUser@master] UIC: Fix in-interface invocations of {{#uic:}} (client-side)

https://gerrit.wikimedia.org/r/1331507

In T424466#12260761, @stjn wrote:

I think there’s some sort of discrepancy between the skins: in Vector 2022 I do see it added immediately, but in old Vector I see it added a few seconds after the page has loaded.

You're right. It seemed that presence of Codex Button styles (which are, at least partially, loaded by Vector 2022) helped to display the UIC button immediately after page load. I have included the relevant part of button's styles in the UIC module, which should help. Full button Codex Button definition (CSS+JS) arrives together with JS module for UserInfoCard, so I didn't want to fully duplicate all the styles in the style-only module.

I think something is broken. When I try non-existing user, there is no tracking category as before, and the icon does not disappear as before. Instead, I get a wrong ID error.

In T424466#12265483, @IKhitron wrote:

When I try non-existing user, there is no tracking category.

That was the desired behavior, actually. The tracking categories are added to page when the wikitext is parsed. The result of a parse is then cached and reused for subsequent page views. I means that if the account gets created shortly after such a page is parsed, the category wouldn't disappear at the same time (and UIC couldn't reappear, if it was skipped the same way as it's now for invalid targets).

Maybe the error message should be better, but I propose to track it as a separate task, so as that it'll be clear what the status is etc.

Looks like it shows the old tracking category for all IPv6, I'm not sure.

I did a quick round of tests and wasn't able to reproduce. Can you point me to an example?

In T424466#12265767, @mszwarc wrote:

In T424466#12265483, @IKhitron wrote:

When I try non-existing user, there is no tracking category.

That was the desired behavior, actually. The tracking categories are added to page when the wikitext is parsed. The result of a parse is then cached and reused for subsequent page views. I means that if the account gets created shortly after such a page is parsed, the category wouldn't disappear at the same time (and UIC couldn't reappear, if it was skipped the same way as it's now for invalid targets).

Maybe the error message should be better, but I propose to track it as a separate task, so as that it'll be clear what the status is etc.

I do not speak about the preview, it's just for visualization. The tracking category for wrong user names of registered users does not work any more.

Looks like it shows the old tracking category for all IPv6, I'm not sure.

I did a quick round of tests and wasn't able to reproduce. Can you point me to an example?

My bad, it was because of another problem. Let me rephrase: any usage of #uic with any type of IP and bullets breaks the parser.

In T424466#12265820, @IKhitron wrote:

The tracking category for wrong user names of registered users does not work any more.

I can still observe the tracking category being added for e.g., {{#uic:inv#lid name}}. It's meant for invalid names as opposed to non-existing users, and has been working in such a way from the very beginning.

Looks like it shows the old tracking category for all IPv6, I'm not sure.

I did a quick round of tests and wasn't able to reproduce. Can you point me to an example?

My bad, it was because of another problem. Let me rephrase: any usage of #uic with any type of IP and bullets breaks the parser.

It's interesting, for me such wikitext renders correctly: https://test.wikipedia.org/wiki/User:MSzwarc-WMF/UIC

In T424466#12265911, @mszwarc wrote:

In T424466#12265820, @IKhitron wrote:

The tracking category for wrong user names of registered users does not work any more.

I can still observe the tracking category being added for e.g., {{#uic:inv#lid name}}. It's meant for invalid names as opposed to non-existing users, and has been working in such a way from the very beginning.

I'm in shock. Thank you for the explanation.

Looks like it shows the old tracking category for all IPv6, I'm not sure.

I did a quick round of tests and wasn't able to reproduce. Can you point me to an example?

My bad, it was because of another problem. Let me rephrase: any usage of #uic with any type of IP and bullets breaks the parser.

It's interesting, for me such wikitext renders correctly: https://test.wikipedia.org/wiki/User:MSzwarc-WMF/UIC

Weird.

Change #1331507 merged by jenkins-bot:

[mediawiki/extensions/CheckUser@master] UIC: Fix in-interface invocations of {{#uic:}} (client-side)

https://gerrit.wikimedia.org/r/1331507