Wikipedia:Village pump (technical)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

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.

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

Edit conflicts with myself

I saw this after an unintentional mouse double-click

Something annoying has started happening lately; this has happened to me multiple times in the last several days.

I click undo to undo another editor's edit, and check the diff, then when I click save I see:

"Someone else has changed this page since you started editing it, resulting in an edit conflict."

That someone else was me, and my edit was successfully saved, despite this message popping up telling me otherwise! wbm1058 (talk) 15:44, 25 October 2023 (UTC)

Do you have a cheap mouse that sometimes gives you two clicks when one would have been enough?

—Trappist the monk (talk) 17:20, 25 October 2023 (UTC)

No, I was on my desktop using a wireless Microsoft mouse; my biggest issue with it is that it burns through batteries too quickly. I suppose I could try intentionally double-clicking to see whether that duplicates the issue. But I've been using the same mouse for years and don't recall having the problem until recently. Is there such a thing as an expensive mouse? Could also be an issue with too many tabs open and bots running using up memory or something. I'd suggest that before claiming "someone else" that the software could do a quick checkuser to confirm that it really was someone else though. – wbm1058 (talk) 13:17, 26 October 2023 (UTC)

OK, I confirmed the cause. My intentional double-click saving the above post duplicated the problem. Wikimedia software should check the user ID or IP address and just ignore the second click when they're the same. – wbm1058 (talk) 13:21, 26 October 2023 (UTC)

Adding a screenshot. The software is obviously confused. The "Stored revision" is exactly the revision before I clicked Publish changes. "Your text" is exactly the change I published. It did publish this change before putting up the Edit conflict: Wikipedia:Village pump (technical) page on my PC. If this is coming from my second click, then why isn't the "Stored revision" what my first click saved, and why wasn't my second click treated as a null edit? wbm1058 (talk) 14:19, 26 October 2023 (UTC)

@Wbm1058: What browser are you using, and on what OS? And are you using the WP:WikEd gadget? This is possibly related to Wikipedia:Edit filter noticeboard/Archive 12#Filter 1253: False positive ratio. I've never been been able to reproduce this (long-standing) self-conflict bug, or the filter bug, in Firefox on Linux. Suffusion of Yellow (talk) 20:01, 27 October 2023 (UTC)

No, I haven't used WikEd in years. I still have some WikEd stuff in my common.css from back when I did some work for another user. Heh, I'm still running Windows 7 and the last version of Google Chrome that runs on 7. I like and still use the Windows Media Center even though it's lost its program directory. And I'm proud that the PC I built from parts (BYOPC) thirteen years ago is still cooking. I don't really know what I'm missing by not having a Windows 11 machine, and I had a machine that ran Ubuntu, which I never came to like as much as Windows, until it died on me. I think I'm gonna get a new rechargeable mouse now that I see that's an option. – wbm1058 (talk) 22:40, 27 October 2023 (UTC)

OK, found this in the source:

                                $this->isConflict = true;
                                if ( $this->section === 'new' ) {
                                        if ( $this->page->getUserText() === $requestUser->getName() &&
                                                $this->page->getComment() === $this->summary
                                        ) {
                                                // Probably a duplicate submission of a new comment.
                                                // This can happen when CDN resends a request after
                                                // a timeout but the first one actually went through.
                                                $editConflictLogger->debug(
                                                        'Duplicate new section submission; trigger edit conflict!'
                                                );
                                        } else {
                                                // New comment; suppress conflict.
                                                $this->isConflict = false;
                                                $editConflictLogger->debug( 'Conflict suppressed; new section' );
                                        }
                                }

Can someone with logstash access check if wbm1058 is triggering lots of Duplicate new section submission; trigger edit conflict!" errors? That would at least narrow down part of the problem (but still doesn't explain why this could happen when undoing an edit). Suffusion of Yellow (talk) 23:37, 28 October 2023 (UTC)

I admit my Logstash skills aren't great, but at quick glance I only found a single entry in the "EditConflict" channel over the past two weeks, and it was not from wbm1058 or even on this wiki for that matter. Here's a permalink for those who have access. There definitely have been more edit conflicts than that, so clearly my query is wrong, or these are intentionally not getting logged. Sorry I'm not of much help! I suggest reaching out to the Editing team or simply filing a bug if this persists. — MusikAnimal ^talk 15:44, 31 October 2023 (UTC)

