Could you address this: T346250: wikipage.content hook warning on Live recent changes ?

Related task: T341349: wikipage.content should fire after content is appended to the DOM

Because we got message:

Hello everybody. Because LiquidThreads have been undeployed from Hungarian Wikipedia,

https://hu.wikipedia.org/wiki/Wikip%C3%A9dia:Kocsmafal_(m%C5%B1szaki)#Az_ideiglenes_fi%C3%B3kok_hamarosan_bevezet%C3%A9sre_ker%C3%BClnek

All Wikidata references are broken on huwiki.

Could you please consider this too? T361393: Remove the "switch to old look" button (aka MediaWiki:Vector-opt-out)

Why this link has to be in the main menu with bold face? Isn't it enough in the Preferences? It's very inappropriate because of the message it carries and also a dumb UI element. Present everywhere because of some exceptions. Why? Do you consider you comment an explanation?

Please implement this. It's not needed. It looks like an invitation, use the old look, don't use the new look. Why this link is still there?

There is a rendering problem on https://hu.wikipedia.org/wiki/Sablon:K%C3%B6nyvsorozat_infobox Could you take a look?

There's the point. Most of the sites are not providing dark mode. As I said, if I set both dark modes, the icons are visible but many features are not readable. At least on huwiki.

Thank you. Is there any CSS trick I can apply until then?

Could you tell please what is the reason for the change? Is it intentional? Can it be changed back?

It's not about preference. If I set both dark mode options, Wikimedia Vector 2022 and Chrome, the result is even worse. The inversion worked until Sep 6.

The icons are loaded, but they are not inverted by Chrome. Black drawing with black transparent background. Until Sep 6 they were inverted. Chrome 128, Windows 10 22H2, desktop, Auto dark mode setting of Chrome

Thank you for your attention. Chrome 128.0.6613.120 (64 bit), Windows 10 Enterprise 22H2 build 19045.4780

@stjn: Please see patch history and first patchset. https://gerrit.wikimedia.org/r/1069208

Could you ask please for clarification before closing? Only half of the problem is resolved. It had a perfect solution. Then Tacsipacsi came.

I use Chrome (Windows 10, desktop) with Auto Dark Mode for Web Contents which inverts colors. Until Sep 5 the icons were inverted and appeared in white and gray. Now they are not inverted and they are not visible. All user menu icons became invisible. Could you fix this, please? Vector-2022 skin, Wikipedia

<Button> within <a> was perfect. Thanks to @Tacsipacsi we cannot open it in new tab. What was your problem with button within a? It is the recommended method.

10:50 edit didn't get Reverted tag. https://hu.wikipedia.org/w/index.php?title=Moszkva&date-range-to=2024-07-03&tagfilter=&action=history&uselang=en

I faced the same problem on huwiki. See: https://hu.wikipedia.org/w/index.php?title=Port%C3%A1l:Wikip%C3%A9dia/Jel%C3%B6lt_lapv%C3%A1ltozatok/Test2&action=history&uselang=en

In T205506#9627364, @Bugreporter wrote:

... a suggestion is introducing a new page like MediaWiki:Wikibase-unconnected-pages-excluded-regexes which lists regexes for pages that should be removed from unconnectedpages.

This is what I was about to propose. Special:UnconnectedPages is totally unusable for the template namespace. There are many templates with datastore function, and many pattern based templates without any transcluded templates. It would be very useful to exclude pages based on regex, in order to Special:UnconnectedPages have meaning for templates.

Another example: https://commons.wikimedia.org/wiki/File:Map_of_Colorado_highlighting_Adams_County.svg

Current situation is as if I were set it OFF. Couldn't this status be cleared in the database?

Thanks. By "new" I meant "new visit since the problem exists" (few days). For example slwiki.

I am not seeing any bug here based on how everything has been configured. I'm sorry I can't be of more help here.

The two default values (anons and logged in) does not match. It is ON for the former, and OFF for the latter. You can see it for yourself if you try.

@Jdlrobson I don't understand why you are doing this. Where did I say that doesn't work for anon users?

1. Reference Previews is enabled and does work for anon users.
2. It is disabled for logged in users.
3. You can replicate it as I described.

This is the bug I'm reporting. It was on, and from one point went off without any intervention. It is off even now for "new" wikis I visit.

In T366419#9871339, @Func wrote:

What is enabled for anon users, is the Reference Tooltips gadget. Gadgets cannot be disabled individually for anon users, you can only disable all local wiki scripts with the ?safemode=1 query string.

Forget the gadget. We are talking the situation when the gadget is disabled.
Reference Previews: if disabled is the default value, as you say, then why does it work for not logged in users? It's not consistent with what you say. I don't understand.

I noticed afterwards that disabled setting is from Reference Tooltips gadget. Remains my original problem.

