I realized I forgot to turn on editcheck by default in the first patchdemo, sorry.

We have other wikis where DT is enabled on namespaces that've also got VE (mediawikiwiki and metawiki, notably). It works out fine -- VE doesn't edit those pages well because of definition-lists. There's nothing stopping us from going ahead and enabling it with the vote, I'd think.

This is one of those "the editing team is listed as maintainer, but never really deals with it" components. @matmarex is the WMF person who has been making some recent changes, pinging just in case this looks related to anything they've been doing.

Demonstration of the change requested from the original design review in T275729:

Token @color-placeholder was chosen recently in T367432 by @bwang.

Probably need to talk to SRE about the "verification method" section.

I'm not entirely convinced that [https://example.com]https://example.com is sensible output for <a href="https://example.com" rel="mw:ExtLink nofollow" class="external free" id="mwAw"></a><a href="https://example.com" rel="mw:ExtLink">https://example.com</a> -- it'd probably make more sense to discard the empty link entirely. That said, it's a bit of an edge case, and we should probably look at fixing the input rather than nitpicking the conversion.

We're submitting approximately this API request:

Someone may have fixed the specific example on metawiki following this report. The blocked users are available from the API, but they're successfully filtered out in the completion display. (The removal criteria is user.blockexpiry === 'infinite' && !user.blockpartial if you're looking at those results.)

Is this for purely client-side cache (in-memory, just affecting people who repeatedly click "generate" in a single session)? If so it seems harmless, but I can't imagine it'd have much impact.

Confirmed, this happens in the 2017WTE on enwiki.

Looks fixed to me on beta mobile following that patch (and some fairly aggressive cache-clearing):

I'm not particularly familiar with how dark mode was implemented, so: was the expectation that the earlier Vector patch adding new classes to OOUIIconSelectors should have fixed this in mobile (i.e. in MinervaNeue)?

Having checked, like Jon I'm still seeing the images as inverted. That said, I wonder if there's something wrong with Beta's caching of the compiled less (or with that patch to Vector) -- the icons do have mw-no-invert on them.

Looks like it might be a side-effect of T366984.

