Wikipedia:Village pump (technical)

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, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

Bot activity problem

DannyS712 bot, a bot which is supposed to look after various daily or weekly maintenance tasks, hasn't made any edits since July 1, including failing to update Wikipedia:Database reports/Polluted categories (2) in eleven days despite that being a thing that's supposed to happen weekly, but the bot's maintainer says on their own userpage that they're not around much lately, and they haven't made any Wikipedia edits at all since July 3, so there's no way to know when they'll be back in order to look into it if I approach them personally (especially in July, when any editor could very well be on vacation for a couple of weeks). So could somebody take a quick gander into whether there's a problem with the bot, and maybe jumpstart it again if there is? Thanks. Bearcat (talk) 15:53, 12 July 2024 (UTC)[reply]

@DannyS712 is pretty active in other areas of the wikiverse and I suspect they will see this ping. It certainly doesn't hurt to try. https://toolsadmin.wikimedia.org/tools/id/dannys712-bot states they are the only maintainer, so there's nothing anyone can do to help (unless they are a Toolforge admin). — MusikAnimal ^talk 19:48, 12 July 2024 (UTC)[reply]

It's a straightforward query without any postprocessing, so if DannyS712 doesn't respond or can't easily fix whatever's gone wrong, the report can be run at will on Quarry and it'd be trivial to migrate the WP:DBR subpage to {{Database report}}. —Cryptic 20:08, 12 July 2024 (UTC)[reply]

I saw the ping, and have been meaning to get to this, but am aware of the issue - hopefully I'll have time this weekend, and sorry for the delays --DannyS712 (talk) 21:07, 12 July 2024 (UTC)[reply]

I'm not sure if DannyS712 got to it this weekend and the bot just hasn't run yet, but if he didn't get to it, feel free to copy over my sandbox which has {{Database report}} set up correctly. (cc @Bearcat) --rchard2scout (talk) 07:18, 15 July 2024 (UTC)[reply]

DannyS712 has written a ton of great code done so much to help enwiki. -- GreenC 15:48, 15 July 2024 (UTC)[reply]

Nobody said otherwise. The problem is with a bot not functioning properly for purely technical reasons, and absolutely nobody accused Danny of anything improper. Bearcat (talk) 14:39, 20 July 2024 (UTC)[reply]

I guess I just got the weekend wrong, I was out of town for a while - I definitely should have time this week, maybe even tomorrow DannyS712 (talk) 02:40, 21 July 2024 (UTC)[reply]

No worries. I was able to use the substitute on-the-fly report provided above to work around the bot issue, so the delay hasn't been a major crisis. Bearcat (talk) 14:04, 21 July 2024 (UTC)[reply]

WMF sabotage?

I assume that since loads of stuff has stopped working with every skin except Vector (2022), this is a deliberate way of forcing editors to switch to it even though no one wanted it in the first place. Nice call! ——Serial Number 54129 09:58, 15 July 2024 (UTC)[reply]

I see no sign of that. If you tell us your skin and what isn't working then maybe we can help. PrimeHunter (talk) 10:05, 15 July 2024 (UTC)[reply]

Of course PrimeHunter, and apologies to WMF for the hyperbole. but it's blooming odd. I haven't touched my scripts for over a month—I know there's probably too many!—but over the last week (not sure absolutely since when), One-Click Archiver and Discussion Closer have disappeared from where they used to be. I noticed the latter's absence earlier when I tried to close a discussion. Tried all the available skins in preferences, the two scripts were missing in all of them except Vector 2022. Coincidence? Hence my outraged squawks of sabotage :) I'm using Vector 2010 btw. ——Serial Number 54129 11:01, 15 July 2024 (UTC)[reply]

@Serial Number 54129: That is, indeed, catastrophically egregious. Have you considered using User:Elli/OneClickArchiver.js and/or molotov cocktails? Polygnotus (talk) 11:39, 15 July 2024 (UTC)[reply]

Both scripts should have been updated for changes that have been communicated multiple times in the Tech News newsletter, scripts without active maintainers aren't the responsibility of the Foundation. Sjoerd de Bruin (talk) 12:09, 15 July 2024 (UTC)[reply]

Serial Number 54129, these are symptoms of a recent change in the HTML markup of headings, which you can see more about at mw:Heading HTML changes, and these scripts having inactive maintainers. There are new versions of the scripts you mention at User:DaxServer/DiscussionCloser and User:Elli/OneClickArchiver. Curbon7 (talk) 12:33, 15 July 2024 (UTC)[reply]

It's so complicated![/MOANS] I deal with it now. Thanks for all your help, @PrimeHunter, Sjoerddebruin, and Curbon7: and I guess you too Polygnotus :p ——Serial Number 54129 12:43, 15 July 2024 (UTC)[reply]

@Serial Number 54129 The good news is that all this stuff will break for Vector 2022 in the near future as well. The markup changes that broke those scripts was implemented on older skins first, but will be implemented on Vector 2022 in MediaWiki 1.44. --Ahecht (TALK
PAGE) 14:39, 15 July 2024 (UTC)[reply]

Serial Number 54129, I've already had to updaye one of my scripts to work in Vector 2022 because of some html change, not sure if that's related. — Qwerfjkl talk 16:05, 15 July 2024 (UTC)[reply]

Absolutely unacceptable opening comment. I just have to say it. F'ing 100k edits lets people get away with this shit I guess. —TheDJ (talk • contribs) 18:11, 15 July 2024 (UTC)[reply]

Yeah, this is ridiculous. How is "WMF sabotage" appropriate in any circumstance? @Serial Number 54129, if you were serious when you said "apologies to WMF for the hyperbole", you should've changed the section heading and struck your initial comments. Legoktm (talk) 04:49, 21 July 2024 (UTC)[reply]

Hey TheDJ, hey Legoktm here I am, for your delectation :) *waves* ——Serial Number 54129 21:23, 21 July 2024 (UTC)[reply]

The title of this thread is rather hyperbolic, but there is something to be said about how this breakage came to be. Wikipedia depends on hundreds (if not thousands) of add-on front-end scripts (and other back-end tools) to do essential work. I don't think it's hyperbolic at all to say that if all these tools were to suddenly stop working, it would be very difficult to keep things going. These tools depend on navigating (and in many cases, modifying) the structure of a rendered page. As such, the structure of the HTML is an essential API, just as much as any of the other documented APIs. The problem is, it's not documented. And as we've seen here, it's subject to change with little or no notice, breaking stuff willy-nilly. That needs to change. RoySmith (talk) 14:29, 15 July 2024 (UTC)[reply]

All changes like this are clearly communicated wide ahead. That users keep using outdated scripts (or fork a existing script and never process the upstream changes) and we as the community have no way to force them to switch to a maintained version (or gadget) is a huge problem in the longer term. Sjoerd de Bruin (talk) 14:53, 15 July 2024 (UTC)[reply]

(edit conflict) The issue here isn't little to no notice. The notice was given in Tech news updates and I had seen in the passing some repeated pings and conversations (or attempts to do so) on the various talk pages with the maintainers. Some of these userscripts as noted by some above were abandoned or maintainers not being active.

If anything, we should look at how the userscript system is being set up (by limitations of the software) to be dependent on bus factor of 1 editor, the maintainer to have the userscript updated. Are INTADMINS empowered to update these userscripts? If so, is having 9 INTADMINs (at the current count) sufficient to update and maintain the userscripts or even redirect these outdated userscripts to the updated ones when asked? – robertsky (talk) 14:56, 15 July 2024 (UTC)[reply]