Update: I bought and started using a $99 rechargeable "gaming (Esports)" mouse (plus: it has "forward" and "back" buttons. minus: now another USB port is tied up, as mouse and keyboard have separate receivers). I tried intentional double-clicks a couple times yesterday, and they worked fine (second click ignored). But then late last night, I unintentionally double-clicked on a "rollback" link, and saw the screenshot posted above. I was tired, miffed at the vandal, whatever, my aging finger got "twitchy". Is there ever a valid use for double-clicks on MediaWiki? I know that some software supports them. If there is never a valid use then whatever the software front end is that's receiving my mouse signals should just ignore any signal received say, less than a second after another signal. – wbm1058 (talk) 12:59, 1 November 2023 (UTC)

Problems with links on Special:NewPagesFeed

Tracked in Phabricator
Task T349850

Tracked in Phabricator
Task T347732

I have since a few days (last Thursday perhaps?) some issues with links on Special:NewPagesFeed, I'll try to describe the most obvious ones. I don't have these issues on other pages (e.g. the watchlist), so it seems to be page-specific and not some general browser issue. I use Windows, Firefox, desktop.

The issues happen especially when the entry on the feed only takes up 2 or three lines (so with only one line of text, or no text at all), not when you get more lines of text. I use "old" vector, widescreen, so this may not happen on "new" Vector which is smaller and thus will probably show more lines of text in most cases.

• Links are very "fussy", I don't get the link-indicator (the link getting underlined and clickable, arrow becomes a hand) across the whole height of the text, but only near the top of the words, across only a few pixels really, when there is only one line of text.
• When there is no text, e.g. with a redirect which is nominated for deletion (in the current feed, the entry for "14:28, 26 October 2023" and below), I get no link at all for the username, talk and contribs links, and a very limited one for the page title. I also get, on the far right, the "Review" button obscuring most of the date.

Fram (talk) 15:34, 26 October 2023 (UTC)

I've noticed it as well. Haven't bothered to write out the problem yet as a Phabricator ticket. It's the new Vue.js-based page triage interface. See Wikipedia:Page_Curation/2023_Moderator_Tools_project#October_20,_2023:_Final_update! for discussion/links. You can use the old one, for now, at <https://en.wikipedia.org/wiki/Special:NewPagesFeed?pagetriage_ui=old>. Skynxnex (talk) 16:44, 26 October 2023 (UTC)

@Novem Linguae ^ Izno (talk) 18:16, 26 October 2023 (UTC)

Thanks for reporting. Special:NewPagesFeed is in the middle of a rewrite and it probably created some bugs. This sounds like it might be T349852: Links for page titles are offset high when a page has no autgenerated summary and T349850 Review button overlapping creation time to me. If so, feel free to add some detail to the tickets. If not, let's try to gather enough info to start a new ticket. –Novem Linguae (talk) 19:50, 26 October 2023 (UTC)

Thank you (all). I don't edit phabricator, too much passive-agressive behaviour from some of the people ruling over there, rules which only get imposed when it suits them and so on. Fram (talk) 07:49, 27 October 2023 (UTC)

I'm planning to include fixes for these as part of the planned redesign :) Wrt to phabricator, I am unsure as to what you are reffering to, but there should be very little friction if you stick to the bug reporting template for PageTriage for anything concerning NPP. Do file bug reports/feature requests, since otherwise it becomes hard to fix the issues and they get lost :( Sohom (talk) 12:23, 29 October 2023 (UTC)

Possible to just get a list of changes to a page?

It'd be really great if there was a way to just get a simple list of changes to a page. Right now you have to weed through 'compare versions', but if there was a way to get an ordered list of additions and subtractions - without all the surrounding text (user, timestamp, changed text) - I believe that would be quite useful. Yes, it won't always make perfect sense, but over all I believe it would, especially for current / ongoing event type pages. Note the summaries on the history page are rarely useful or informative. Wikiqrdl (talk) 18:58, 27 October 2023 (UTC)

You could try a comparison (diff) that includes multiple revisions instead of just one revision at a time. WP:POPUPS is also a good tool for viewing diffs in one's watchlist without clicking on them, saving a couple clicks. Setting one's watchlist to show every diff, grouped together by page, is also a good trick. Then you can uncollapse a page and it will show every individual edit, and you can read edit summaries and use popups to view the ones of interest. –Novem Linguae (talk) 06:07, 28 October 2023 (UTC)

