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 is 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