In theory the signature not being recognized should also manifest as their comments not getting [reply] links added, since the check for the signature in preview/post is approximately "run the comment parser on what was submitted, and see whether we can already find a valid comment in it?". (Unless there's some edge case that's only hitting when there's a single comment in the preview, of course.)

I can't immediately reproduce this:

This is a click on the "back" button in the edit check popup. For it to error like this, it needs to be in a state where said back button is accessible... but there's no open context item or inspector. This might mean that there's a reachable state where we just seem to have an empty edit check stage with the toolbar still showing... or it might mean that there's a way to access the toolbar after we think we've cleaned up and moved on.

Quick note in case QA gets to this extremely-promptly: the frontend permalinks being enabled causes a change to the cached rendered content markup. As such, the permalinks will start appearing on enwiki as page caches expire, either because of time or because edits are made to the page. (If a page doesn't have them yet, you can use action=purge and they should appear.)

Some quick history checking shows that it was added in T311677/T310624 in 2022. Specifically, it was set to default to true in T310624 because the only way to stop a <gallery> from having the caption duplicated into the alt attribute is to explicitly provide a blank alt (|alt=), so the UI currently represents the default state of just having added a line to the gallery with the image name.

We prevent the addition of obsolete tags to user signatures. Why not elsewhere?

To summarize: current behavior for the gallery image dialog is that when you add a new image to a gallery we check the "use caption as alternative text" box by default. PerfektesChaos would like that box to not be checked by default.

It doesn't really need much QA -- just make sure it's actually turned on where it should be and not on those 8 wikis.

For issue 1, my logic here is that blocked links are (probably) going to be a very uncommon case, so it's better to not have a mandatory second-ish pause every time you edit a link, and the case where someone misses noticing it because they're acting quickly is the same reject-on-save behavior we've been happy enough with for years. That said, perhaps a sensible fallback would be to hook it into the context for the link, since that'll still be showing once you leave the inspector...

The messages are currently:

// link inspector:
"visualeditor-linkinspector-invalid-blocked": "People at this wiki decided to block links to this site. Please try another link.",`
// citoid:
"citoid-citoiddialog-reliability-unreliable-title": "This site is blocked",
"citoid-citoiddialog-reliability-unreliable-description": "This source is considered unreliable by our community, and therefore is not allowed. Please choose a different reliable source.",

Well, if it's automated that's not so bad. It still seems sensible to acknowledge usemap in the skin CSS for responsive images in case other extensions / gadgets output imagemaps in the content in the future, but it's no longer directly related to fixing this issue.

Just to agree, this isn't a problem with the gadget. In safe-mode you can (painfully) see that the <area> tags we're outputting aren't aligned with the correct areas on the map, by carefully hovering over the image and seeing where the clickable areas are. Compared to the safemode version in classic vector, you can see they're misaligned with the shapes in the image (I found the centermost brown circle to be pretty usable for checking this).

We accidentally removed mw.editcheck.findAddedContentNeedingReference while refactoring in the edit check API patch. That patch quickly re-exposes the information we need to keep the tagging working.

Not a regression per-se; I did some quick checking out of old revisions and it looks like this has been doing this ever since we launched the edit-from-reflist feature in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Cite/+/903311. Clicking the "replace" button is presumably just uncommon enough that we never noticed.

VE only has support for <templatestyles> in the sense that it supports all registered extension tags as "alien" nodes. It doesn't currently know anything at all about the rules for that tag. Normally the way this is done is that the extension implementing custom tags will add some VE registration code so that it can handle things itself -- there's examples in extensions like Cite.

That commit does indeed look suspicious.

(Could easily put up guardrails against the situation, but it'd be good to make sure we're not generating such a malformed link...)

The error in F54942927 boils down to copyLink being passed an incorrect argument -- link is undefined. Suggests that there's a .ext-discussiontools-init-timestamplink link in there somewhere which doesn't have an href, which is peculiar.

It looks like the definitions are very underspecified for this hook. E.g. this extension is doing it as just a string: https://github.com/thaider/Tweeki/blob/cd9490a7370df8f296a54d81fd5e5c1033284f54/includes/Hooks.php#L263

The requirement for a date is pretty strong inside DT -- all our IDs for permalinks require one for disambiguation. If you want the unsigned-template to result in a reply button, it needs to include a timestamp (in the wiki's official format) that's closely preceded by a link to a user page.

Ed raises in the patch comments that we might want to say "users" rather than "people". We're fairly inconsistent about that across messages, admittedly. "Administrators" might be most accurate.

@Mnalis I was quoting @Pols12's suggestion that they'd like to run an RfC to switch to a prefix search in the Category namespace, i.e. having the category-editor only allow search for categories that have a page created. In retrospect this was replying to something from over a year ago, rather than your recent quite-appreciated summary of options, so it was perhaps a bit unnecessary.

Or maybe "page", because "site" might still be read as the entire domain. 🤔

It's worth noting that "links to the domain you entered" isn't quite right, because the blocks can be much more specific than that. E.g. blocks on specific pages of sites aren't uncommon -- particular youtube videos, google books pages, etc. It's why I went with "site" originally.

“This project” is also a bit of a WMF-specific terminology — a random fandom wiki wouldn’t call itself a project, I think? Would “this wiki” or “this site” work for you?

(e.g. It's less of an issue now, since Musk did his Musk-y thing to it, but copying links from twitter used to get you a t.co link that's a shortener, and that's on the global blocklist... and also the sort of place that people will grab links from that they want to place into talk pages.)

"Wikipedians" is going to look pretty weird on non-wikipedias. Even on our projects, someone on e.g. wikivoyage isn't a "wikipedian" -- and this is going to run on non-WMF third party wikis as well... fandom, etc.

Thank you for tagging this task with good first task for Wikimedia newcomers!

Technically a category “exists” if any page links it.
However, for end users, a category “exists” if a category page has been created.

Worth considering that this is a bit wiki-dependent, and is more true on the big wikis. Outside of the wikiprojects, it'd also affect people who're running their own small mediawiki instance, who might not have actually created category pages. I'd prefer not to make this trade-off, since there's a decent set of category results that'd effectively be hidden by it.

Should this one be merged into T59302? It includes things like a big table of the trade-offs between the various options. (With everything else currently losing out to allcategories because it's the only one that works for categories without a Category: page.)

Patch has been updated: it'll disable the done button after checking whether the URL is blocked.

I was mostly thinking of avoiding unintended consequences if it turned out there was some case where we were blocking something in the dialog that wouldn’t really be blocked by the existing pre-save checks. That said, I don’t actually know of such a case, so I might well be being overly cautious. I’m not wedded to the current behavior, so I’d be entirely happy to change it to a full block of choosing “done” (or, I guess, in the other direction changing it to display as a warning ⚠️ rather than an error 🛑).

@ppelberg re: 1, yes, the "external site" tab is what I'm talking about. Specifically, it'll appear where that "enter a full URL" error is.

We wound up doing this in T347531.

Thank you for tagging this task with good first task for Wikimedia newcomers!

I've given this a subtask T366721 for just improving the error message, since that seems uncontroversial. Ideally we can find a way to reapply the user's changes on a freshly stashed copy of the article, but there's obviously some conflict-resolution UX to work out there before we could have a general fix...

I'm thinking that an error message of approximately "your edit session has been open too long" is a good start. If reopening the editor and restoring the auto-save is sufficient to wind up in a saveable state without any negative consequences that could be recommended, but it'd need some testing first.

Thank you for tagging this task with good first task for Wikimedia newcomers!

This has been fixed elsewhere in the interim.

I'm inclined to say that VE shouldn't meddle with parameters inside the template editor that've been provided by a user in plain text. If we want that to happen, we should go all-in and have type="content" params (which are currently displayed as a textarea that you put wikitext into) instead display as an embedded VisualEditor (like we do for e.g. gallery descriptions).

The main drawback to the gadget approach is that you can't pre-render like we can do in DiscussionTools server-side. Instead you'll need to let the page load, then reformat it. As you say, though, (non-default) gadgets get a lot more leeway for flaky UX, so that'd probably be acceptable -- if nothing else, as a proof of concept to get communities on-board for changing the default experience via DT.

However, I get a console error like like TypeError: Cannot read properties of undefined (reading 'length') on de.wiki and hr.wiki. This doesn't look like a bug introduced in the code changes for this ticket.

@EAkinloose could you point to the specific page/link that you were clicking on when you got this?

The example page from the ticket description is a decent demonstration of how the debug page is throwing everything non-comment away: https://www.wikidata.org/wiki/Special:DiscussionToolsDebug?pagetitle=Wikidata%3ARequests_for_comment%2FCreate_items_for_property_proposals

The technical difficulty is mostly in edge cases where we worry about the parser misunderstanding things. Currently, the only problem that really happens there is that a particularly unusually structured comment might be missing a "reply" link, and behind the scenes the parser might think that it's part of the next comment (but not in a way that's really visible to you). The more we expose things that involve us actually manipulating the structure of a talk page, the more likely it is that we'll accidentally break something that's visible. (Another example is the "edit comment" feature.)

Deliberate, as of about a year ago. See: T54750.

On that website there's <meta property="og:url" content="http://www.thecity.nyc/2024/05/02/nypd-officer-fired-gun-columbia-hamilton-hall-raid/" /> in the source, which I'd assume is what's being picked up on.

I can't reproduce this in Safari currently.

This is an issue with the mediawiki-core TitleSearchWidget that happens to be used by VisualEditor for this. The data does seem to be returned by the API (the tofragment field on redirects), so it could be done there...

MediaWiki:Visualeditor-quick-access-characters.json actually has something close to this already, albeit in an extremely undocumented fashion -- you can add source:true to a given character/replacement, and it'll only be shown when you're in source mode.

This is Mediawiki:edittools, which isn't very importable into the new editor. (I do have a userscript I wrote that does it, but I wouldn't want to consider it reliable.)

Something like enwiki's version of the spamprotectiontext message (that's shown to someone who tries to post a revision containing blocked URLs) sounds like what you want here, or at least one of the pages it links to. I'm not sure if there's a particularly good language-agnostic page on metawiki to be the default, though.