@Wikiqrdl: At Preferences → Appearance → Diffs, disable "Don't show the revision slider". Then when you go to any diff, you get a collapsed box at the top labelled "Browse history interactively". Click that, and it expands, showing a horizontal line across the middle. Bars projecting above the line indicate a net increase in page size; bars projecting below the line indicate a net decrease. Hover your mose over any bar to get date, time, username, edit summary etc. for that edit. You also have two sliders, a yellow and a blue, which you can move about to compare any two revisions of a page; as you move them, the diff shown at the bottom changes to show the cumulative diff. There's more info at mw:Extension:RevisionSlider. --Redrose64 🌹 (talk) 14:47, 29 October 2023 (UTC)

Are scripts like commonHistory and ExpandDiffs what you're looking for? Nardog (talk) 15:31, 29 October 2023 (UTC)

Main page sr.wiki - help needed

Hi. I would like to ask for a help with Serbian Wikipedia Main Page visual output. The problem we encounter is that low lines of boxes with content are not vertically aligned left-with-right and that looks ugly. There is a scratch version at this page, pretty much working except that we do not know how to align buttons and icons and text and three dots to stick to the lower part of any of the boxes i.e. their low line. Please check w:sr:Шаблон:Одељци Главне стране/тест, as well as w:sr:Шаблон:Главна страна/styles.css and w:sr:Шаблон:Одељци Главне стране/styles.css where problem can be resolved by someone who knows how to float css element at the bottom of the div container. This is pretty much what we aim to do. Thank you in advance! — Sadko (words are wind) 20:45, 29 October 2023 (UTC)

@Sadko you want each box on the left to start and begin in the same place as the box on the right? You may use CSS grid. Here's a guide at CSS tricks and a similar guide at MDN. Izno (talk) 20:59, 29 October 2023 (UTC)

As for attaching items to the bottom of a box, see this DDG search which mostly suggests the use of CSS bottom. I don't know if you can use CSS clear with that, which you would probably need to ensure Stuff attached doesn't overlap with other content. Izno (talk) 21:02, 29 October 2023 (UTC)

Ty. fellow editor Izno. I'll write to you some more if I have any more questions. Thanks once again.. — Sadko (words are wind) 00:44, 30 October 2023 (UTC)

Reference tool cannot reuse citations from infobox

The new reference tool is so much better than manually typing and copying the <ref name=...>, but I noticed that references defined in templates do not show up on the list of existing references that I can reuse. C9mVio9JRy (talk) 07:27, 30 October 2023 (UTC)

Edit count

I'm not happy with the public disclosure of my edit count in my contributions as if edit count is a defining feature of an editor's worth. The vast bulk of my edits were done as a virtual bot over ten years ago. I think I and other editors should have the right not to disclose our edit count to the general public in our preferences.♦ Dr. Blofeld 13:47, 30 October 2023 (UTC)

The feature was added under phab:T324166. --Redrose64 🌹 (talk) 14:43, 30 October 2023 (UTC)

I understand your wish but the problem is the assumption that lots of edits = worthy person. My edits are also mainly minor but, for those who make such misjudgements, my edit count flatters rather than upsets me. I'd be more worried about someone who has a few dozen edits, each one a decent article which took weeks to write, but is mislabelled as an insignificant newbie. Certes (talk) 15:00, 30 October 2023 (UTC)

No new private information is being disclosed here, Special:Contributions has always been able to identify all of someone's edits and anyone would have been able to readily count them at any time. As far as the concept of being able to hide your quantity of edits from review - the quantity is simply a side effect of them existing, and having all of your contributions transparently available to any and everyone is a core principal of the project. — xaosflux ^Talk 15:07, 30 October 2023 (UTC)

User contributions also have edit count links. If you don't want to see the edit count of other users directly on their contributions page then add this to your CSS:

.mw-contributions-editor-info {display:none;}

It also hides the account creation date which doesn't have a separate class. I don't expect there would be support for adding this to the default CSS of the English Wikipedia. If we want to give users a choice to hide their own count from others without a MediaWiki change then it would require extra JavaScript to run for all users. I don't think this purpose is worth that. And without a MediaWiki preference the choice would have to be stored somewhere else like a user subpage or a central list. PrimeHunter (talk) 16:15, 30 October 2023 (UTC)

Thanks PrimeHunter, yes it's not something I want to see for other editors either! The point though Xao is that I don't mind people checking if they really want to, but I disagree that it's necessary to disclose this information to everybody every time they click on an editor's contributions, and would argue that it actually runs the risk of worsening Editcounteritis and people trying to quickly notch up a lot of edits to look more valued on here. ♦ Dr. Blofeld 17:26, 30 October 2023 (UTC)

