Wikipedia:Village pump (technical): Difference between revisions

Browse history interactively

← Previous edit

Content deleted Content added

VisualWikitext

Inline

Latest revision as of 22:53, 16 May 2024

Table of contents
First discussion
End of page
New post

Shortcuts

The technical section of the village pump is used to discuss technical issues about Wikipedia. Bug reports and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).

If you want to report a JavaScript error, please follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk. Discussions are automatically archived after remaining inactive for five days.

view · edit

Frequently asked questions (see also: Wikipedia:FAQ/Technical)

Click "[show]" next to each point to see more details.

If something looks wrong, purge the server's cache, then bypass your browser's cache.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.

No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an `accesskey` property on it (default to `accesskey="f"` in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.

No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.

If you have problems making your fancy signature work, check Help:How to fix your signature.

If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.

If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.

For server or network status, please see Wikimedia Status. If you cannot reach Wikipedia services, see Reporting a connectivity issue.

« Archives, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212

Broken "pages by quality" assessment template[edit]

I'm trying to do some upkeep with many of the neglected articles on Zoroastrianism. When I visit WP:Zoroastrianism (or any other page containing the template), it seems the pages by quality template is broken. Thus, I am unable to review the assessment status of relevant articles. Is this problem on the end of WP 1.0? For what reason would the server would return a broken list? Doughbo (talk) 21:47, 8 May 2024 (UTC)[reply]

The list isn't broken, it's empty. User:WP 1.0 bot/Tables/Project/Zoroastrianism hasn't been updated in over three years. I suspect that the WikiProject has been de-subscribed. --Redrose64 🌹 (talk) 15:59, 9 May 2024 (UTC)[reply]

Shouldn't it auto-populate with entries that have been project-tagged? eg. Talk:Gatha (Zoroaster). Doughbo (talk) 20:16, 9 May 2024 (UTC)[reply]

If you're sure about this, then I think your first step should be to "reactivate" WikiProject Zoroastrianism. As part of that you would update Template:WikiProject Zoroastrianism by changing "inactive" to "main", which would repopulate all the categories, which should make everything work again — Martin (MSGJ · talk) 20:34, 9 May 2024 (UTC)[reply]

Thanks. I'm still getting to know things around here, like which actions are appropriate, so I appreciate the help. Doughbo (talk) 15:58, 10 May 2024 (UTC)[reply]

Now that you've reactivated the project banner template, the categories are being populated again, so I've undeleted most of the category pages - all except Category:FL-Class Zoroastrianism articles and Category:A-Class Zoroastrianism articles. If these are also required, say so and I'll undelete them too. --Redrose64 🌹 (talk) 18:05, 10 May 2024 (UTC)[reply]

Thank you very much! I see that the list is now functioning properly on the template page. On the Assessment page, however, the old, broken list is still present. What is needed in order to replicate the new list? If possible, I'd like to also include a line for unassessed articles. Doughbo (talk) 22:57, 11 May 2024 (UTC)[reply]

It's dependent upon a bot run. I left a note at Wikipedia talk:Version 1.0 Editorial Team/Index. --Redrose64 🌹 (talk) 23:44, 11 May 2024 (UTC)[reply]

Thank you very much! I think I'm equipped from here on out. I've subscribed to the thread, so I'll check on any updates from there. Doughbo (talk) 21:53, 12 May 2024 (UTC)[reply]

special:export[edit]

Tracked in Phabricator
Task T364554
Resolved

Are special:export broken? I get an error if I choice "Include templates". Christian75 (talk) 08:35, 10 May 2024 (UTC)[reply]

Yes :( T364554 It'll probably be fixed on Monday. Matma Rex talk 09:48, 10 May 2024 (UTC)[reply]

Thanks. Resolved today. Christian75 (talk) 21:10, 13 May 2024 (UTC)[reply]

What Links Here misses links/transclusions wrapped in includeonly[edit]

Tracked in Phabricator
Task T7178

I noticed this issue in Wikipedia:Templates for discussion/Log/2024 May 10#Template:Deleted template. In that discussion we used regexes (compare with WLH) to solve the problem but that's really error prone (this was the regex originally proposed in the TfD). Some more testing I did found that this also happens with regular links, not just transclusions. That means the issue affects all XfD venues. Can we get Special:WhatLinksHere to see links/transclusions between WP:INCLUDEONLY tags? If the current behavior is desirable for some reason, can a toggle be provided? Nickps (talk) 20:08, 10 May 2024 (UTC)[reply]

And funnily enough, I got the regex wrong while trying to prove that it's easy to get it wrong. Here's another attempt. Nickps (talk) 20:18, 10 May 2024 (UTC)[reply]

The current behaviour seems entirely correct to me - If the page "foo" contains either a link or a template wrapped in includeonly tags then the page "foo" does not actually contain that link or template. Only pages that transclude "foo" would have the link or template.

I don't see how this could be changed in the manner you suggest or why such a change would be beneficial - you would need the parser to render wikitext that it has explicitly been told not to render (and hope that doing so produces something sensible rather than a broken mess), then add entries to the linktables for links that don't actually exist. This seems likely to break all manner of things.

Your more complex "correct" regex does not capture every possible way of invoking the template, and doesn't actually capture any uses the simple case missed. You can call templates using all kinds of weird wikitext constructions, e.g. {{Dele{{void}}ted template}}, {{Deleted {{lc:{{NAMESPACE:Template:Cite}}}}}}. 86.23.109.101 (talk) 21:25, 10 May 2024 (UTC)[reply]

I believe I made my case for why my proposal is beneficial already. But, I'll elaborate further. When WLH is used in a deletion venue, what people want to know is where the nominated page is used. That includes links/transclusions between includeonly tags because, if the page is deleted, those will be affected too. I bet that 9 out of 10 frequent XfD participants will find the current behavior both surprising and undesirable.

Also, I never argued that my regex was "correct". That's why I called it "an attempt". In any case, you're making my point for me. Since regex won't work in the general case, we need something more powerful. Nickps (talk) 21:59, 10 May 2024 (UTC)[reply]

How is "the list of links only shows links that actually exist" and "the list of transclusions only shows places where a page is actually transcluded" surprising and undesirable behaviour? The whole point of includeonly tags is to stop stuff from being parsed when viewed directly.

I think you've missed that this behaviour isn't actually specific to includeonly tags, there are all manner of template coding schemes that can cause a template to call another template only in specific scenarios, the output can depend the parameters you pass it, where it is used, whether it is substituted, what the time is...

The point I was trying (and failing) to make RE regex is that the simplest, naïve approach to finding uses of the template found 6 uses. Your more comprehensive regex found 6 uses. While you can invoke templates using namespaces with arbitrary capitalisation and you can add whitespace and you could make the template name out of wikitext constructions these are rare to see in actual usage and the simple approach is good enough. 86.23.109.101 (talk) 23:47, 10 May 2024 (UTC)[reply]

The whole point of includeonly tags is to stop stuff from being parsed when viewed directly and the whole point of using WLH in XfD is to know all the pages that use a specific page in any way. Excluding everything between includeonly tags makes this intuition fail. You said, the simple approach is good enough. But if you read the TfD I linked above you'll see that the "simple approach" and the one tried first was not to use a regex. It was to trust WLH. In that case, no, the simple approach is not good enough. It utterly fails at what it's supposed to do. Nickps (talk) 00:03, 11 May 2024 (UTC)[reply]

Also, while most of the constructions I took into account are rare to see in actual usage adding whitespace is not. Nickps (talk) 00:13, 11 May 2024 (UTC)[reply]

I don't think we can. The template itself (which effectively excludes the includeonly section) doesn't transclude the page; the text it evaluates to does. It's a specific case of a more general insoluble problem. For example, a template Foo which transcludes [[{{{1}}}]] will, when called as {{Foo|Bar}}, transclude Bar, but as Template:Foo doesn't mention Bar there's no way to list Bar amongst its incoming links. Certes (talk) 21:01, 10 May 2024 (UTC)[reply]

But your Template:Foo does not link to Bar at all. It's just that the result of the transclusion of {{Foo|bar}} is a link to Bar. My motivating example is different. {{Expand}} directly links to {{Deleted template}}. The test to tell those two cases apart is simple. Just remove the includeonly tags. If you do that then {{Expand}} will show up in Special:WhatLinksHere/Template:Deleted template but {{Foo}} will not show up in Special:WhatLinksHere/Bar. And that's expected. What's unexpected is that when we add the includeonly tags back, the first link disappears. Why? It's clearly still there. Nickps (talk) 23:45, 10 May 2024 (UTC)[reply]

I don't think there is a way to achieve the OP's general request of finding all templates that use a template. If the template is called from inside a conditional if statement or similar, it won't appear in the "What links here" list either. There are no doubt more cases. – Jonesey95 (talk) 23:58, 10 May 2024 (UTC)[reply]

And that's wrong too if you ask me. If the link is spelled out in the source code of a given page then it should count for WLH. If we wrap a link in an if statement as in {{#if:{{{1|}}}|[[Foo]]}}, it shouldn't just disappear from the list. Nickps (talk) 00:32, 11 May 2024 (UTC)[reply]

Well, it's called "What links here" and the page doesn't link there. I don't know what else to tell you. Searching is necessary in some cases. – Jonesey95 (talk) 03:52, 11 May 2024 (UTC)[reply]

If the issue is semantics, then either rename "What links here" or add a "What links here including in noincude tags". At the end of the day, when you search for usages of a template (or any link), you are more than likely interested in all places it is used at, including those places. Gonnym (talk) 08:11, 11 May 2024 (UTC)[reply]

Turns out, this is already known since 2006. That issue only talks about categories, but the underlying idea is the same. Nickps (talk) 11:37, 11 May 2024 (UTC)[reply]

That phab task has nothing to do with what you are proposing here. That phab task is asking that articles should track where the categories on them are coming from and include that information in the category page, basically just adding metadata to the existing entries.

You are asking for template pages to parse content they have been told not to parse, somehow deal with missing parameters, figure out which templates "could" be used (even though this will vary with the parameters you provide) then add entries to the link tables for links and transclusions that don't actually exist. Certes has already tried to explain this to you once, but it is not possible to figure out an exhaustive list of every template that another template could call, as this depends upon how it is used. As a simple example, a template that contains the code {{cite {{{1}}}}} could end up evaluating to any of the citation templates ({{cite web}} {{cite book}} {{cite news}}) or an infinite number of redlinked template (e.g. {{cite foo}}) depending upon what someone puts into parameter 1. 86.23.109.101 (talk) 13:12, 11 May 2024 (UTC)[reply]

Nope, I never said anything about missing parameters. Your example is irrelevant. After all, there's nothing that says that parameters can only appear between includeonly tags. All I'm asking is that if for example, a template contains <includeonly>{{cite web}}</includeonly> then that template should appear in Special:Whatlinkshere/Template:cite web. Nickps (talk) 13:34, 11 May 2024 (UTC)[reply]

Let me turn that question back to you. How is {{cite {{{1}}}}} handled outside includeonly? This is a common usecase since not all templates wrap their code in includeonly (because they don't have to) and it works just fine. Why do you think that I ever asked we change that? Nickps (talk) 13:36, 11 May 2024 (UTC)[reply]

The data for WhatLinksHere is made when a page is rendered and actual links and transclusions are encountered during the rendering. It doesn't matter which code was used to produce the links. Code in <includeonly>...</includeonly> is ignored during rendering so no links are encountered. Your requested change would require something like a second rendering process where <includeonly>...</includeonly> is not ignored. It would be expensive and I'm pretty sure the developers would reject it as not worth the cost, and probably also as more likely to cause confusion than solve problems. Many users would be confused if WhatLinksHere reports links and transclusions which aren't actually in the page itself but may be in other pages which transclude it. PrimeHunter (talk) 22:26, 11 May 2024 (UTC)[reply]

It would be expensive. Per WP:PERF I can say that I don't care about that at all. What I suggest would be useful for XfD and that's all I care about. Now I agree with you that my proposal could potentially be confusing but that's easy to fix, just have the links explicitly marked as includeonly, like the phabricator issue suggests. Alternatively, you can make the feature opt-in so those links only appear for users that know they want them. Nickps (talk) 22:37, 11 May 2024 (UTC)[reply]

Thumb version and small version of some images are not shown[edit]

Resolved

Hi, for example, for the image c:File:Nasseraldinshah3.png the thumb version and small version are not shown. i.e,

Large version (280px)	thumbnail version (not shown)	small version (220px) (not shown)

This problem happens in Windows OS and Edge, Chrome and Firfox browsers, but not at Android. Please inspect. Thanks, Hooman Mallahzadeh (talk) 08:24, 11 May 2024 (UTC)[reply]

None of them are rendering for me. Firefox 125.0.3 --Redrose64 🌹 (talk) 14:03, 11 May 2024 (UTC)[reply]

@Redrose64 If you zoom in and out, the pictures would appear and disappear. But why this phenomenon occurs? Hooman Mallahzadeh (talk) 14:27, 11 May 2024 (UTC)[reply]

OK, if I use Ctrl++ to zoom in one step (to 110%), the left-hand image appears. If I zoom in four more steps (making five in all), to 170%, the second and third appear. By this time, the images are approaching the "natural" size of the image, which is 394 × 532 pixels; my guess is that there's something funny about the jpeg encoding that doesn't allow reduction beyond a certain limit. --Redrose64 🌹 (talk) 15:14, 11 May 2024 (UTC)[reply]

@Redrose64 Maybe! But this happens only for specific images between Wikipedia articles. When I view that at commons or standalone it seems that zoom in/out has no effect on its appearance. Hooman Mallahzadeh (talk) 15:27, 11 May 2024 (UTC)[reply]

There may be something broken with the full-size version of this image that browsers can cope with (which is why that can be displayed), while the software that's supposed to generate smaller versions can't. It may be enough just to download the affected images, open them in an image editing program, save a new copy, and upload that copy as a new version of each affected image (but I believe you need to be autopatrolled on Commons for that). Rummskartoffel 16:52, 11 May 2024 (UTC)[reply]

MediaWiki appears unable to scale it to any size. Only the original upload works. HTML for the "small" 220px version:

<a href="/wiki/File:Nasseraldinshah3.png" class="mw-file-description"><img src="//upload.wikimedia.org/wikipedia/commons/thumb/d/db/Nasseraldinshah3.png/220px-Nasseraldinshah3.png" decoding="async" width="220" height="297" class="mw-file-element" srcset="//upload.wikimedia.org/wikipedia/commons/thumb/d/db/Nasseraldinshah3.png/330px-Nasseraldinshah3.png 1.5x, //upload.wikimedia.org/wikipedia/commons/d/db/Nasseraldinshah3.png 2x" data-file-width="394" data-file-height="532"/></a>

MediaWiki uses srcset to offer different sizes and let the browser choose depending on circumstances. The above has three choices:

A smaller 100px version doesn't include the original 394px in srcset so no zooming will help there. PrimeHunter (talk) 16:44, 11 May 2024 (UTC)[reply]

Oddly, for me with Chrome 124.0.6367.158, looking at the diff for the initial post in visual diff mode displays all three images in the diff, but not in the page being displayed below the diff (I only see the leftmost image). (On Firefox 125.0.3, only the leftmost image is displayed in the visual diff and the page displayed below.) isaacl (talk) 17:24, 11 May 2024 (UTC)[reply]

Also when I do a simple reload via Ctrl-R on Chrome, all three images are displayed. (I see all three after posting a comment in this section; presumably the equivalent of a simple reload is being done.) If I do a force reload of the entire page via Shift-Ctrl-R on Chrome, just the leftmost image is shown. For me, page zoom doesn't cause the images to display/not display. isaacl (talk) 17:31, 11 May 2024 (UTC)[reply]

The 100px version in PrimeHunter's post doesn't display for me under any of these cases. isaacl (talk) 17:40, 11 May 2024 (UTC)[reply]

With both simple reload and force reload, I see three network requests being made. The first is for Nasseraldinshah3.png and it succeeds. The second two are for 330px-Nasseraldinshah3.png and 150px-Nasseraldinshah3.png, and they fail with a 429 code, "Too many requests". (As previously noted, the three images are displayed after the simple reload.) isaacl (talk) 18:05, 11 May 2024 (UTC)[reply]

Is this one of those multitudinous image problems that needs the image to be reuploaded to be fixed? — Qwerfjkl talk 18:34, 11 May 2024 (UTC)[reply]

I don't know. I think I understand better now why a simple reload causes the images to appear: since the original file URL (which was successfully retrieved) appears in the srcset for each of the images in the original post (but, as PrimeHunter stated, it doesn't get included for the 100px version), the browser will just use that to refresh the page, rather than try to match the file with the most appropriate pixel density based on the physical display (since with a simple refresh, the browser will try to avoid loading the images again, so there's no need to do a match if any of the images in the set are already available). My device probably has a different pixel density than the other commenters, such that changing the zoom level isn't causing the original image to be a match to be loaded. isaacl (talk) 22:58, 11 May 2024 (UTC)[reply]

I've uploaded a corrected version, but due to the 429, it will probably take a while (not sure how long) before we can see the effect of that. —TheDJ (talk • contribs) 09:16, 13 May 2024 (UTC)[reply]

It's fixed now. I processed it with the png-fix-IDAT-windowsize utility, to correct the invalid checksum it contained. —TheDJ (talk • contribs) 15:30, 13 May 2024 (UTC)[reply]

Can't login to the Wikipedia library[edit]

I do get this message "We are unable to validate your login credentials. Please contact your institution for assistance. Please note, Referring URL authentication may have been prevented by antivirus or privacy control software" but I'm not convinced that's the issue. But if others are able to login, it must be. Thanks. Doug Weller talk 09:34, 11 May 2024 (UTC)[reply]

I don't have the issue when I can see my credential in the upper right hand corner, and then search for Wikipedia:TWL . I can then see the library when I click on database access. Maybe the message is an artifact. -- Ancheta Wis (talk | contribs) 09:50, 11 May 2024 (UTC)[reply]

The error message matches one at EBSCO, which is just one of the partners with TWL. I doubt it's TWL you can't log into. Nardog (talk) 10:18, 11 May 2024 (UTC)[reply]

@Nardog@Ancheta Wis That makes sense. I can login to the WL but not use it to search for articles. I can click on Access Collection - but I'm puzzled by the fact that when I click on Brill it looks as though it just takes me to their web page, and if I click on a books offers it for sale. I've never clicked on Brill before so don't know if that's what it should do. Doug Weller talk 12:14, 11 May 2024 (UTC)[reply]

Hello Doug Weller! I'm having the same problem, can get to the Library page but as soon as I use the search I'm taken to the EBSCO Error page you describe. Others also reporting this problem, like here. I use the Library all the time, use it to access ProQuest as an invaluable source for referencing. Hope this is just a temporary glitch. Take care, LooksGreatInATurtleNeck (talk) 22:37, 11 May 2024 (UTC)[reply]

Thanks. Looks like there are other problems as well. Doug Weller talk 02:46, 12 May 2024 (UTC)[reply]

cc @Samwalton9 (WMF). –Novem Linguae (talk) 17:00, 13 May 2024 (UTC)[reply]

@Doug Weller, Ancheta Wis, Nardog, LooksGreatInATurtleNeck, and Novem Linguae: Apologies for the delay in responding here, but we believe this issue should now be fixed. Samwalton9 (WMF) (talk) 08:48, 15 May 2024 (UTC)[reply]

Hello Samwalton9! No worries, I saw the reply over on the Wikipedia Library talk page. Thank-you kindly for fixing the issue! The Library is so useful for researching & referencing, I wouldn't want to be without it. Take care, LooksGreatInATurtleNeck (talk) 10:38, 15 May 2024 (UTC)[reply]

@Samwalton9 (WMF) Thanks. Ironic that when I searched for an article it led to a nonexistent page. I still found it though. Doug Weller talk 12:39, 15 May 2024 (UTC)[reply]

Can anyone think/suggest how to reliably archive a docx document from a website?[edit]

I want to archive https://dam.gettyimages.com/viewer/universal/rc3x9h8n56vqfxvhx7fjs which is a production notes/press document for the 2024 film Abigail since if I can't back it up it's just at very likely risk of Link Rot since they don't host these forever.

I tried webarchive but all it saves is the frame, not the content (https://web.archive.org/web/20240511101050/https://dam.gettyimages.com/viewer/universal/rc3x9h8n56vqfxvhx7fjs) and archive.today which does save the doc but only the first couple of pages (https://archive.ph/R8LNy), and finding the direct link to the document here didn't have any further success. Anyone know of any options that will work on reliable long term archive sites? Thanks Darkwarriorblake (talk) 10:35, 11 May 2024 (UTC)[reply]

Archived at this link. -- LCU ActivelyDisinterested «@» °∆t° 20:18, 11 May 2024 (UTC)[reply]

That's amazing, thanks ActivelyDisinterested, what was I missing? You archived the download link instead? Darkwarriorblake (talk) 21:09, 11 May 2024 (UTC)[reply]

Archived the download load link, that's just a redirect but archive.org saves the redirect destination as well. Find where the reditect went and you have your archive link. -- LCU ActivelyDisinterested «@» °∆t° 23:15, 11 May 2024 (UTC)[reply]

Migrating SQL data from one toolforge db to another[edit]

I run two tools on toolforge, both of which have SQL databases. I'd like to consolidate them under one of the tools and would like to migrate the data in one of the databases to the other. I could do this with a script to extract the data to a file, then connect to the other location and insert the data, but that's a lot more trouble than insert into <newdb>.<newtable> select * from <olddb>.<oldtable>, which is how I'd do it in SQL Server. For that I would need to be simultaneously connected to both databases at the SQL prompt, with write permission on the new database at the same time as read permission on the existing database, which is not currently public. Is there a way to do this at the MariaDB SQL prompt or do I have to just write that script? Mike Christie (talk - contribs - library) 12:42, 11 May 2024 (UTC)[reply]

As far as I know, most Toolforge tools' databases are still on the same server. But probably neither tool's database user has read access to the other's. You might try asking for help via one of the channels listed at wikitech:Help:Cloud Services communication. Anomie ⚔ 13:33, 11 May 2024 (UTC)[reply]
I will try that; thanks. Mike Christie (talk - contribs - library) 19:09, 11 May 2024 (UTC)[reply]

I could do this with a script to extract the data to a file, then connect to the other location and insert the data. This is how I would do it. Can probably do everything you need from the command line. –Novem Linguae (talk) 16:59, 13 May 2024 (UTC)[reply]

ListeriaBot[edit]

I have written a SPARQL query that works perfectly on Wikidata query service but ListeriaBot seems unable to execute it and generate a table from it unless I delete the big optional clause. Please see here the template syntax and a link to the query on WDQS where you can run and verify the results (see the Query here too. I just wanted to test the water here and see if someone have had a similar experience before I contact the bot operator who might have their hands full. Assem Khidhr (talk) 04:06, 12 May 2024 (UTC)[reply]

Very long response times[edit]

I'm experiencing very long response times currently. Anyone else? Nurg (talk) 09:18, 12 May 2024 (UTC)[reply]

Me too. --Redrose64 🌹 (talk) 09:19, 12 May 2024 (UTC)[reply]

I got maintenance message. Grabup (talk) 09:20, 12 May 2024 (UTC)[reply]

seems there was a bit of a spike, but things returned to normal. https://www.wikimediastatus.net —TheDJ (talk • contribs) 09:49, 12 May 2024 (UTC)[reply]

AFD signature needs correction[edit]

I edited Wikipedia:Articles for deletion/Cloverland, Washington prior to its closure, but probably didn't get something on the correct line. When it closed, it didn't show up at my AFC stats page. I think I erred on where I signed. Tried to correct it after it closed, with no luck. Other than that, it looks like others have also edited the closed template, and possibly re-opened it. I think others need to have a look at the status of this AFD. Thanks. — Maile (talk) 17:45, 12 May 2024 (UTC)[reply]

The AFD is still open. The "closure" was by a sock forging another user's signature. Suffusion of Yellow (talk) 17:58, 12 May 2024 (UTC)[reply]

Thanks — Maile (talk) 21:04, 12 May 2024 (UTC)[reply]

Suffusion of Yellow There's still an odd glitch. Normally, when I edit an open AFD, it shows up almost immediately on my AfD Statistics for User:Maile66, but it's still not showing up. Any ideas on what I did wrong? — Maile (talk) 21:20, 12 May 2024 (UTC)[reply]

I got it, finally! It didn't like where I put my signature, or something like that. It works now. — Maile (talk) 21:38, 12 May 2024 (UTC)[reply]

Force collapse navboxes[edit]

Is there any script or piece of CSS to collapse all navboxes? -- LCU ActivelyDisinterested «@» °∆t° 18:58, 12 May 2024 (UTC)[reply]

User:SD0001/AllCollapseToggle.js. It places a "Collapse all" / "Uncollapse all" button under the Tools menu. – SD0001 (talk) 05:17, 13 May 2024 (UTC)[reply]

Doesn't that already exist in core? Nardog (talk) 05:23, 13 May 2024 (UTC)[reply]

Thanks SD0001, much appreciated. -- LCU ActivelyDisinterested «@» °∆t° 09:38, 13 May 2024 (UTC)[reply]

May 2024 Accessibility for Reading Update: appearance menu, upcoming font size changes and customization, dark mode, and more[edit]

Hi everyone! This is an update on the current work of the Web team on the Accessibility for Reading initiative that introduces changes to the Vector 2022 and Minerva skins. It improves readability, and allows everyone, both logged-out and logged-in users, to customize reading-focused settings. It will also increase the default font size for logged-out users of wikis and introduce dark mode. Customization will be done through the new Appearance menu, which will contain options for customizing 1. typography (font size, line height, and paragraph spacing combined), 2. color scheme (dark/light), and 3. page width.

1. Appearance menu, typography improvements, and font size changes for logged-out users

In December 2023, we introduced the "Accessibility for Reading" beta feature. It adds the Appearance menu which allows logged-in users to choose different font sizes and page widths. This makes it possible for people to read in a font size that they prefer and customize their experience. Since the introduction of the menu, we have studied its usage and performed usability testing:

No significant issues were observed, but based on the feedback, we have changed the copy and behavior of the menu (for example, we have renamed the "night" color scheme to "dark").
The majority of users who interact with the feature opt for a font size that is larger than the current default. This confirms our hypothesis that most users prefer a larger font size. We previously saw this in the findings from the community prototype testing.

Based on this data, we plan on increasing the default font size for all readers. The current (smaller) default will be kept for logged-in users and as one of the options so that anyone can return to the font size used in the past.

2. Dark mode

Dark mode is a highly-requested reading feature which was the top wish on last year’s Community Wishlist. We will bring dark mode to the desktop and mobile websites. Currently, dark mode is available to logged-in users on the mobile site (Minerva skin only). To access this feature, you must first be opted into advanced mode for mobile. Then, you can select "dark" from the list of color options. ("Automatic" will follow the preference of your device.) See the more detailed message about this change.

3. Page width options

With the introduction of Vector 2022, we made available the option for all readers and editors to switch their view from limited to full with a toggle in the bottom right corner of the screen.
That limited/full width toggle will be moved to the Appearance menu instead of being in the corner of the screen.
We will be also switching some pages to full width by default, including the main page.

Coming up soon!

Over the next weeks, we will be preparing for significant deployments related to this project:

First, we plan on introducing dark mode to the desktop website as a beta feature.
Then, we will bring the Appearance menu for all users and change the default font size for all logged-out readers.
Finally, after a period of testing, we plan on bringing dark mode into the Appearance menu for all users on the desktop and mobile websites.

This is just a report. Later this week, we will post more information, and invite you to a discussion. In the meantime, please check out the Accessibility for Reading beta feature. If you want to know more about the project, go to our project page for updates and general overview, and to the FAQ page for more details. You can also subscribe to our newsletter. Thanks! SGrabarczuk (WMF) (talk) 13:33, 13 May 2024 (UTC)[reply]

The above message says: The majority of users who interact with the feature opt for a font size that is larger than the current default. This confirms our hypothesis that most users prefer a larger font size. Leaving aside the selection bias problems in that statement, the phabricator link appears to indicate the opposite, that 44.9% of sessions eventually opt for small (default: font=0) font size; 43.6% of sessions eventually opt for standard (font=1) font size; 11.5% of sessions eventually opt for large (font=2) font size. What am I missing? – Jonesey95 (talk) 14:34, 13 May 2024 (UTC)[reply]

Hey @Jonesey95. The selection bias part needs to be addressed by someone else than me, but to your point about the link indicating the opposite: Standard + Large (larger font size) > Small (default). SGrabarczuk (WMF) (talk) 16:36, 13 May 2024 (UTC)[reply]

That's what I was missing: the small size was the default. I confused the word "standard" with "default", I suppose. – Jonesey95 (talk) 17:07, 13 May 2024 (UTC)[reply]

Hey @Jonesey95 - wanted to leave a quick note on the selection bias question. In terms of the selection bias, we recognize that there is a very specific audience that will be opted into our beta feature, which is a downside of any beta feature data to begin with. This is generally an audience of active logged-in users who are interested in trying out new features in the first place (they are quite different from the average reader). For some features, that might be a sufficient proxy. For others, it might not make as much sense. In general, we try to get data from multiple different sources in order to account for this. In this case, we did prototype testing on a subset of logged-in users across languages, user testing with logged-out readers, as well as the beta feature launch. We've also launched the feature as the default for logged-out users on a small set of wikis to see if the data we're seeing there resembles what we saw on beta. These should be sufficient predictors of the behavior in production, but it's important to measure and double-check. Once we have a wider release, we'll do a similar comparison as well. OVasileva (WMF) (talk) 14:41, 14 May 2024 (UTC)[reply]

Panoviewer.toolforge.org is down[edit]

Moved from Template talk:PanoViewer § Panoviewer.toolforge.org is down

– Sdkb ^talk 15:18, 13 May 2024 (UTC)[reply]

Template does not work. Panoviewer.toolforge.org is down. Liglioto (talk) 09:38, 13 May 2024 (UTC)[reply]

Template:PanoViewer isn't protected, feel free to adjust it. That external tool isn't supported by us here on the English Wikipedia, and has sparse documentation on where to report problems. You can try to open a bug on it similar to phab:T354949. — xaosflux ^Talk 15:33, 13 May 2024 (UTC)[reply]

Noting for reference that following phab:T354949#9792952, Panoviewer seems to be working again. All the best, ‍—‍a smart kitten_[meow] 12:14, 14 May 2024 (UTC)[reply]

Typing, but text appears a few lines below my cursor[edit]

Tracked in Phabricator
Task T365008

Hi, I'm encountering a weird bug (it's not the first time it's happened). When I type text in a long page in visual source editing (the 2017 wikitext mode), I'm getting some funky behaviour where what I'm actually typing ends up being multiple lines below my cursor. The video attached is this occurring on this page, but it sometimes happens on other such long pages.

Any ideas to debug?

Cheers, Cocobb8 (💬 talk • ✏️ contribs) 21:29, 13 May 2024 (UTC)[reply]

Smells like a code highlighter userscript/gadget bug. Are you able to reproduce when adding ?safemode=1 / &safemode=1 to the URL? This will turn off gadgets and user scripts. I suspect you will not be able to reproduce it. Next step after that will be tracking down which code highlighter userscript/gadget and reporting the bug on their talk page. –Novem Linguae (talk) 08:07, 15 May 2024 (UTC)[reply]

@Novem Linguae I did some debugging, and figured out that the issue is caused by the Syntax Highlighter itself. I'll report it on Phabricator. Cocobb8 (💬 talk • ✏️ contribs) 13:04, 15 May 2024 (UTC)[reply]

Tech News: 2024-20[edit]

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Recent changes

On Wikisource there is a special page listing pages of works without corresponding scan images. Now you can use the new magic word __EXPECTWITHOUTSCANS__ to exclude certain pages (list of editions or translations of works) from that list. [1]
If you use the user-preference "Show preview without reloading the page", then the template-page feature "Preview page with this template (what's this?)" will now also work without reloading the page. [2]
Kartographer maps can now specify an alternative text via the alt= attribute. This is identical in usage to the alt= attribute in the image and gallery syntax. An exception for this feature is wikis like Wikivoyage where the miniature maps are interactive. [3]
The old Guided Tour for the "New Filters for Edit Review" feature has been removed. It was created in 2017 to show people with older accounts how the interface had changed, and has now been seen by most of the intended people. [4]

Changes later this week

The new version of MediaWiki will be on test wikis and MediaWiki.org from 14 May. It will be on non-Wikipedia wikis and some Wikipedias from 15 May. It will be on all wikis from 16 May (calendar). [5][6]
The Special:Search results page will now use CSS flex attributes, for better accessibility, instead of a table. If you have a gadget or script that adjusts search results, you should update your script to the new HTML structure. [7]

Future changes

In the Vector 2022 skin, main pages will be displayed at full width (like special pages). The goal is to keep the number of characters per line large enough. This is related to the coming changes to typography in Vector 2022. Learn more. [8]
Two columns of the pagelinks database table (pl_namespace and pl_title) are being dropped soon. Users must use two columns of the new linktarget table instead (lt_namespace and lt_title). In your existing SQL queries:
1. Replace JOIN pagelinks with JOIN linktarget and pl_ with lt_ in the ON statement
2. Below that add JOIN pagelinks ON lt_id = pl_target_id
- See phab:T222224 for technical reasoning. [9][10]

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 23:56, 13 May 2024 (UTC)[reply]

CORS auth[edit]

Hello. I'm trying to edit Wikidata from Wikipedia (ro.wp to be precise) using a user script, but I am unable to do it under my user. The code from ro:MediaWiki:Gadget-wikidata-description.js works, it obtains an edit token and does the change, but in the history my IP appears. I made sure I am logged in both wikis. Can anyone give me an example of working code or some pointer on how to do the edits as logged-in user? Thanks! Strainu (talk) 08:59, 14 May 2024 (UTC)[reply]

mw.ForeignApi is the supported interface for accessing sister site APIs. Fetching a token manually isn't required, postWithEditToken() will do it for you. – SD0001 (talk) 09:08, 14 May 2024 (UTC)[reply]

Works like a charm, thank you! Strainu (talk) 09:53, 14 May 2024 (UTC)[reply]

Resolved

–Novem Linguae (talk) 08:05, 15 May 2024 (UTC)[reply]

Problem in map?[edit]

Hi,
Tenganan editing shows this (in red):

Preview warning: Page using Template:Infobox settlement with unknown parameter "pushpin_mapsize1"

Preview warning: Page using Template:Infobox settlement with unknown parameter "pushpin_map_caption1"

Preview warning: Page using Template:Infobox settlement with unknown parameter "pushpin_map1"

It was there when I arrived on the page and I have zero idea about what brings that up. (and I'm supposed to be working and I'm starting to run late on the job, so really no time to get into anything as mysterious as that.) Anyone would know how to get rid of that, please? If no (very) simple fix is possible, thanks for letting me know whom I can ask who would be willing to sort it out. Have a good day. Pueblo89 (talk) 13:20, 14 May 2024 (UTC)[reply]

Fixed – Jonesey95 (talk) 13:31, 14 May 2024 (UTC)[reply]

Anchoring new sections to set location on talk page[edit]

As I've formatted my user talk page in a manner that encloses all sections in a table, I was wondering if there is a way to have new talk page sections added at a specific point on a talk page, rather than simply at the end. Specifically, a means that would work with the default 'New section' button above the talk page, rather than the addition of a second, custom 'New section' wikilink or button on the talk page itself. -CoolieCoolster (talk) 01:35, 15 May 2024 (UTC)[reply]

There is not. I doubt this is something that will be added. Izno (talk) 02:25, 15 May 2024 (UTC)[reply]

If you remove the closing |}</div> tags, new sections will effectively go inside your custom frame. On the other hand, you might get people grumbling about this being a Linter error. Framing talk pages like this isn't well supported. Matma Rex talk 02:40, 15 May 2024 (UTC)[reply]

IP Information tool[edit]

Tracked in Phabricator
Task T363118

Facing a new issue today regarding the IP Information Tool where access to some of the non-admin information does not show up in the Special:Contributions page for an IP as it did before. That page now only shows "Version", "Active blocks", and "Contributions". Oddly, the country (not city) location still pops up on the watchlist preview, even though it does not show on the Contributions page. Anyone else seeing similar? Best, CMD (talk) 08:00, 15 May 2024 (UTC)[reply]

The IP information drop down has been returning no information for me other than the version (IPv4 vs. IPv6), local block info and contribs for the last two days. It's like it can't access any of the data from whichever database it draws from. Every other field simply states "not available".-- Ponyo^{bons mots} 21:43, 15 May 2024 (UTC)[reply]

And regarding my odd note on watchlist preview, this only happens sometimes, with even different edits from the same IP showing me country location in one instance but not another. CMD (talk) 01:50, 16 May 2024 (UTC)[reply]

Further learning, I can refresh the same IP contributions page repeatedly and sometimes it will show me the country, sometimes it will show no access. CMD (talk) 03:25, 16 May 2024 (UTC)[reply]

Can someone link a page where this has recently happened to them, so that I can try to reproduce? –Novem Linguae (talk) 07:15, 16 May 2024 (UTC)[reply]

@Novem Linguae: it happens on any IP contributions page (this one, for example).-- Ponyo^{bons mots} 15:29, 16 May 2024 (UTC)[reply]

Thanks, I'm able to reproduce. According to https://phabricator.wikimedia.org/T363118#9804312, "not available" is case #2. This means Spur/Maxmind doesn't have that data. Looking at these fields, they're all populated by Spur. Maxmind and Spur have different coverage, so we may have a location for an IP but no other data for it.. So that one is not a bug and they have no plans to patch it, it looks like. –Novem Linguae (talk) 15:56, 16 May 2024 (UTC)[reply]

I don't understand how that data was available consistently for all IPs, then suddenly is missing for nearly all of them. It renders the entire IP contribs drop down useless. Oh well.-- Ponyo^{bons mots} 16:13, 16 May 2024 (UTC)[reply]

Someone just commented in the ticket that they think it's happening way more than it used to and they think something is broken. So it may be a bug after all. Here's hoping the devs figure it out. –Novem Linguae (talk) 16:47, 16 May 2024 (UTC)[reply]

Dark mode is available in Vector 2022 as a beta feature[edit]

Hi everyone, the Wikimedia Foundation Web team has just released dark mode for logged-in users on desktop across all wikis for testing purposes. It's part of the Accessibility for Reading (Vector 2022) beta feature.

Just like previously, when we were releasing this feature for logged-in users on mobile, our goals for the early rollout are to:

Show what we've built very early. The earlier you are involved, the more your voices will be reflected in the final version
Get your help with flagging bugs, issues, and requests
Work with technical editors to adjust various templates and gadgets to the dark mode

Known limitations

Dark mode is only available for logged-in users: on desktop as a beta feature, and on mobile in the advanced mode.
Gadgets may initially not work well with dark mode and may have to be updated.
Our first goal is making dark mode work on articles. Special pages, talk pages, and other namespaces (including Wikipedia) have not been updated to work in dark mode yet. We have temporarily disabled dark mode on some of these pages.

What we would like you to do

Our request to you is exactly the same as previously:

To opt into dark mode, select the Accessibility for Reading beta feature from the beta feature list. This will opt you into the Appearance menu displayed in the right sidebar on every page. More about the menu itself here.
Next, go to different articles and look for issues:
- If you have noticed an issue with a template but do not know how to fix it
  1. Go to the recommendations page and find a relevant example
  2. If no relevant example is available or you're not sure of the fix, contact us
- If you want to debug many templates in dark mode
  1. Go to https://night-mode-checker.wmcloud.org/ and identify templates that need to be fixed. The tool flags the top 100 most read articles.
  2. Go to the recommendations page and find a relevant example
  3. If no relevant example is available or you're not sure of the fix, contact us
- If you want to identify problems beyond the top 100 articles.
  1. Install the WCAG color contrast browser extension (Chrome, Firefox) and visit some articles. Use it to identify problems
  2. Go to the recommendations page and find relevant examples
  3. If no relevant example is available or you're not sure of the fix, contact us
- If you have a bug report for dark mode that is not related to templates
  1. Take a screenshot of what you are observing.
  2. Contact us. If possible, please write down your browser version and operating system version.

When most issues are solved, we'll be able to make the dark mode available for readers on both desktop and mobile. Go to the Accessibility for Reading project page and the FAQ page to see more information about the basics of this project. Thank you! SGrabarczuk (WMF) (talk) 21:47, 15 May 2024 (UTC)[reply]

I don't know if this was the right move. Tons of pages still look like garbage (shoutout Special:Watchlist)—the theme is definitely not ready for use by non-technical editors. It wouldn't be too bad if you had made a seperate beta option for it—because you've clumped it in with Accessibility for Reading a couple people have gone on the Discord confused. Snowmanonahoe (talk · contribs · typos) 23:54, 15 May 2024 (UTC)[reply]

"Fixing" it is as simple as setting your personal chosen theme to light mode.

As for tons of pages, I just got separate word that OOUI interfaces don't support light mode (currently/ever?), which is why Watchlist has light elements. Perhaps it shouldn't be displaying as dark. Izno (talk) 00:08, 16 May 2024 (UTC)[reply]

Articles too. Along with interface pages, editnotices, syntax highlighting, half the mboxes... Snowmanonahoe (talk · contribs · typos) 00:27, 16 May 2024 (UTC)[reply]

The point is for editors to find these things. Might as well drop logged users in and let them make the two button presses to find a different, less-painful choice. Izno (talk) 00:41, 16 May 2024 (UTC)[reply]

Exactly, there is no magic fairy dust for some of this, just grunt work to fix the pages and templates that never had to account for a darkmode. —TheDJ (talk • contribs) 14:56, 16 May 2024 (UTC)[reply]

We do have a long-term solution for OOUI fixes that is in development right now. We hope to have it ready within the next couple of weeks. In the meantime however, pages like Watchlist and should be displaying in light mode so this is a bug. We're tracking it in phab:T365084 and should have a fix out later today. OVasileva (WMF) (talk) 07:36, 16 May 2024 (UTC)[reply]

@SGrabarczuk (WMF): Is there really a plan to take over the right 1/4 of screen with a "settings" panel every time someone opens a page in a new private tab, or clears cookies, or switches to a new language, or doesn't realize what the "hide" button does? Or is that just so in-your-face during the testing phase? Suffusion of Yellow (talk) 02:01, 16 May 2024 (UTC)[reply]

Hey @Suffusion of Yellow - thanks for the question. In general, we think this is the most effective way to launch the new menu and be able to inform users about it. It removes the necessity to add additional modals or notices that say "New menu available!" or "Dark mode available", which would otherwise show on every pageview. So, the current plan is to keep the menu open by default for the wider release as well for all logged-in and logged-out users. Then, after the release, we can look at the data to gauge whether we need to keep it open as default, or collapse, and when. OVasileva (WMF) (talk) 07:40, 16 May 2024 (UTC)[reply]

Why can't it be on the left side, with the TOC? Or better yet, just put a plain-text link at the top? I mean, registered users have already been able to find the "preferences" link for 20 years now. Right when I open up testwiki:LOREM IPSUM (or any page with a TOC) on my phone in a new private tab, then switch to the desktop site, about half my screen is whitespace, and the text is squished into a narrow little strip in the middle. It's unusable until I hide the settings column

People are reading a website, not installing software. There shouldn't be a "setup" stage before they can get down to the business of looking up that one little fact. The defaults should at least be usable. Suffusion of Yellow (talk) 17:11, 16 May 2024 (UTC)[reply]

@SGrabarczuk (WMF): https://night-mode-checker.wmcloud.org/ appears to only be for the mobile version. Is there is desktop report? Also, the beta is only for Vector 2022. Many editors still use legacy vector or other skins, will the new feature be moved to any other skin besides Vector 2022? How does the new feature compare to the dark mode gadget that is currently available? RudolfRed (talk) 03:31, 16 May 2024 (UTC)[reply]

This dark mode is only going to be supported on Vector 22 and Minerva so far as I know. Izno (talk) 03:54, 16 May 2024 (UTC)[reply]

The main idea of the new feature is that it doesn't invert colors that are not known to be invertable. This causes the colors on Pantone for example to not be distorted. Snowmanonahoe (talk · contribs · typos) 11:43, 16 May 2024 (UTC)[reply]

'Undo' button now says 'cin gbere le'[edit]

For some reason, if I go to the page history of any enwiki page, the undo button now says "cin gbere le" instead of "undo", as shown in the screenshot here. It just started happening today all of a sudden. Anyone else had this problem?

Note: the button actually still works, I just tested it here, it's just the button text that's different. — AP 499D25 (talk) 08:41, 16 May 2024 (UTC)[reply]

Short answer, don't use en-gb. Long answer - its upstream vandalism at translatewiki of the MediaWiki:Editundo message in the en-gb language. Language (Warning: Selecting a language other than 'en - English' will prevent you from seeing localized parts of the interface on the English Wikipedia, and you may see inaccurate external translations.): — xaosflux ^Talk 09:04, 16 May 2024 (UTC)[reply]
The upstream vandalism seems to have been cleared, but now you will have to wait for sync. Or just change to en. — xaosflux ^Talk 09:09, 16 May 2024 (UTC)[reply]
I created MediaWiki:Editundo/en-gb with "undo". Presumably that can be deleted when it synchronises — Martin (MSGJ · talk) 10:01, 16 May 2024 (UTC)[reply]

I see! Lol. Indeed, I have my interface language set to en-gb. Though I'm not sure how a protected page like that got vandalised. I guess it's unprotected on the translatewiki. — AP 499D25 (talk) 09:16, 16 May 2024 (UTC)[reply]
It's not quite the most aggressive action by the Provisional Change to EN Brigade that I've ever seen, but it's up there. DuncanHill (talk) 10:09, 16 May 2024 (UTC)[reply]
DuncanHill, Just wait until the Real Changes mob find out though ;) ——Serial Number 54129 10:21, 16 May 2024 (UTC)[reply]

Non-English en-gb messages are nearly always somebody editing the wrong Translatewiki messages when trying to translate another language. Here translatewiki:User:Umar Ahmad2345 was trying to make Nupe (nup) which sounds amusingly like noob. It's not an option in our preferences but maybe it's coming. Incubator has a Nupe Wikipedia. PrimeHunter (talk) 11:09, 16 May 2024 (UTC)[reply]

Almost nothing is protected on translatewiki for messages, it's ripe for abuse. — xaosflux ^Talk 13:30, 16 May 2024 (UTC)[reply]

Harv and Sfn no-target error help please[edit]

Hi. One of my pastimes is trying to empty Category:Harv and Sfn no-target errors. Today I found Military courts of the United Kingdom, which has multiple uses of {{sfn|Armed Forces Act|2006}} which are meant to link to {{UK-LEG|title=Armed Forces Act 2006|path=ukpga/2006/52 |ref={{harvid|Armed Forces Act|2006}}}} but don't. I can't work out how to fix the no-target errors and get the link from sfn to citation template to work. Any help will be appreciated, thank you. DuncanHill (talk) 10:22, 16 May 2024 (UTC)[reply]

{{UK-LEG}} does not know about |ref= so does not create an anchor ID. Without an anchor ID, {{sfn}} has nothing to link to. Your options are to modify {{UK-LEG}} or implement an appropriate solution from the list of possible solutions at :Category:Harv and Sfn template errors § Resolving errors: {{wikicite}} (best) or {{anchor}} (not so best).

—Trappist the monk (talk) 10:53, 16 May 2024 (UTC)[reply]

@Trappist the monk: Thanks, so like this? DuncanHill (talk) 22:39, 16 May 2024 (UTC)[reply]

I got a bit confused at first because the instructions at :Category:Harv and Sfn template errors § Resolving errors only say "wrapping a plain-text citation inside {{wikicite}} and setting |ref= or |id= as appropriate to match the value expected by the short-cite template", whenwikicite can "be assigned templates as well as text". DuncanHill (talk) 22:53, 16 May 2024 (UTC)[reply]

ChristieBot unable to edit Talk:Israeli invasion of the Gaza Strip (2023–present)[edit]

ChristieBot (BRFA · contribs · actions log · block log · flag log · user rights)

ChristieBot, which manages GA nominations, has been crashing when trying to transclude the GA review to Talk:Israeli invasion of the Gaza Strip (2023–present). The error is "Page en:Special:Log is not supported due to namespace restriction". The page is extended-confirmed protected. The bot does have extended-confirmed rights as part of the bot group rights, but presumably is missing some other related permission. I can change the code to not crash and simply log the error, but I'm at work and won't be able to touch the code for a few hours. If anyone can tell me what the problem is I would appreciate it. Thanks. Mike Christie (talk - contribs - library) 12:48, 16 May 2024 (UTC)[reply]

@Mike Christie check your bot permissions grant, that you have enabled Edit protected pages. — xaosflux ^Talk 13:33, 16 May 2024 (UTC)[reply]

Is this something I can set myself, and if so, where? (I'm not an admin.) I thought that a bot just needed the same user rights as a non-bot editor would need to edit a given page. Mike Christie (talk - contribs - library) 13:46, 16 May 2024 (UTC)[reply]

How is your bot logging in? Through the webui, or the api? If the API are you using a consumer grant or BotPasswords? — xaosflux ^Talk 13:51, 16 May 2024 (UTC)[reply]

I don't have access to toolforge from where I am now, and since it was set up eighteen months ago I don't recall the details offhand, but as I recall I have a config set up in the toolforge shell account that handles the bot authentication. I think that means it uses BotPasswords? Mike Christie (talk - contribs - library) 14:04, 16 May 2024 (UTC)[reply]

@Mike Christie You'd have to check your PyWikiBot user-config.py file. If it has an authenticate[] = line you're using oauth, if it has a password_file = line you're using BotPasswords. --Ahecht (TALK
PAGE) 14:08, 16 May 2024 (UTC)[reply]

I don't recall getting oauth to work so I think it must be BotPasswords, which I remember dealing with. (If SD0001 is available and has a moment they may be able to look and confirm as they are a maintainer for that bot.) Mike Christie (talk - contribs - library) 14:19, 16 May 2024 (UTC)[reply]

@Mike Christie If that's the case, you'd have to go to Special:BotPasswords, log in using your bot account, click on the password you're using for your bot, check the "Edit protected pages" box, and click "Update". --Ahecht (TALK
PAGE) 14:36, 16 May 2024 (UTC)[reply]

It's using BotPassword. It should be able to edit the page if the appropriate grant is checked as mentioned above. But from the error message, I am wondering if there is a code issue as well - the bot seems to be literally trying to edit Special:Log which of course isn't possible. – SD0001 (talk) 17:58, 16 May 2024 (UTC)[reply]

That flag is now checked but it hasn't fixed the issue. The issue only occurs when trying to edit that page, using the same code that it uses for transcluding GA reviews on other talk pages, so I can't see why Special:Log is in the picture. There's certainly no explicit attempt by the bot to try to edit the special page. The error happens when it attempts to add text to the Page object's text field: in the traceback I see self.botMayEdit() is called, in pywikibot/page/_basepage.py, which eventually pops out to the Special:Log error for some reason. Later I will have time to add some code to trap the error so at least it'll finish its run, even if it can't do that particular transclusion. I'll do that this evening unless someone has any further ideas. Thanks for the help so far. Mike Christie (talk - contribs - library) 19:04, 16 May 2024 (UTC)[reply]

This appears to be an error in pywikibot, I can confirm it also occurs for me.

Full traceback

---------------------------------------------------------------------------
UnsupportedPageError Traceback (most recent call last)
Cell In[1], line 4
2 site = pywikibot.Site('wikipedia:en')
3 page = pywikibot.Page(site, 'Talk:Israeli invasion of the Gaza Strip (2023–present)')
----> 4 page text = 'foo'
File /srv/paws/lib/python3.10/site-packages/pywikibot/page/_basepage.py:576, in BasePage.text(self, value)
571 """Update the current (edited) wikitext.
572
573 :param value: New value or None
574 """
575 try:
--> 576 self.botMayEdit() # T262136, T267770
577 except Exception as e:
578 # dry tests aren't able to make an API call
579 # but are rejected by an Exception; ignore it then.
580 if not str(e).startswith('DryRequest rejecting request:'):
File /srv/paws/lib/python3.10/site-packages/pywikibot/page/_basepage.py:1146, in BasePage.botMayEdit(self)
1131 """
1132 Determine whether the active bot is allowed to edit the page.
1133
(...)
1143 user cnfig file (user-config.py), or using page.put(force=True).
1144 """
1145 if not hasattr(self, '_bot_may_edit'):
-> 1146 self _bot_may_edit = self._check_bot_may_edit()
1147 return self _bot_may_edit
File /srv/paws/lib/python3.10/site-packages/pywikibot/page/_basepage.py:1163, in BasePage._check_bot_may_edit(self, module)
1161 username = self.site.username()
1162 try:
-> 1163 templates = self.templatesWithParams()
1164 except (NoPageError, IsRedirectPageError, SectionError):
1165 return True
File /srv/paws/lib/python3.10/site-packages/pywikibot/page/_page.py:78, in Page.templatesWithParams(self)
62 """Return templates used on this Page.
63
64 The templates are extracted by :meth:`raw_extracted_templates`,
(...)
74 :rtype: list of (pywikibot.page.Page, list)
75 """
76 # WARNING: may not return all templates used in particularly
77 # intricate cases such as template substitution
---> 78 titles = {t.title() for t in self.templates()}
79 templates = self raw_extracted_templates
80 # backwards-compatibility: convert the dict returned as the second
81 # element into a list in the format used by old scripts
File /srv/paws/lib/python3.10/site-packages/pywikibot/page/_basepage.py:1612, in BasePage.templates(self, content)
1609 del self _templates
1611 if not hasattr(self, '_templates'):
-> 1612 self _templates = set(self.itertemplates(content=content))
1614 return list(self._templates)
File /usr/lib/python3.10/_collections_abc.py:330, in Generator.__next__(self)
326 def __next__(self):
327 """Return the next item from the generator.
328 When exhausted, raise StopIteration.
329 """
--> 330 return self.send(None)
File /srv/paws/lib/python3.10/site-packages/pywikibot/tools/collections.py:279, in GeneratorWrapper.send(self, value)
276 if not hasattr(self, '_started_gen'):
277 # start the generator
278 self _started_gen = self generator
--> 279 return next(self._started_gen)
File /srv/paws/lib/python3.10/site-packages/pywikibot/data/api/_generators.py:625, in QueryGenerator.generator(self)
622 self normalized = {}
624 try:
--> 625 yield from self._extract_results(resultdata)
626 except RuntimeError:
627 break
File /srv/paws/lib/python3.10/site-packages/pywikibot/data/api/_generators.py:567, in QueryGenerator._extract_results(self, resultdata)
565 """Extract results from resultdata."""
566 for item in resultdata:
--> 567 result = self.result(item)
568 if self _namespaces and not self._check_result_namespace(result):
569 continue
File /srv/paws/lib/python3.10/site-packages/pywikibot/data/api/_generators.py:736, in PageGenerator.result(self, pagedata)
734 elif ns == Namespace.CATEGORY:
735 p = pywikibot.Category(p)
--> 736 update_page(p, pagedata, self.props)
737 return p
File /srv/paws/lib/python3.10/site-packages/pywikibot/data/api/_generators.py:983, in update_page(page, pagedict, props)
966 def update_page(page: pywikibot Page,
967 pagedict: dict[str, Any],
968 props: Iterable[str] | None = None) -> None:
969 """
970 Update attributes of Page object *page*, based on query data in *pagedict*.
971
(...)
981 supported yet
982 """
--> 983 _update_pageid(page, pagedict)
984 _update_contentmodel(page, pagedict)
986 props = props or []
File /srv/paws/lib/python3.10/site-packages/pywikibot/data/api/_generators.py:882, in _update_pageid(page, pagedict)
880 raise InvalidTitleError(f"{page}: {pagedict['invalidreason']}")
881 if int(pagedict['ns']) < 0:
--> 882 raise UnsupportedPageError(page)
883 raise RuntimeError(f"Page {pagedict['title']} has neither 'pageid'"
884 " nor 'missing' attribute")
UnsupportedPageError: Page en:Special:Log is not supported due to namespace restriction.

— Qwerfjkl talk 19:21, 16 May 2024 (UTC)[reply]

Thanks. I've opened phab:T365199 for this and linked here. I'll just catch the exception in that case. Mike Christie (talk - contribs - library) 20:31, 16 May 2024 (UTC)[reply]

Big placeholder thumbnails in search results[edit]

Tracked in Phabricator
Task T320295

Search results have a thumbnail next to them, or a gray placeholder if there's no suitable image in the article. Since today, those placeholders are bigger than regular thumbnails, which also places them uncomfortably close to the article text. It appears to be caused by this CSS rule:

.searchResultImage .searchResultImage-thumbnail > div { 
  padding: 0.5em;
}

Avessa (talk) 18:29, 16 May 2024 (UTC)[reply]

Thank you for reporting. This is a bit of fallout from phab:T320295 and it should be fixed latest next week. —TheDJ (talk • contribs) 18:54, 16 May 2024 (UTC)[reply]