Jump to content

Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia
 Policy Technical Proposals Idea lab WMF Miscellaneous 
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.

Bot activity problem

[edit]

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?

[edit]

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. — Qwerfjkltalk 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 (talkcontribs) 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". — Qwerfjkltalk 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

[edit]

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]

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

[edit]

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

[edit]

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 (talkcontribs) 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]

 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

[edit]

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

[edit]

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. SilverserenC 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]
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]

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]

Folks are on it

[edit]

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

[edit]

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.

[edit]

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

[edit]

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

[edit]

Background color in edit textarea for dark mode

[edit]

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

[edit]

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

[edit]

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

[edit]

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)

[edit]

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 (talkcontribs) 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

[edit]

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

[edit]

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]