@Dr. Blofeld if there is consensus, we could hide this client-side for all users via local CSS hack. Personally, I'd be opposed to that on the basis of not including more display hacks that could cause page jumping, but it could gain support. — xaosflux ^Talk 17:45, 30 October 2023 (UTC)

It was well-supported at the community wishlist survey in 2022. –Novem Linguae (talk) 18:29, 30 October 2023 (UTC)

@Xaosflux: For that matter, if we wanted to we could edit MediaWiki:contributions-edit-count to prevent the count from being included in the first place. Anomie⚔ 19:53, 30 October 2023 (UTC)

@Anomie yup, that would turn it off for everyone. We could also add some hint text in there, such as to Wikipedia:Edit count that explains the subject more. @Dr. Blofeld - think adding such a link would help? — xaosflux ^Talk 20:00, 30 October 2023 (UTC)

And of course, the link parser doesn't work there - so if we want this to be anything other than plain text we will need a feature request (unless Novem Linguae wants to just start working on this some more :D ) — xaosflux ^Talk 20:12, 30 October 2023 (UTC)

Perhaps it would be worth a debate to see what the general outlook is, given a possible risk of it encouraging editcounteritis, even if people generally don't find it invasive. The problem with disclosing raw edit count is that it doesn't say anything about what you've edited and type or quality of edits and puts AWB or bot-type mass edits and talk/wiki page edits on par with really substantial content additions to the project. I think I have less than 100k edits in the last 13 years on here!♦ Dr. Blofeld 17:54, 30 October 2023 (UTC)

I would say though that most editors have WP:POPUPS installed which by default shows the edit count of any user by simply hovering over them. So I don't know how much of a difference this makes. Galobtter (talk) 17:49, 30 October 2023 (UTC)

Personally it's quite useful. Knowing a user's general experience helps phrase any questions I need to ask them. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 18:00, 30 October 2023 (UTC)

There are a lot of editors not using the navigation popups gadget. As of the moment I checked, Special:GadgetUsage shows the navigation popups gadget has been enabled by 58,581 users (other than the default gadgets, topped only by the dark mode toggle). According to Special:Statistics (again, as of the moment I checked), there are 122,331 active users (usres who have performed an action in the last 30 days). (The first number divided by the second is 48%, but that's an upper bound, since the first number isn't restricted to active users.) isaacl (talk) 23:04, 30 October 2023 (UTC)

Just a quick note that "Show edit count at Special:Contributions" was #45 on the community wishlist for 2022 and had 48 supports. The change seems well-supported. Although as the person that wrote the code for it, I am sorry that the change bugs you. –Novem Linguae (talk) 18:26, 30 October 2023 (UTC)

That's odd as in my experience on here there is usually a significant consensus to hide edit counts and discourage people from viewing figures to the point that the old tables were replaced with placeholders or even deleted. Not your fault NovemLingae, if you were following consensus, but I'm surprised that only Bilorv raised a point about its value. and nobody even showed a concern about it potentially encouraging edit counteritis. ♦ Dr. Blofeld 19:10, 30 October 2023 (UTC)

To be fair, the software change for this, and the large support referenced - was for a mediawiki feature, used on all WMF's 800+ projects and non-WMF instances - it wasn't about enwiki; we just get the feature like everyone else does. — xaosflux ^Talk 19:53, 30 October 2023 (UTC)

the old tables were replaced with placeholders or even deleted WP:EDITS isn't hidden, it's updated daily. --Redrose64 🌹 (talk) 19:55, 30 October 2023 (UTC)

I must be thinking of Article count then? I could have sworn Edit count was turned into placeholders too. ♦ Dr. Blofeld 21:01, 30 October 2023 (UTC)

As a demonstration of a possible CSS solution, User:PrimeHunter/Hide edit count.css hides the edit count for a hard-coded list of users who have requested it, currently only Dr. Blofeld. I'm not sure where this will go in the future. Users who want to respect the requests could install it with this in your common JavaScript:

importStylesheet('User:PrimeHunter/Hide edit count.css'); // Linkback: [[User:PrimeHunter/Hide edit count.css]]