My situation is not what you are saying. I said it twice that I didn't set a global value for this preference. What you say in the task description is not true. This is not the problem I'm reporting.
Once again. I don't have global setting. If I view it not logged in, Reference Previews is on. If I view it logged in, Reference Previews is off, despite I never set it off, in a language version I haven't visited recently. You can replicate it as I described before. In some languages I can change the setting, in some languages I can't, the setting is disabled. "Set a local exception" is not present, because I don't have global value set, I assume. Please replicate and verify.

The task is to fix the bug.

Reference Previews default value for logged in users does not match the default value for not logged in users.
Steps to replicate the issue (include links if applicable):

Why does it work for not logged in users and doesn't for logged in users? Like it's turned off on purpose.

The function works consistent with the setting. The problem is that a couple of days ago the setting changed from on to off. Even now if I go to a new language version, dewiki, frwiki or eswiki, the setting is off by default. I didn't set global value for this preference. I don't use the Reference Tooltips gadget, it is not set on by default. It happened to others too on huwiki.

Please check on different language Wikipedias too. Do you have global setting for this preference? I don't.

Even now is turned off if I go to a new language version of Wikipedia.

This is what happened to me too. It got turned off by itself.

Huwiki page https://hu.wikipedia.org/wiki/Matthew_McConaughey?stable=0&uselang=en cannot be checked. After "accepting changes" it gets unreviewed over again.

The issue has returned:

• https://hu.wikipedia.org/wiki/Hallelujah!_(%C3%A9nekesk%C3%B6nyv)?stable=0&uselang=en
• https://hu.wikipedia.org/wiki/Hallelujah!_(%C3%A9nekesk%C3%B6nyv)?stable=0&uselang=en&action=history

But the redirect is also a link we want to see on the basic list.

In T120794#9511825, @Winston_Sung wrote:

Oh, this one?

https://hu.wikipedia.org/wiki/Modul:Adjacent_stations/LIRR?redirect=no

Only local namespace name is supported like "Modul" on huwiki. Please allow canonical namespace name too, like "Module".

@Aklapper Why do you close it? No one addressed the reported issues. I don't understand. Why would anyone report anything if you close it without answering? Could you please clarify or answer my previous questions. Thanks.

Could someone with expertise state that understands the problem and indicate which workaround is less worse?

1. make 1800 API requests instead of 4
2. use a very low percentage (1-15%) of downloaded data, increasing network traffic with no use

We could easily resolve this with a new filter parameter.
Thank you.

That's true, but you cannot get 500 entities at once, it remains the problem that you have to do 1800 requests in my previous example instead of 4. Is this not a problem?

What are the recommendations of stewards/maintainers/owners of the codebase regarding the issues? Either workaround is not desirable.

I think this request was closed without addressing the issues reported in it.

@Lydia_Pintscher It's not the case. How can you download the _P131 property of 1800 items with only 4 requests? Either you have to do 1800 requests, or download tons of data you use for nothing. This would not be for my convenience, it would be better for Wikimedia servers and resources. Did you take into account? Are you aware how big the items have grown? What a small percentage of total download the bots use?

Many Wikibase items have many statements. Many tasks deal with only one or few properties. It would considerably improve performance, traffic and load if it were a possibility to filter properties in the same manner as languages and sitefilter, especially when getting 500 entities at once.
It would be very useful to add a parameter properties or similar and allow values like P31|P1082|P939 to filter the returned data.
There is something similar for wbgetclaims.

You can see it here:

select * from page_props where pp_propname = 'wikibase_item' limit 100

https://quarry.wmcloud.org/query/77832

https://en.wikipedia.org/w/api.php?action=query&format=json&prop=pageprops&titles=Kofoworola%20Abeni%20Pratt&formatversion=2
gives

{
  "batchcomplete": true,
  "query": {
      "pages": [
          {
              "pageid": 51046741,
              "ns": 0,
              "title": "Kofoworola Abeni Pratt",
              "pageprops": {
                  "defaultsort": "Pratt, Kofoworola Abeni",
                  "page_image": "Kofoworola_Abeni_Pratt.jpg",
                  "wikibase-shortdesc": "20th-century Nigerian nurse; first black Chief Nursing Officer of Nigeria",
                  "wikibase_item": "Q25796287"
              }
          }
      ]
  }
}

I suspect that there is a table with page properties. As I see, it is already integrated, just needs a magic word like {{WIKIBASEITEMID}}.

Magic words are not Wikibase client. This a Wikipedia pageprops. See T349571 for links. Could someone add the right project and assign the task?

@Pppery What would be the correct project? What project deals with the {{PAGEID}} magic word? This is not about Wikidata, this is about magic words and page properties on Wikipedia. No one seems to deal with this feature request since 2016. Could you help please?

I propose {{WIKIBASEITEMID}} magic word. Like {{PAGEID}}, {{PAGEID:page name}}. See also T349571.

In T324422#8986804, @matmarex wrote:

It's not impossible that something special about VE edits is causing issues