Is there a centralised place that lists all the common userscripts and who runs them? I think such a list might be helpful to track this sort of thing. Especially if you add maybe a "Last updated" + "How many editors use it" column. If a script is not updated and it falls behind, it's much easier to follow along or maybe notify editors. Soni (talk) 15:06, 15 July 2024 (UTC)[reply]

For most used, see Wikipedia:User scripts/Most imported scripts. Sjoerd de Bruin (talk) 15:08, 15 July 2024 (UTC)[reply]

For a general list see Wikipedia:User scripts/List – robertsky (talk) 15:09, 15 July 2024 (UTC)[reply]

It's a pretty common problem with volunteer-written software. People often aren't great at succession planning, particularly when there is no financial incentive. Having the software be open source and thus available is probably good enough for small scripts. Once the tools become more elaborate, possibly with off-wiki build systems using languages other than Javascript, something more definite would be better. But it's a tradeoff: in the spirit of empowering anyone to build their own personal tools that can also be used by others, the community doesn't require any approvals that might be contingent on a long-term sustainable setup for maintenance (after all, the vast majority of scripts like the ones I wrote aren't ever going to need that). Human nature being what it is, it's hard to get backup developers ready unless they actually start taking over some of the development. But working in a team means some slowdown in development to co-ordinate and collaborate, though with the eventual benefit that there will be more redundancy in developers able to make fixes and enhancements. isaacl (talk) 16:25, 15 July 2024 (UTC)[reply]

There is seldom a backlog (see User:AnomieBOT/IPERTable) of ready-to-go bug fixes on abandoned user script pages. It is not up to intadmins to maintain the programming of everyone's personal scripts, but we will process bugfixes if the script owner has abandoned the project. In general, editors should never assume that another editor will make a future edit and could abandon or change their own personal scripts at anytime. — xaosflux ^Talk 18:27, 15 July 2024 (UTC)[reply]

Anyone reading this may be interested in this phab ticket for a "Gadget API for adding buttons to section titles". — Qwerfjkl talk 16:07, 15 July 2024 (UTC)[reply]

Yeap. I was just going to drop a link to the phab ticket you linked, thanks for linking it. The ideal workflow would have been to create this API first, THEN start deploying mw:Heading HTML changes. And anything that broke could be converted to the new API. But unfortunately that didn't happen. So now I have just been waiting for them to finish the staggered rollout, which will finally complete this Thursday July 18. At that point we can fix any remaining broken scripts. These scripts could have been fixed during the staggered rollout, but patching it to support 2 types of selectors is more complicated than just waiting for the rollout to finish, so the ideal time to fix all these is when the rollout is finished on Thursday. –Novem Linguae (talk) 21:47, 15 July 2024 (UTC)[reply]

Oof. An implemented phab:T337286 would have saved a lot of time spent on (mostly duplicate) work for userscript maintenance in Wikipedia:Village pump (technical)/Archive 213#Heading markup changes. —⁠andrybak (talk) 07:52, 16 July 2024 (UTC)[reply]

Probably worth posting this on the wishlist. If more gadget developers are asking for an API, it makes an easier case for prioritizing it. 🐸 Jdlrobson (talk) 23:08, 18 July 2024 (UTC)[reply]

Recommend articles

Is there a way to edit/change the “Recommended articles” that appear at the bottom of articles in mobile view? Blueboar (talk) 19:19, 16 July 2024 (UTC)[reply]

@Blueboar Yes, it's possible to add specific entries. There are some details at mw:Help:Extension:RelatedArticles about that. Quiddity (WMF) (talk) 19:33, 16 July 2024 (UTC)[reply]

Sorry, but that link didn’t help. I need more of a step by step instruction.

Also, why is this all hidden away on an extension and not editable directly from the article page? Blueboar (talk) 20:17, 16 July 2024 (UTC)[reply]

@Blueboar For example, at New York City they have {{#related:Manhattan}} (and others) at the bottom of the article, written in the wikitext just above the categories.

I think it's setup like this (since 2015 when it was created) because it's intended to be useful to readers automatically, without any interaction needed (but with overrides available, like this, when required). Quiddity (WMF) (talk) 20:58, 16 July 2024 (UTC)[reply]

Ok, I can see how it works at The NYC article… but take a look at Roberto Mogrovejo (just to pick an article at random)… there are NO “related” tags at all. The three “related articles” seem to just appear by magic. It isn’t very intuitive. Blueboar (talk) 01:26, 17 July 2024 (UTC)[reply]

It's explained at mw:Help:Extension:RelatedArticles. By default they are selected automatically from a search so the editors don't have to do anything. You can override the automatic selection by adding {{#related:}}. We rarely do that. PrimeHunter (talk) 01:58, 17 July 2024 (UTC)[reply]

I understand that (now)… my concern is that, while this is (poorly) explained on a page at meta, there is nothing at the article level to help editors.

Perhaps the easiest solution that I might suggest is to create a bot that would write the automatically chosen “related” tags somewhere in the article’s edit view (listed the way the manually chosen ones at the NYC article are listed). Then, if editors want to choose alternatives, they have something to edit right there on the page. Blueboar (talk) 12:19, 17 July 2024 (UTC)[reply]

It would be better to actually have an edit link on related article that opened the editor with the three currently algorithmically-defined articles pre-selected and appended to the page. It would be pretty straightforward to create a gadget that does this.

A bot doesn't sound like a good idea as the recommendations improve as new articles get edited or created.

I believe the reason they are currently not in the article or editing is encouraged is that they do not show on the desktop site. It would also be nice if these showed up on desktop experience as well to avoid confusion. 🐸 Jdlrobson (talk) 23:05, 17 July 2024 (UTC)[reply]

Related articles are deliberately only shown in mobile and Timeless in most Wikimedia wikis. https://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php says:

'wgRelatedArticlesFooterAllowedSkins' => [
	'default' => [ 'minerva', 'timeless' ], // T144812, T181242
	'dewiki' => [ 'minerva' ], // T278611
	'eswikinews' => [], // T230660
	'frwikinews' => [], // T341105
	'htwiki' => [ 'minerva', 'vector', 'vector-2022', 'timeless' ], // T126826, T298916
	'hewiki' => [ 'minerva', 'vector', 'vector-2022', 'timeless' ], // T191573, T298916
	'wikivoyage' => [ 'minerva', 'vector', 'vector-2022', 'timeless' ], // T298916
	'zhwikinews' => [], // T299856
],

I don't know how it was decided but mobile omits navboxes and categories so there are fewer ways to navigate. It does work in Vector 2022 when it's enabled, e.g. at ht:Wikipedya and he:ויקיפדיה. PrimeHunter (talk) 10:14, 18 July 2024 (UTC)[reply]

Yeh I honestly can't remember why disabled on desktop, but yes it would be trivial to add these to English Wikipedia desktop for any skin if it was requested and it would likely lead to better recommendations on the long term.

Probably worth a quick RFC or discussion under Wikipedia:Village_pump_(proposals) if someone feels inclined to do that. Jon (WMF) (talk) 02:18, 20 July 2024 (UTC)[reply]

Wikipedia:Manual of Style/Accessibility and Galleries

An editor claimed there is an accessibility issue with mobile version when it comes to galleries [1] [2], yet I see no issues when I tested with a mobile device. There's also MOS:ACCIM, which makes the same claim about galleries. I'm just curious how up-to-date this information is? Many Wikipedia:Featured articles such as Climate change make use of galleries.

Do the same issues apply to gallery tag, as opposed to Template:Gallery (which resize the images)? Bogazicili (talk) 19:59, 17 July 2024 (UTC)[reply]

Stretched navbox

Template:Video game controversy stretches outside of its outline, presumably because of there being no line break in Notice of the National Press and Publication Administration on Further Strict Management and Effective Prevention of Minors' Addiction to Online Games. Should the article name just be piped to a shortened version, or should someone put the bug in Phabricator? QuietCicada chirp 20:14, 17 July 2024 (UTC)[reply]

I've seen a similar issue where tables extend past the content well, and obstruct the tools panel. List of current NFL stadiums. JWheeler-WMF (talk) 20:41, 17 July 2024 (UTC)[reply]

From {{navbox}}:

{{navbox}} automatically adds the class nowraplinks which can be overridden, for example with |listclass=wraplinks.

Sjoerd de Bruin (talk) 20:47, 17 July 2024 (UTC)[reply]

Intermittent Python errors in background jobs

I intermittently get some errors on a background bot job. The bot fails, more or less gracefully, and picks up again at the next run, so this is not urgent, but if there's a way to avoid these errors it would be good to know. The errors include:

pywikibot.exceptions.ServerError: 502 Server Error: Server Hangup
requests.exceptions.ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))
pywikibot.exceptions.ServerError: 503 Server Error: Service Unavailable
pymysql.err.OperationalError: (2006, "MySQL server has gone away (ConnectionResetError(104, 'Connection reset by peer'))")

Are there ways to retry in these cases, or do they indicate a server state in which the job is not going to be able to run anyway? Mike Christie (talk - contribs - library) 00:50, 18 July 2024 (UTC)[reply]

Can be either. It can be an intermittent issue for 'any' request, or it can be a specific request that is trying to do something that the server isn't expecting or that is taking too long to eexecute.. —TheDJ (talk • contribs) 08:07, 19 July 2024 (UTC)[reply]

OK, thanks. These are always requests that run most of the time, so it's the intermittent issue. Failing gracefully seems like the best option. Mike Christie (talk - contribs - library) 10:04, 19 July 2024 (UTC)[reply]

Discussion at Wikipedia:Village pump (proposals) § Allow everyone to move pages in draftspace

You are invited to join the discussion at Wikipedia:Village pump (proposals) § Allow everyone to move pages in draftspace. Nickps (talk) 16:58, 18 July 2024 (UTC)[reply]

Alphabetical comparison of 2 strings

Does anyone know of a template or module which would allow me to give it two strings and simply return the one that comes first alphabetically (perhaps with a switch to choose between ascending or descending order)? Josh (talk) 22:28, 18 July 2024 (UTC)[reply]

@Joshbaumgartner just checking, you want an {{min}} function but for stings? So for example {{minstring|foo|bar|biz}} --> bar ? — xaosflux ^Talk 22:48, 18 July 2024 (UTC)[reply]

@Xaosflux That would be exactly right. The ability to have more than 2 strings compared would be great, though I only had 2 in mind for my purpose. Josh (talk) 22:52, 18 July 2024 (UTC)[reply]

Maybe you can use {{sort list}}. PrimeHunter (talk) 00:26, 19 July 2024 (UTC)[reply]

Or make a simple sortable wikitable; see Help:Sortable tables. Easy to sort more than two strings and easy to do ascending or descending sorts.

—Trappist the monk (talk) 00:53, 19 July 2024 (UTC)[reply]

Thanks, the thing is that I just want the first item returned because that value will be used in a template and further processed to format an output. Maybe I can process the list to strip all the rest of the list away but it would be a lot simpler if there were a way to just get the single value back. I looked at {{sort list}} but I don't have the Lua chops to modify the module to give me the single value back, or to be called without having to use multiple lines to provide the input. The functionality of {{min}} is exactly what would be most efficient to employ in the template I am developing, just I need it to work on strings. Josh (talk) 01:40, 19 July 2024 (UTC)[reply]

Lua supports less-than comparison between strings, so it would be straightforward to implement. (The implementation from Module:Math could be copied with the code enforcing numeric arguments removed, but being comfortable with Lua would be helpful as it uses various implementation techniques for reusability and efficiency.) I believe the result, however, would be dependent on the installed locale on the server and thus I'm not sure if it would be consistent, or would work across all Unicode characters. The same issue also exists for {{sort list}}, though, so I don't know if this is a problem for your specific use case. isaacl (talk) 04:46, 19 July 2024 (UTC)[reply]

Looks like modern MediaWiki forces the C.UTF-8 locale, so results should be consistent. Even before that, since phab:T107128 Wikimedia wikis have set that locale. Anomie ⚔ 11:40, 19 July 2024 (UTC)[reply]

I'll be honest, I am not even at a beginner level with Lua. I've perused a few modules and made the slightest of tweaks to one or two of them, but I would rank my Lua fluency only about 3 microns above 0. I sure that for someone of even intermediate ability this function is probably child's play, but I'm barely at newborn level, so this is why I have appealed to the community to find out if this function is already out there somewhere. Josh (talk) 13:08, 19 July 2024 (UTC)[reply]

Can you explain a bit more about the intended use? isaacl (talk) 13:53, 19 July 2024 (UTC)[reply]

Sure, I am working on a template that will determine complex category names based on elements provided and within the context of a given topic. In some topics, the elements are done alphabetically, so it needs to compare multiple elements and determine which comes first in the target category name. For example, say it knows it is combining 'children' and 'adult humans', it needs to know which to list first. The correct target is 'adult humans with children', as 'children with adult humans' would be a redirect or redlink. If I could simply use {{min|children|adult humans}} and get "adult humans" back, it would be super easy for the template to correctly form the target category name based on that. Of course {{min}} is only for numbers, so it'd need to be a function that worked on strings. Josh (talk) 14:37, 19 July 2024 (UTC)[reply]

I'm a bit confused by the example, since the two don't seem equivalent and an alphabetical sort doesn't seem like a reasonable way to choose one over the other. It feels like the code would need to search through category hierarchies to find the most suitable category? isaacl (talk) 17:36, 19 July 2024 (UTC)[reply]

I don't need it to do any category hierarchy searching, as the structure is already known and set. It doesn't really matter to me, or at least to this template, why the category names are arranged they way they are, that's already a fact of life. I have something that works now, so thank you again for the input! Josh (talk) 02:44, 20 July 2024 (UTC)[reply]

@Joshbaumgartner, see if

{{Switch by pattern|_input= 'children' and 'adult humans' |adult humans|children|_returnall=x |_returncaptures=x |_outputsep=_with_}}

→ adult humans_with_children can help. You can use |_outputsep={{sp}}with{{sp}} as well. This way you may need no further processing for your category name. Ponor (talk) 18:44, 19 July 2024 (UTC) + 19:36, 19 July 2024 (UTC)[reply]

Thanks, I will give that one a shot and see how well it works. Josh (talk) 22:13, 19 July 2024 (UTC)[reply]

^-- this is important because of how parsing and nesting may work; especially if you are trying to input something dynamic, and use the output as in input to something else. Writing a lua to purely take some pieces of raw text (so long as they are not very long), sort, and display the first value isn't super hard -- however it may need to be written in different ways depending on if the inputs are just text and the format of the output. For example if the inputs are {bravo,[[alpha]],charlie,alphabet} does the link need to be delinked, or should the brackets be sorted? — xaosflux ^Talk 14:39, 19 July 2024 (UTC)[reply]

That makes sense. For my application, it will be getting raw text in all lowercase. Initially it should be only two values, but it would be nice if that had growth potential to all for more (as {{min}} does). I would not think any de-linking or other such formatting would be required on the function side. Josh (talk) 15:00, 19 July 2024 (UTC)[reply]

Thank you everyone for the input. The following code does the trick exactly:

local p = {}
:p.main = function ( frame )
:	str1 = frame.args[1]
:	str2 = frame.args[2]
:	if str1 < str2 then
:		return str1
:	else
:    	return str2
:	end
:end
:return p

Thanks! I've created a simple template here to use it. Josh (talk) 02:40, 20 July 2024 (UTC)[reply]

Mediawiki errors

Tracked in Phabricator
Task T370304

Has anyone else been experiencing MediaWiki errors? I tried a few projects and got them across the board. I hope it's over now. ꧁Zanahary꧂ 00:18, 19 July 2024 (UTC)[reply]

I was also getting an error. I don't remember the exact error but it did start with MediaWiki: Wikimedia\Rdbms\[error name] I think it was DBUnexpectedError J2UDY7r00CRjH (talk) 00:23, 19 July 2024 (UTC)[reply]

I get this:

MediaWiki internal error.

Original exception: [34ac1401-8578-4b58-a1be-36b1278fa8bf] 2024-07-19 00:14:57: Fatal exception of type "Wikimedia\Rdbms\DBUnexpectedError"

Exception caught inside exception handler.

Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.

It has been happening on and off for about 10 minutes. PrimeHunter (talk) 00:28, 19 July 2024 (UTC)[reply]

I got that when I was previewing an edit, and another time when (IIRC) I just visited a user page. ClaudineChionh (she/her · talk · contribs · email) 00:32, 19 July 2024 (UTC)[reply]

Help, I'm drowning. It keeps happening every edit I make! The edits do seem to go through though, so there's that. Silver seren^C 00:44, 19 July 2024 (UTC)[reply]

I cannot make this edit logged in. I got the error several times, changed my theme to Minerva, changed my theme to Vector 2022, and now cannot open any page while logged in. It's fine (I think?) logged out, and the Android app works but can't post to this page, 2600:1702:1C50:1360:18FA:42C0:F510:BE6A (talk) 00:48, 19 July 2024 (UTC)[reply]

I have the exact same problem. 2001:BB6:3084:2658:F14B:6D9A:F011:5C09 (talk) 00:53, 19 July 2024 (UTC)[reply]

I am getting this too. I was not happening earlier today (Two hours ago). Looks like WP:THURSDAY. Hawkeye7 (discuss) 00:52, 19 July 2024 (UTC)[reply]

It's not letting me delete any pages or posts responses to talk page comments. Frustrating. Liz ^{Read! Talk!} 00:56, 19 July 2024 (UTC)[reply]
except for this one. Liz ^{Read! Talk!} 00:57, 19 July 2024 (UTC)[reply]
The discussions I initiate are particularly robust and bugs know to leave them alone, out of reverence and disinterest. ꧁Zanahary꧂ 01:01, 19 July 2024 (UTC)[reply]

The last page deleted happened at 00:22 UTC which was 50 minutes ago. Liz ^{Read! Talk!} 01:02, 19 July 2024 (UTC)[reply]
Okay, some functionality for admins has returned. Liz ^{Read! Talk!} 01:05, 19 July 2024 (UTC)[reply]

I had three almost identical messages like these, with different exception codes:

[f1541cf5-6bd5-4dac-bb64-7cff625c7692] 2024-07-19 00:40:42
[ec5f67e0-1672-48da-8f70-a53aecdb9ad3] 2024-07-19 00:42:17
[18674d8b-749c-40be-9138-0eba30011100] 2024-07-19 00:46:26

In between edits #1 and 2, I managed to save one edit. In trying to publish this edit, I got 1 2 3 more of these. Mathglot (talk) 00:56, 19 July 2024 (UTC)[reply]

Fyi, exception codes are always different. One per page load. Even if the error msg is the same. I think they correspond to error log entries. –Novem Linguae (talk) 19:58, 19 July 2024 (UTC)[reply]

Same, so dead. Can't navigate, edit, or view hardly any page when logged in without getting that error/warning page. Hope this gets fixed soon. 2606:A800:CD82:9700:1DE4:7632:6615:835C (talk) 00:57, 19 July 2024 (UTC)[reply]

Yeah, I'm the same. I can't do anything when logged in. The iOS app appears to be working fine though. 2001:BB6:3084:2658:F14B:6D9A:F011:5C09 (talk) 00:59, 19 July 2024 (UTC)[reply]

https://phabricator.wikimedia.org/T370304. Nurg (talk) 01:03, 19 July 2024 (UTC)[reply]

I'm the user who mentioned the iOS app above. Everything appears to be working okay now. Bertaut (talk) 01:06, 19 July 2024 (UTC)[reply]

I was about to ask whether anyone else had seen these errors. I don't think that I need to ask the question. It appears to have been resolved.

The question now is what happened and whether a recurrence can be prevented. Robert McClenon (talk) 02:36, 19 July 2024 (UTC)[reply]

According to some logs on IRC the database serving S4 (Commons) went down. For reasons I don't quite understand that caused pages with no relation to Commons to fail. Probably the devs will write up some docs on what happened soon. * Pppery * _{it has begun...} 19:24, 19 July 2024 (UTC)[reply]

The IP information tool appears to be down, showing only "The IP information could not be retrieved." I wonder if that's related. CMD (talk) 08:00, 19 July 2024 (UTC)[reply]
Not related. * Pppery * _{it has begun...} 19:24, 19 July 2024 (UTC)[reply]

phab:T363118 –Novem Linguae (talk) 19:57, 19 July 2024 (UTC)[reply]
Aww, I really hoped it was not the previous April/May issues. CMD (talk) 03:32, 20 July 2024 (UTC)[reply]
Idea: 2024 CrowdStrike incident. I hope not, because that would mean that we depend upon Microsoft. --Redrose64 🌹 (talk) 19:14, 19 July 2024 (UTC)[reply]
No, not related. * Pppery * _{it has begun...} 19:24, 19 July 2024 (UTC)[reply]

I thought I'd lost two or three hours of work on Timeline of the attempted assassination of Donald Trump, i.e. the entire new article. When I set about to begin it anew this morning, lo! It was all there! Passingly strange and a P.I.T.A. kencf0618 (talk) 16:59, 20 July 2024 (UTC)[reply]

I'm seeing this problem again. It's not letting me post some talk page messages. Let's see if this gets posted. Liz ^{Read! Talk!} 01:23, 21 July 2024 (UTC)[reply]
Weird, my message gets posted but I still am receiving error messages at the same time as if it didn't post. Liz ^{Read! Talk!} 01:24, 21 July 2024 (UTC)[reply]
I'm experiencing this occasionally still. It could be a caching issue on my end from earlier errors I experienced this morning, though. Frustrating. Thankfully my talk page messages still seem to go through (eventually). GhostOfNoMeme 13:01, 21 July 2024 (UTC)[reply]
I currently can't open any pages while logged in. My account is basically disabled because of this. Are there any updates? 95.164.181.95 (talk) 01:28, 21 July 2024 (UTC)[reply]

Folks are on it

I'll just note that the phab ticket is currently marked "Open, In Progress, Unbreak Now!". Translating from techno-speak, that basically means, "We know about it, we're working on it, and it's our highest priority issue at the moment". So we should just get out of their hair and let them work on it. RoySmith (talk) 16:47, 21 July 2024 (UTC)[reply]

And it's the weekend so while some of WMF's site reliability engineering team remains on-call to deal with outages probably fixing things is a higher priority than reporting the incident. * Pppery * _{it has begun...} 17:40, 21 July 2024 (UTC)[reply]

Error message

MediaWiki internal error

What does this mean? — Maile (talk) 01:30, 21 July 2024 (UTC)[reply]

See #Mediawiki errors. It means that things beyond your control are down, and there's nothing you can do about. The WMF people responsible for fixing the issue have already been notified. * Pppery * _{it has begun...} 01:36, 21 July 2024 (UTC)[reply]

Thanks for the quick reply. At least I know I didn't trigger it. — Maile (talk) 01:39, 21 July 2024 (UTC)[reply]

What's going on? I'm new here and could use some help.United StatesẂÈĎ

§ᛵᛠᙱᙳ@Maile66@Pppery Will;Draku (talk) 08:21, 21 July 2024 (UTC)[reply]

MediaWiki internal error.

I have been getting repeated "MediaWiki internal error.

Original exception: [d0d3b60c-5f72-4e07-ae15-3451f56eefcf] 2024-07-21 21:00:09: Fatal exception of type "Wikimedia\Rdbms\DBUnexpectedError"

Exception caught inside exception handler.

Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information."

messages tonight, had them last night too. the bit inside the square brackets changes each time. Happens when I click on a page link on my watchlist. Edge on Win11, also happens on Chrome on Android. DuncanHill (talk) 21:07, 21 July 2024 (UTC)[reply]

I just had this, I would assume this is the same as #Mediawiki errors, although https://www.wikimediastatus.net/ is showing something happened.Terasail ^[✉️] 21:11, 21 July 2024 (UTC)[reply]

Only affects me while logged in. It's surreal looking at Special:Recentchanges and seeing a page full of only ip edits. —Cryptic 21:14, 21 July 2024 (UTC)[reply]

See the #Mediawiki errors thread above. Things were good for the past day or so, then another big spike of errors around 2100 UTC (i.e. about 20 minutes ago). RoySmith (talk) 21:20, 21 July 2024 (UTC)[reply]

List of pages containing sic with hide

How can I generate a list of pages containing {{sic}} with the optional |hide= argument? -- GreenC 05:19, 19 July 2024 (UTC)[reply]

The "monthly report" in the TemplateData section is sometimes helpful. This list might be what you want. It's based on the monthly database dump, so it won't be current. The most recent report shows 4,277 articles. – Jonesey95 (talk) 05:47, 19 July 2024 (UTC)[reply]

You can also try a live search like hastemplate:sic insource:hide insource:/\| *hide *=/ PrimeHunter (talk) 09:05, 19 July 2024 (UTC)[reply]

Thanks (and for {{search link}} I'd not seen before). My goal is to find uses of {{sic}} embedded in URLs ie. hastemplate:sic insource:hide insource:/\| *hide *=/ insource:/[-]\{\{sic/, has about 80. To get them all I'd probably need to change the last regex to insource:/[^ ]{{sic/ then use a bot to see if it's in a URL, in which case might as well use the larger number from Jonesey95. Only trying to understand how widespread this intractable problem is. Employing {{sic}} or not in these situations is a bad choice either way, and I don't see a good solution. If you don't add {{sic}} then users and user scripts/AWB etc search and replace misspellings, breaking the URL. If you do add {{sic}}, it breaks bots and tools which can't parse multiple encoding schemes, it violates the IETF RFC on URL encoding standards. In theory bots and tools should account for it, but it's an edge case and difficult to program for, I'd be surprised if any tools or bots are aware of it. -- GreenC 15:11, 19 July 2024 (UTC)[reply]

@GreenC: {{nobots}} may be of use. Polygnotus (talk) 23:52, 19 July 2024 (UTC)[reply]

I don't think {{nobots}} would make sense here. Even {{bots|deny=AWB}} would probably be excessive. WP:SPELLBOT basically prohibits spell-checking bots, and if a human editor is using AWB or some other tool or script (or even manual "fixing") to break URLs while spell-checking then WP:MEATBOT would apply if they refuse to be more careful with their edits. Anomie ⚔ 13:01, 20 July 2024 (UTC)[reply]

OTOH, I suspect the editors adding {{sic}} inside URLs aren't trying to stop bots or scripts from fixing them so much as trying to clear a search for misspellings as they fix the ones that can correctly be fixed. Checking the first few from GreenC's search above finds all were added by User:Federhalter, so pinging him in the hope he will elucidate his process and he and GreenC can come to a better solution. Anomie ⚔ 13:14, 20 July 2024 (UTC)[reply]

OK thanks for pinging Federhalter, hope they respond.

Using this template or not has deleterious effects over the long term. How many URLs have been silently broken by spell checkers, we never know. How many URLs have been mangled by bots, or link rot incorrectly detected, because of the template. My intuition is the spell checker problem is more common because there are more editors running spell checks; and we hope bot writers are more expert to deal with the template. The template thus might have the advantage, though neither is a good solution. -- GreenC 16:32, 20 July 2024 (UTC)[reply]

Indeed, these edits were a (misguided) attempt to exclude misspellings from search results, e.g. Carribean insource:/carribean/i. At the time I was unaware this can cause problems. I learned since then. The reason for including the parameter 'insource' in the first place, instead of simply using Carribean, is that the latter returns (a lot of) results which are only a "redirect from" a misspelled title and do not contain an actual misspelling. I could not yet find an alternative search method for fixing this. Federhalter (talk) 07:05, 21 July 2024 (UTC)[reply]

Sunsetting of goo.gl

Moved to Wikipedia:Link rot/URL change requests § goo.gl

– PrimeHunter (talk) 08:58, 19 July 2024 (UTC)[reply]

Background color in edit textarea for dark mode

When I edit admin-protected pages like Template:Disambig editnotice, I get nearly-white text on a very light pink background, and it's nearly invisible. Does anyone know where this color is set? Is that part of the skin CSS?

BTW, I added class=skin-invert to that template, but the results are pretty ugly in dark mode. It (and many other templates) could probably use upgrading to CSS variables with the palette from [3], though it's very difficult for me to edit it safely at the moment. -- Beland (talk) 03:46, 20 July 2024 (UTC)[reply]

I've thrown Something at the problem now that I've been reminded about at least 5% of why I asked for int admin back. We're going to need to refine colors, these don't necessarily mesh well with syntaxhighlighting, which is still a known problem child. Izno (talk) 04:07, 20 July 2024 (UTC)[reply]

(Alternatively, we can ditch the pink for editing protected things and just use the base colors, but IDK how that will go down with Everyone.) Izno (talk) 04:10, 20 July 2024 (UTC)[reply]

The pink reminds me that I'm editing a protected page, and that I need to exercise extra caution. --Redrose64 🌹 (talk) 08:13, 20 July 2024 (UTC)[reply]

This discussion prompted me to post a bug report: MediaWiki talk:Common.css § Pink background-color for protected pages doesn't work without CodeMirror. —⁠andrybak (talk) 12:20, 20 July 2024 (UTC)[reply]

FTR, andrybak's problem turned out to be a conflict with a gadget; see mw:User talk:Remember the dot/Syntax highlighter.js#Inline styles interfere with enwiki's CSS. -- Beland (talk) 18:58, 21 July 2024 (UTC)[reply]

I know what the purposes of the background is, I am just about convinced however that it isn't valuable to load for every user in the groups of interest. Izno (talk) 16:34, 20 July 2024 (UTC)[reply]

I'm now getting white text on a dark red background in dark mode, which makes things a lot easier to edit in dark mode. Many thanks! I'm still curious where this fix was implemented, in case I run into similar problems elsewhere? -- Beland (talk) 19:03, 21 July 2024 (UTC)[reply]

MediaWiki:Group-sysop.css and MediaWiki:Group-templateeditor.css. Izno (talk) 19:19, 21 July 2024 (UTC)[reply]

Aha, thanks for the pointers! -- Beland (talk) 19:50, 21 July 2024 (UTC)[reply]

As for the BTW, this template strongly needs to reconsider whether it should have the (coffee) color it does. It is intended as a system message (edit intro) and should be colored as expected for that series of templates. It looks like it was added based on "it would be more noticeable", which I think is a miss since most other edit notices are no more noticeable. But particularly to using a Codex color, there are no coffee colors in that palette. Izno (talk) 04:15, 20 July 2024 (UTC)[reply]

I've changed it to "background-color-warning-subtle" from the official palette, which is more or less the same hue. It still ends up as an ugly brown in dark mode, even without "class=skin-invert". Presumably there needs to be an official thinking up of a good subtle warning color for dark mode?

Whether this should be notionally colorized as a warning or as info I'm agnostic about. Looking through the templates in Category:Editnotice templates, the aesthetics are really all over the place. Some templates get attention by having a yellow icon, red icon, yellow border (which is nice even in dark mode), red words as internal headers, yellow background, or pink background. Some have no attention-getting colors at all. Should we start a discussion somewhere about making the visual conventions more uniform? If these are all going to need to be converted to use the new official palette, they'd need to be adjusted anyway. -- Beland (talk) 19:22, 21 July 2024 (UTC)[reply]

I wouldn't be surprised by an ugly brown being the flip for yellow. Using the skin-invert class should be used only for non-flipping colors, and this isn't one of those.

We don't need to convert to Codex per se, we just need to be sensitive to what colors we have and are providing in multiple color themes now. Having a standardized color scheme (which we in fact already have for the message box series, though as you point out it is often customized) is one way to be successful at that objective by default. Adding the customizations that we do is the issue, and could be solved either by removal of those colors, making some other standard templates/templatestyles, or using upstream variables from Codex or even Common.css. A discussion about the customizations is probably warranted somewhere, but I don't know how many people are interested in that kind of topic - often there is resistance along the lines of "it looks like how I wanted" (which would echo refrains from when the message boxes were standardized nearly 20 years ago). Izno (talk) 19:35, 21 July 2024 (UTC)[reply]

Unstrip post-expand size limit

Hello, I'm working on a fairly large page that may be coming up against some technical limits. One may be the Unstrip post-expand size. But I can't say I understand much about this datum and the help files don't say much. Do these stats look problematic? Except for the Unstrip post-expand size value none are more than about 50% of the limit.

Post-expand include size 1,155,959/2,097,152 bytes Template argument size 9,599/2,097,152 bytes Highest expansion depth 16/100 Expensive parser function count 37/500 Unstrip recursion depth 1/20 Unstrip post-expand size 4,254,075/5,000,000 bytes

My understanding is that the Post-expand include size is a hard limit, but don't know about Unstrip post-expand size. Mr. Swordfish (talk) 21:55, 20 July 2024 (UTC)[reply]

See Help:Template limits#Unstrip post-expand size and mw:Manual:Template limits#Unstrip post-expand size. You may lose styling from TemplateStyles at the end of the page if the limit is broken. The latter link also says "some other extensions implemented in a similar manner". I don't know which extentions can be affected. I have never encountered this limit in practice. Category:Pages where the unstrip size limit is exceeded only lists two articles and 13 other pages. The bottom of List of Android smartphones currently shows what can happen when navbox styling is lost from Template:Android (operating system). Which page are you referring to? PrimeHunter (talk) 22:38, 20 July 2024 (UTC)[reply]

Thanks for your prompt reply. The two links you provided say the same thing, and don't tell me much. I'd already read the first one.

The page in question is List of common misconceptions. See the next thread. Mr. Swordfish (talk) 01:48, 21 July 2024 (UTC)[reply]

The large Unstrip post-expand size mainly comes from numerous citations loading Module:Citation/CS1/styles.css. If it was blank then List of common misconceptions would use 1,640,908 instead of 4,298,458 of the allowed 5,000,000 bytes. Maybe we should try to reduce the impact of loading it. PrimeHunter (talk) 20:58, 21 July 2024 (UTC)[reply]

Does that count include the comments in that css file? Maybe it would help just minimizing it to a styles.min.css, and loading that instead? --rchard2scout (talk) 21:27, 21 July 2024 (UTC)[reply]

No, it's the minimized CSS that's counted. Anomie ⚔ 23:23, 21 July 2024 (UTC)[reply]

Surely enough page views have at least one citation on them that it would make sense to merge that into the main MediaWiki:Common.css. —Cryptic 21:45, 21 July 2024 (UTC)[reply]

MediaWiki talk:Common.css/to do#description has a discussion about why we should prefer TemplateStyles categorically. But specific to numbers, no, we have something like 60 million pages and only 6 million of them carry a CS1 template.

I would object to changing anything here, for both the reasons espoused in the to do page and because we should not change general templates to suit the whims of arbitrary edge case pages. There are approximately 3 main space pages which are hitting an issue with this limit. Reduce their size per WP:SIZE/WP:SPLIT as expected of such pages. This is the standard response to such hard limits as are imposed by the software. To be honest, I'm shocked that any pages hit the unstrip limit, it's very hard to do that (almost always, a page will hit WP:PEIS first). Izno (talk) 01:38, 22 July 2024 (UTC)[reply]

Maybe adding the styles to {{Reflist}} can be a possible solution? Gonnym (talk) 03:48, 22 July 2024 (UTC)[reply]

Citations are used outside of reflist and on pages without the reflist template all the time. Izno (talk) 04:14, 22 July 2024 (UTC)[reply]

I can't find it now, but some years ago I expressed a concern that if a template was used multiple times then multiple copies of its template styles would be loaded. I was assured that this could not happen, only the first instance would be processed. It now seems that I was misinformed. --Redrose64 🌹 (talk) 22:30, 21 July 2024 (UTC)[reply]

Only the first instance in the page is served to the browser. The situation here, on the other hand, is counting on the server before the deduplication happens. See my comment in the section below for details. Anomie ⚔ 23:23, 21 July 2024 (UTC)[reply]

PEIS question

We have a question at Talk:List of common misconceptions#Split proposal about Help:Template limits. This is one of our largest pages, with 569,144 bytes of wikitext, 869 refs, and 1,220 templates. I think it would be best to answer it over there. WhatamIdoing (talk) 22:20, 20 July 2024 (UTC)[reply]

The post-expansion inclusion size of that page is currently a bit above 50% of the limit. so that should not be much of an issue. OTOH, the Unstrip post-expand size is over 80% of the limit, which may or may not be an issue. See the previous thread. Yeah, we could use some informed technical advice, either here or at the talk page there. Mr. Swordfish (talk) 01:45, 21 July 2024 (UTC)[reply]

Looks like much of the "Unstrip post-expand size" is it counting every repetition of the TemplateStyles stylesheets, even though these are deduplicated before the article is sent to the browser (somewhat unfortunately that's the direction T160563 wound up going in). Which means, for example, the minified version of Module:Citation/CS1/styles.css is counted 1113 times even though it's only included in the page output once. If the limit winds up being exceeded, then TemplateStyles <style> tags at the end of the article (like for the portal bar) might wind up broken. "Manual" deduplication for the cite template styles (i.e. sticking one <templatestyles src="Module:Citation/CS1/styles.css" /> before the <references /> and passing an arg to all the cite templates to have them not include that) might work, but in more general cases you'd want to be careful that the on-demand section loading for the mobile apps (if they still do that) doesn't break. Anomie ⚔ 13:13, 21 July 2024 (UTC)[reply]

Database error

Attempting to post a reply on a talk page, and it fails to post, with the error:

[81c7ca0f-eea1-42f7-8924-5a63e7dbb4cf] Caught exception of type Wikimedia\Rdbms\DBUnexpectedError

I'm betting I'll probably get the same error while trying to report this error... cheers. anastrophe, an editor he is. 01:29, 21 July 2024 (UTC)[reply]

And it posted, and the post on the talk page went through on a retry just now. Whee! cheers. anastrophe, an editor he is. 01:29, 21 July 2024 (UTC)[reply]

Issue with archive bot (Lowercase sigmabot III)

I think something may be wrong with Lowercase sigmabot III. Looking at its contributions, it only archived 4 talk pages on the 19th, about 80 on the 20th, and only 4 so far today. For comparison, it usually seems to archive many hundreds or thousands (for example on the 18th it archived well over 700). Any insight? GhostOfNoMeme 09:28, 21 July 2024 (UTC)[reply]

Please contact the bot owner, they are the only one who can change/check the bot. —TheDJ (talk • contribs) 10:28, 21 July 2024 (UTC)[reply]

Unfortunately, they seem MIA. No edits for 2 years, and no response to past messages on their talk page. I suppose there's nothing that can be done. GhostOfNoMeme 10:36, 21 July 2024 (UTC)[reply]

That's pessimistic, GhostOfNoMeme. Well, the bot didn't start on the 19th, and I can't tell why, but it hasn't reoccurred, so let's not worry about it for now. On the 20th it ran into an issue partway through its run. I've put in a workaround so that is less likely going forward. And today it's been running fine. (It doesn't start until 12:00 UTC, so that's why you didn't see any activity when you started this thread.) — The Earwig (talk) 23:27, 21 July 2024 (UTC)[reply]

Toolsadmin suggests that 0xDeadbeef and The Earwig might be undocumented co-operators. * Pppery * _{it has begun...} 15:31, 21 July 2024 (UTC)[reply]

Thanks, Pppery. I added myself as a co-maintainer on the bot's userpage. — The Earwig (talk) 23:22, 21 July 2024 (UTC)[reply]

This may be phab:T370603. --Redrose64 🌹 (talk) 21:18, 21 July 2024 (UTC)[reply]

Seems unrelated, unless IABot is also having issues due to high maxlag. — The Earwig (talk) 23:28, 21 July 2024 (UTC)[reply]

Fix Infobox: Dylan Dog

I'm not sure if this is the correct place to post a request. Could someone please check the page Dylan Dog and fix the infobox? I'm a bit out of practice with formatting standards. Also, what would have been the correct place to make this request? Thanks! 100.19.66.49 (talk) 15:30, 21 July 2024 (UTC)[reply]

Seems it was fixed here [4] and WP:HELPDESK would have been a righter place. I remember reading that comic. Gråbergs Gråa Sång (talk) 16:38, 21 July 2024 (UTC)[reply]

Dark Mode Text

In dark mode, at {{Soulfly}}, the actual link for Soulfly is an extremely dark grey that is difficult to see on a black background. Also, when editing, anything that is NOT a link is grey text on a white background. It was not this way before. Does anyone know how to fix this? --Jax 0677 (talk) 21:35, 21 July 2024 (UTC)[reply]

I get the same result. Any unvisited link is a helpful blue on a black background. Any visited link is dark gray (#202122, if I am reading my inspector correctly) on a black background (#101418, I think, which is "--background-color-base"). My inspector says that the contrast ratio is 1.14. – Jonesey95 (talk) 23:29, 21 July 2024 (UTC)[reply]

Reply - Thank you very much for your feedback. I think that the first issue may be exclusive to {{Navbox musical artist}}. And now we wait, I suppose... --Jax 0677 (talk) 23:32, 21 July 2024 (UTC)[reply]

Jdlrobson made some edits to {{Navbox musical artist}} about a week ago that added color: #202122 to several parameter styles. I'm still using the Dark Mode gadget rather than the Foundation version, and I'm not experiencing the issue in Vector 2022. Folly Mox (talk) 10:17, 22 July 2024 (UTC)[reply]

Screen blacking-out on mobile app

So I rrecently used my iPhone to access the Teahouse and the scrreen flickered between normal and black for about 10 seconds before going all black. Restarting the app doesn't fix this either. Unfortunately I have no image of this, but to describe it:

The screen would flicker between being able to read, then white, then flickering black.
Then the screen would stop flickering and go all-black. This isn't an issue with my device, as only a few pages within the Wikipedia app in specific do it.
Every part of the screen was black except the upper search bar and the Wikipedia logo.
Then I atttempted to restart the app and see if the glitch would go away, but it kept doing it.

I noticed that extremely long pages or threads will completely black-out iPhone screens (including the Teahouse, which is notoriously long). This can be a serious issue when trying to access something in-the-moment, and the Teahouse still is completely broken on my phone. I have no idea if this is even a Wikipedia-side issue, but yea. Just anted to make ya'll aware of this. I'll try to get an image tomorrow, it's prretty hard to explain. Sir MemeGod ._. (talk - contribs - created articles) 04:16, 22 July 2024 (UTC)[reply]

Also I do apologize if this was the wrong place to report this. (I'd report it to Phabricator but I've never been able to access it due to a separate and unrelated glitch) Sir MemeGod ._. (talk - contribs - created articles) 04:18, 22 July 2024 (UTC)[reply]

MemeGod27, issues specific to the iOS app might get a more informed response at mw:Talk:Wikimedia Apps or at the technical support email address listed at :mw:Wikimedia Apps/iOS FAQ § If I have a question or a suggestion, how do I get in touch? Folly Mox (talk) 10:27, 22 July 2024 (UTC)[reply]

Cellullar data drain

Apologies if this is not the right place for my query. While using the Wikipedia app on iOS with a 4G connection, I received a notification from my provider stating I had only 5GB left in my data package. Eight minutes later, I received another message saying my data package was completely used up. Upon checking my cellular usage settings, I found that the Wikipedia app had consumed 6.8GB of data in just about 10 minutes. What could be the cause of this? 141.196.107.237 (talk) 05:08, 22 July 2024 (UTC)[reply]

Could be that you looked at pages with many large images? Jo-Jo Eumerus (talk) 06:11, 22 July 2024 (UTC)[reply]

141, do you happen to have a large Reading List of articles saved for offline viewing? Is it possible that it was syncing across devices or refreshing its contents for another reason?

I'm afraid most of us editors at English Wikipedia have very little experience with the apps, since they don't support full editing functionality. Someone here may have answers for you, but in case none are forthcoming, you could always ask the iOS app team directly at mw:Talk:Wikimedia Apps or at the technical support email address listed at :mw:Wikimedia Apps/iOS FAQ § If I have a question or a suggestion, how do I get in touch? Folly Mox (talk) 09:58, 22 July 2024 (UTC)[reply]

TemplateStyles CSS help: `tbody tr:first-child {<css attributes>}`

Courtesy link: Wikipedia:Copying text from other sources § Can I copy from open license or public domain sources?
Courtesy link: Draft:License compatibility

If that subject line does not look cryptic to you, I would love to have your advice. I am trying to spin off the table about License compatibility that you can view here, into a template so I can use it in multiple articles, and add user-configurable style, and I am running into problems using CSS to reproduce the blue background in the first row. Currently, the template is at Draft:License compatibility. I am busy on two tracks: adding parameters for user stylability, and moving the original style to Draft:License compatibility/styles.css as default style. In trying to reproduce the original table style with the blue background and bolded white font in the top row as seen here, I tried the following at Draft:License compatibility/styles.css:

.lic-comp tbody tr:first-child {
	background-color:blue;
	color:white;
}

but it doesn't seem to be working properly; instead of rendering the top row with blue background, it is rendering the *second row* with blue background, and I don't understand why. Thanks for any tips you can offer. Mathglot (talk) 09:33, 22 July 2024 (UTC)[reply]

All rows in a wikitext-generated table are in <tbody>, not <thead>, even if the first one(s) include only <th>s. If the table is sortable, jquery.tablesorter puts the first row in <thead> for JavaScript-enabled users. You should probably add a class to the row itself rather than rely on a pseudo-class. Nardog (talk) 09:45, 22 July 2024 (UTC)[reply]

Thank you very much from this response. The table is non-sortable. When I look at the generated Html, I see this:

Html for table

<table class="wikitable lic-comp">
<tbody><tr>
<th colspan="2">License Compatibility with Wikipedia<sup id="cite_ref-1" class="reference"><a href="#cite_note-1">[1]</a></sup>
</th></tr>
<tr>
<td><span class="heading">Licenses compatible with Wikipedia</span>
</td>
<td><span class="heading">Licenses <i>not</i> compatible with Wikipedia</span>
</td></tr>
<tr>
<th scope="row" colspan="2"><span class="lic-comp-label">Creative Commons licenses</span>
</th></tr>
<tr style="vertical-align: top;">
<td>
<ul><li>CC BY, all versions and ports, up to and including 4.0</li>
<li>CC BY-SA 1.0, 2.0, 2.5, 3.0, 4.0</li>
<li><a rel="nofollow" class="external text" href="https://creativecommons.org/share-your-work/public-domain/cc0/">CC0</a></li></ul>
</td>
<td>
<ul><li>CC BY-NC</li>
<li>CC BY-NC-ND</li>
<li>CC BY-ND</li>
<li>CC BY-NC-SA</li></ul>
</td></tr>
<tr>
<th colspan="2"><span class="lic-comp-label">Other licenses</span>
</th></tr>
<tr>
<td>
<ul><li>GFDL <b>and</b> CC BY or CC BY-SA</li></ul>
</td>
<td>
<ul><li>any GNU-only license (including GFDL)</li></ul>
</td></tr></tbody></table>

so it seems like the first tr child should be the top row, not the second one. Are you saying that jquery alters the Html after the capture posted here from right-click, view page source? Mathglot (talk) 09:55, 22 July 2024 (UTC)[reply]

If it's sortable, yes. I know it doesn't pertain to this table since it's not a data table and so is unlikely to be made sortable, but it's good practice to not rely on :first-child or :nth-child to select header rows because jquery.tablesorter modifies them for a subset of users. Nardog (talk) 10:00, 22 July 2024 (UTC)[reply]

Thanks. I'll try a different approach, although I'm not sure how to address a row in a wikitable, unless I convert it to an Html table first, and then I have the row and cell tags available which I can address. Maybe that's where this should go, at this point, unless there is an alternative. Mathglot (talk) 10:08, 22 July 2024 (UTC)[reply]

You can just write |- class="...". Nardog (talk) 10:11, 22 July 2024 (UTC)[reply]

Oh, really? Cool! I don't know how I missed that. I checked Help:Table and Help:Table/advanced and didn't see that. That should provide a solution to this; thanks a lot! (edit conflict) Mathglot (talk) 10:15, 22 July 2024 (UTC)[reply]

Just to say: I find the color unnecessary, distracting and hurting accessibility. Sjoerd de Bruin (talk) 10:12, 22 July 2024 (UTC)[reply]

Sjoerddebruin, you may be right, but as I am spinning off content written by another editor into a Template, I feel like the first effort should exactly reproduce their original design, so I can introduce the template into the article where they originally added the wikitext, without any changes to the rendered page. The parameters being added to the template will provide configurability to other users, to alter it as they see fit. Thanks for your comment. Mathglot (talk) 10:19, 22 July 2024 (UTC)[reply]

I doubt a template like this needs much customization options, what would the use cases be? Sjoerd de Bruin (talk) 10:25, 22 July 2024 (UTC)[reply]

I don't see any blue background or white text. Have you enabled "Make headers of tables display as long as the table is in view" at Special:Preferences#mw-prefsection-gadgets? That also messes with unsortable tables. I get blue background and white text in the top row with this which adds thto your code:

.lic-comp tbody tr:first-child th {
	background-color:blue;
	color:white;
}

PrimeHunter (talk) 10:32, 22 July 2024 (UTC)[reply]

Oh, I must have misunderstood something then. I thought Mathglot was trying to turn "Licenses compatible with Wikipedia" and "Licenses not compatible with Wikipedia" blue. Nardog (talk) 10:40, 22 July 2024 (UTC)[reply]

They are blue now, that is the problem. For starters, I am trying to echo the original, which is here, using templatestyles instead of inline style. So far, I haven't managed to do it. That would be the baseline, from which user configurability could begin. Mathglot (talk) 10:46, 22 July 2024 (UTC)[reply]

At this point, I'm going to take a break, but I should add if anyone wants to play with the template, this is a wiki, so by all means, please try stuff out in the template, or the styles.css, if you have an idea how to progress with this. Thanks, Mathglot (talk) 10:50, 22 July 2024 (UTC)[reply]

I just made the draft table much simpler (and I believe more accessible), feel free to revert if it's too drastic a change. Nardog (talk) 11:09, 22 July 2024 (UTC)[reply]

Oh, in that case it's because the default background applies to <th>, not <tr>, so it takes precedence over your custom style in TemplateStyles. .lic-comp tr:first-child > th is one way to do it. Nardog (talk) 10:50, 22 July 2024 (UTC)[reply]

@Mathglot: You didn't answer whether you have enabled "Make headers of tables display as long as the table is in view". If I enable it then I get the result you describe with blue in the second row. Without it, my code works for me, but it would be better to not rely on which table-altering features are used. PrimeHunter (talk) 11:00, 22 July 2024 (UTC)[reply]

User_talk:Rosiestep#Helen_Hunt_Jackson

Help! I've somehow broken a friend's talkpage so that the indentations have turned into parentheses. I don't know how you even do that.... Adam Cuerden ^(talk)_{Has about 8.9% of all FPs.} 11:35, 22 July 2024 (UTC)[reply]