There will probably be very few users who install it unless it becomes a gadget or included in something widely used. The edit count will be hidden from Special:Contributions/Dr. Blofeld which is linked in several places in the MediaWiki interface, but not from https://en.wikipedia.org/w/index.php?title=Special:Contributions&target=Dr._Blofeld which is linked by some tools. I don't know whether MediaWiki itself makes any links to the latter. PrimeHunter (talk) 20:53, 30 October 2023 (UTC)

• A note that many people are already using scripts such as User:Amorymeltzer/scripts#User Info, User:PleaseStand/User info, User:Enterprisey/userinfo, m:User:SMcCandlish/userinfo, and m:User:Perhelion/userstatus, which does the same thing as the recently introduced feature (and more, actually). InfiniteNexus (talk) 22:54, 30 October 2023 (UTC)

  Not to mention popups that just have it in the hover. I suppose those are just "opt in" things though... — xaosflux ^Talk 01:36, 31 October 2023 (UTC)

• Templates and parser functions seem to work in MediaWiki:contributions-edit-count. What if we show the exact edit count up to a fixed limit, maybe 10000, and after that show "over 10000 edits". As WP:Requests for adminship/0xDeadbeef suggests, after 10000 edits or so, the community mostly considers edit count to be irrelevant. People who want more detail can still use a script or gadget. Suffusion of Yellow (talk) 00:18, 1 November 2023 (UTC)
• Judging from the wishlist page, I think there is a significant silent consensus, and I would recommend an RFC before making changes that make this patch go from "really buried" (tiny and gray on a special page) to "extremely buried" (blurs after 10,000 edits, feature flag to turn it off, etc.) –Novem Linguae (talk) 03:46, 1 November 2023 (UTC)

  Fully agree. —TheDJ (talk • contribs) 10:24, 1 November 2023 (UTC)

  Yes, it's a useful feature which can be easily ignored and feasibly turned off by the minority who dislike it. The only real objection is from those who don't want their edit count shown despite it being freely available elsewhere. Removing it, either totally or by default, would need consensus. Certes (talk) 13:24, 1 November 2023 (UTC)

This is apropos of nothing, but back in the day, when SomethingAwful posters were starting to let post count get to their head, they made it so that posting in fyad made your post count go down by one every time you did it. Maybe we can do the same with the drama boards etc ;^) jp×g🗯️ 10:12, 3 November 2023 (UTC)

Tech News: 2023-44

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

Recent changes

• The Structured Content team, as part of its project of improving UploadWizard on Commons, made some UX improvements to the upload step of choosing own vs not own work (T347590), as well as to the licensing step for own work (T347756).
• The Design Systems team has released version 1.0.0 of Codex, the new design system for Wikimedia. See the full announcement about the release of Codex 1.0.0.

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 31 October. It will be on non-Wikipedia wikis and some Wikipedias from 1 November. It will be on all wikis from 2 November (calendar).
• Listings on category pages are sorted on each wiki for that language using a library. For a brief period on 2 November, changes to categories will not be sorted correctly for many languages. This is because the developers are upgrading to a new version of the library. They will then use a script to fix the existing categories. This will take a few hours or a few days depending on how big the wiki is. You can read more. [1][2]
• Starting November 1, the impact module (Special:Impact) will be upgraded by the Growth team. The new impact module shows newcomers more data regarding their impact on the wiki. It was tested by a few wikis during the last few months. [3]

Future changes

• There is a proposed plan for re-enabling the Graph Extension. You can help by reviewing this proposal and sharing what you think about it.
• The WMF is working on making it possible for administrators to edit MediaWiki configuration directly. This is similar to previous work on Special:EditGrowthConfig. A technical RfC is running until November 08, where you can provide feedback.

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

MediaWiki message delivery 23:19, 30 October 2023 (UTC)

Oho! Stand by for new threads like "Categories are sorting in the wrong order", as has happened several times before. These may also be posted at VPM, AN and Teahouse. --Redrose64 🌹 (talk) 23:59, 30 October 2023 (UTC)

Didn't we recently get a feature that lets us put a message on the top of every page in a given namespace (originally requested for Draft:, IIRC)? Is it worth putting an alert at the top of Category: pages about this while they're in flux? —Cryptic 03:06, 31 October 2023 (UTC)

It's not in production wikis yet – enabling it on enwiki needs another phab ticket (gentle nudge to @Sdkb for that). – SD0001 (talk) 03:44, 31 October 2023 (UTC)

Slack vulnerability via Wikipedia

This article, dated yesterday at Security Week ("Attackers Can Use Modified Wikipedia Pages to Mount Redirection Attacks on Slack"), seems concerning and maybe to be something Wikipedia can help with. What say you?  SchreiberBike | ⌨  12:35, 31 October 2023 (UTC)

@SchreiberBike: Unfortunately it's unlikely Wikipedia (or Medium, as the article mentions) can do anything to help — this sounds like an issue with Slack more than anything. — TheresNoTime (talk • they/them) 12:52, 31 October 2023 (UTC)

The Wiki-Slack Attack requires 2 conditions: the Wikipedia article be formatted in a particular way. And lots of pages this way. The formatting requirement has two elements. A footnote at the end of the first paragraph - which is impossible to detect since that's normal. It also requires "the first word of the second paragraph is a top-level domain (TLD)". Unclear what that means, like ".com" or "com" or "foo.com" or "Com". Even if it's not our job to fix Slack's problem, "we" (bots?) could monitor for it to prevent what is essentially vandalism. -- GreenC 13:37, 31 October 2023 (UTC)

The original vulnerability description goes into more detail; the researchers say they found over a thousand natural occurrences of the pattern (not maliciously) exposing Slack to its preview bug. By the nature of the bug, it looks quite indistinguishable from legitimate edits. This seems to pretty clearly be a Slack vulnerability, not Wikipedia. StereoFolic (talk) 14:00, 31 October 2023 (UTC)

Thanks for the link. Yes confirmed with Slack and Lemmatization, this is a thing. User:TheresNoTime is correct, this needs to be resolved by Slack. They have been sending pop-up notices for the past few days of a forced update coming soon, could be related. -- GreenC 14:15, 31 October 2023 (UTC)

Looks easily fixable by Slack. They should change their algorithm to replace line breaks with spaces instead of just deleting them. With a space in between "form." and "In", their linking algorithm wouldn't get confused anymore. –Novem Linguae (talk) 15:14, 31 October 2023 (UTC)

The link destination isn't exactly hidden. The victim sees a blue link such as (in the Lemmatization example) form.In and, although that style normally leads to another Wikipedia article, they can't have too many complaints if clicking it takes them to the form.in domain. Certes (talk) 15:28, 31 October 2023 (UTC)

Perhaps I'm missing something, but this seems like a Rube Goldberg way to achieve the same result as <span class="plainlinks">. I'm struggling to see how "user clicking on a link is taken to the target of the link" is a even a security flaw. I stopped reading the esentire article at Browser-based attacks are a new underestimated threat surface... what what what? "New"? Have these people never heard of Internet Explorer? Suffusion of Yellow (talk) 21:14, 31 October 2023 (UTC)

In terms of what it does, yes. However, class=plainlinks https://evil.hacker.example.com/virus.exe is more likely to get reverted. Certes (talk) 21:19, 31 October 2023 (UTC)

Reminded of this today as I had a text reminder on my phone to remind me of an appointment "...at X Pharmacy.To change..." and the phone helpfully tried to treat that missing space as a link to "pharmacy.to". I'm pretty sure bad parsers have been doing this for a decade or two by now.

From the WP side, their description of the scaled-up threat relies on someone going around using chatGPT to rewrite high-visibility articles to get a desired pair of words in specific constrained places in the lead paragraph... I can't see that actually happening on any kind of meaningful scale? Andrew Gray (talk) 13:15, 3 November 2023 (UTC)

This appears to be a Slack problem, not a Wikipedia problem. If an app misbehaves when the words "pharmacy" and "to" appear together on the internet, the solution is not for every website owner to reword their pages avoiding that combination. Certes (talk) 14:04, 3 November 2023 (UTC)

Indeed. I guess it sounds more dramatic if the author gets to call it a WP vulnerability and give it a catchy name as a result! Andrew Gray (talk) 14:43, 3 November 2023 (UTC)

Defaulted edit window colors

Reporting that about 1/2 hour ago, my edit window colors changed to "defaults". White background, blue text, different font, font size. Timeless skin at User:JoeNMLC/timeless.css.

textarea[style] { height: 46em; color: #32cd32; font-family: 'Noto Mono'; font-size: 110%; } /* color Lime green text */

textarea { caret-color: red; }

textarea { background-color: #000000; } /* color Black */

Before posting here, I did the usual "Purge", Log Out/Log In. Regards, JoeNMLC (talk) 18:23, 1 November 2023 (UTC)

Did you accidentally turn on syntax highlighting? It will be a marker-pen-like symbol in the toolbar. (Or, the gadget or two available?) That would have dis-enabled your customizations and would explain you seeing it in blue text. Izno (talk) 19:25, 1 November 2023 (UTC)

@Izno, Yes - it was that syntax highlight. (my not so good typing) Still learning something new daily. Thanks a bunch. Cheers, JoeNMLC (talk) 19:32, 1 November 2023 (UTC)

When not signed in, three lines to left of article titles

At the top of the page, when I was on a computer where I had not yet signed in, I found that there were always three short lines to the left of the article name. That seems to have gone away. I was just curious what happened. I also tried signing in with an alternate account that I use to see what newcomers see, but that feature wasn't there.— Vchimpanzee • talk • contributions • 23:01, 1 November 2023 (UTC)

It's an icon in the default skin Vector 2022 to show the table of contents when it's hidden. It can also be seen if you are logged in. It usually remembers your choice and remains like that until you click it and select "move to sidebar". PrimeHunter (talk) 23:24, 1 November 2023 (UTC)

See Hamburger button for what it's supposed to signify in general. Nardog (talk) 23:29, 1 November 2023 (UTC)

Not quite. A hamburger button only has the lines and indicates a menu. This looks similar but also has dots and is a bulleted list icon . There is also one under "Advanced" in the default editor toolbar. PrimeHunter (talk) 00:11, 2 November 2023 (UTC)

I think this was what I saw.— Vchimpanzee • talk • contributions • 16:01, 2 November 2023 (UTC)

It's an odd choice for an icon, since they took away the useful TOC numbering in Vector 2022, and I don't know of any skins that use bullets in the TOC. See T44059 for the task that took away numbering, despite testimony from editors about its usefulness, and T307316, which is requesting an easy way for editors to see them again in Vector 2022 (i.e. easier than customizing your CSS and hoping that the developers do not change the class names in the master style sheets). – Jonesey95 (talk) 05:24, 2 November 2023 (UTC)

Perhaps this is phab:T349988 ? Jdlrobson (talk) 18:52, 2 November 2023 (UTC)

Editor stopped working

The WikEd stopped working this morning, throwing me back into the older 2005 editor. I cannot edit with that, and don't know what to do. Any help would be appreciated. Hawkeye7 (discuss) 22:23, 2 November 2023 (UTC)

Is wikEd enabled at Special:Preferences#mw-prefsection-gadgets? wikEd has a pencil icon at the top right of pages to toggle between active (yellow) and disabled (grey). Is it active? PrimeHunter (talk) 23:26, 2 November 2023 (UTC)

Yes, it is enabled at Special:Preferences#mw-prefsection-gadgets. Not seeing the pencil icon. Hawkeye7 (discuss) 23:34, 2 November 2023 (UTC)

When logged out I thought that there was an option for the Visual Editor, but that is not there either. Hawkeye7 (discuss) 23:37, 2 November 2023 (UTC)

I'm having a similar problem where none of my user scripts are working (including scripts in Preferences). What browser are you using? The issue is occurring for me on an old version of Safari (iOS 12) but not on latest Firefox on MacOS Ventura. – dudhhr ^talk_contribs^she_her 04:36, 3 November 2023 (UTC)

This may help finding out what is going wrong: Locating broken scripts —TheDJ (talk • contribs) 09:57, 3 November 2023 (UTC)

Information.svg, linked to by eight million pages, is TEN THOUSAND BYTES?

File:Information.svg -- see how huge this is? Same for File:Information icon4.svg which is 1 kilobyte for an extremely basic shape.

Definitely big if true. But is it true? The impression I get is that it's not actually being loaded by that many pages, and MediaWiki caches a .png render which is what people actually get served, so it's not an actual 10kb image getting loaded or rendered each time a page with them on it is served. Is this a thing, or nah? jp×g🗯️ 10:14, 3 November 2023 (UTC)

MediaWiki caches png versions in different sizes. A typical use says [[File:Information.svg|30px]] and produces which loads the 1834 byte https://upload.wikimedia.org/wikipedia/en/thumb/2/28/Information.svg/30px-Information.svg.png. PrimeHunter (talk) 10:35, 3 November 2023 (UTC)

If a browser has already read it once then the browser will often read it from its own cache and not from a Wikimedia server. PrimeHunter (talk) 10:39, 3 November 2023 (UTC)

Everything that PrimeHunter says. But also, even when you do get the 10KB version by clicking the original file, you'll receive it with on the fly compression applied to it, which will reduce the size. In this case, 3050 bytes will be actually transmitted, so not that far off from that 1800 bytes of the PNG at 30px. Having said that, there are a lot of unoptimised SVGs in our file catalogue. Because of the png thumbnailing this isn't a problem, but there is a long wish by the community to remove the png thumbnailing and to allow SVG directly (something I've been working on a bit over the last year). And then this would be a potential risk that we might have to account for. The current idea is to set a limit of 50 or 100KB per SVG and if SVGs are larger than that, they would still be forced to be rendered as PNGs. —TheDJ (talk • contribs) 12:25, 3 November 2023 (UTC)

Breaking database change: pagelinks table

There is a longstanding plan to move some columns from the pagelinks table to the linktarget_table in enwiki and other databases used by Wikipedia and similar projects. Imminent release has now been announced. This change will break some regular and ad hoc database reports, Quarry queries and perhaps other software. A similar change has already taken place for templatelinks, and is planned for categorylinks in future. Certes (talk) 14:27, 3 November 2023 (UTC)

Draftification

Ever since the idea of immediately moving inadequate articles to draftspace emerged as a common alternative to deletion, the amount of time that has had to be invested in cleaning up polluted categories that have draftspace pages in them has gone way up, because the people who do the sandboxing frequently forget to remove or disable the categories in the process — so I wanted to ask if there's any way that a bot can be made to clean up any overlooked stuff.

Since there's already a bot, JJMC89bot, that detects main-to-draft page moves and tags them as {{Drafts moved from mainspace}}, the obvious thing would be to just have that bot automatically disable any categories on the page at the same time as it's tagging it — but when I directly approached that bot's maintainer earlier this year to ask if this could be implemented, they declined on the basis that the bot hadn't already been approved to perform that task, while failing to give me any explanation of why taking the steps necessary to get the bot approved to perform that task was somehow not an option. As an alternative, I then approached the maintainer of DannyS712bot, which catches and disables categories on drafts that are in the active AFC submission queue (which newly sandboxed former articles generally aren't, and thus don't get caught by it), but was basically told to buzz off and talk to JJMC89bot.

So, since I've already been rebuffed by the maintainers of both of the obvious candidate bots, I wanted to ask if there's any other way to either get one of those two bots on the task or make a new bot for the task, so that editors can cut down on the amount of time we have to spend on DRAFTNOCAT cleanup. Bearcat (talk) 16:10, 3 November 2023 (UTC)

As a stopgap solution, encouraging people to use a script like User:MPGuy2824/MoveToDraft (which automatically disables the categories) might be a good way to go? Elli (talk | contribs) 16:23, 3 November 2023 (UTC)

login.wikimedia.org

Moved from Wikipedia:Village pump (miscellaneous)

Hi,

Not sure if this is the right place to post this, but I was curious:

What is login.wikimedia.org used for?

Some accounts say that they exist on this wiki, but it's not really clear what it is? LOOKSQUARE (👤️·🗨️) talk 16:10, 3 November 2023 (UTC) RoySmith (talk) 16:32, 3 November 2023 (UTC)

It's a part of the unified login system connecting all Wikimedia wikis, and every account should also exist there. When you log in on any project (such as English Wikipedia), you also get logged-in at the login wiki. Then when you visit another project, such as Meta-Wiki, your browser checks with the login wiki and if you're logged-in there, it also automatically logs you in on the project you visited. Matma Rex talk 16:37, 3 November 2023 (UTC)

Highly visible mobile bug

Several times, I have noticed a bug on the mobile Wikipedia (website) involving misdisplaying section heading when preceded by an image with the right option, e.g. here. I've tried to search for it in Phabricator, but I haven't found anything similar. Could somebody reproduce the issue? Given its visibility (if it isn't exclusive to me), I can't believe it hasn't already been reported. Janhrach (talk) 17:11, 3 November 2023 (UTC)

I don't see a problem. Can you post a WP:SCREENSHOT? – Jonesey95 (talk) 18:46, 3 November 2023 (UTC)

This was the problem: (imgur screenshot). I believe this was more of an article layout and missing-wikitext issue than a software bug. It was missing the 'thumb' parameter for the image, which meant the caption was not being displayed, and the image was treated as a 'no format' image (docs) and hence rendered inline instead of floating. After two fixes, it looks like this (imgur link). That appears to have fixed it at all window-widths. Quiddity (talk) 19:32, 3 November 2023 (UTC)