Patch was merged, @DannyS712 any further action required on this task?

This is apparently because of https://github.com/reedy/AutoWikiBrowser/blob/b1d41ae2bef0390adfd6224888a37faa07ddfa25/AWB/Main.cs#L3454:

The patch needs a look from someone who knows about MediaWiki DB performance, as this query joins some very large tables.

I'm wondering if Community-Tech might have a moment to look at this, in view of

IIRC raw bits of the XML upload or foreign wiki export will often get spewed out in the error message - in particular, XML tags.

In T309574#8012386, @Izno wrote:

"It should be the same" is not a bug. Do you have proof to indicate this behavior has changed from some earlier date?

In T309574#8008914, @Izno wrote:

This is supposed to have five lines, where the second and fourth lines are blank:

I see this as expected behavior. Do you have proof that these used to be rendered?

Not going to happen. An additional database query on page load isn't acceptable for such a slim benefit.

This was wish #23 in this year's Community Wishlist Survey. In Community-Tech 's prioritised list of wishes, it came in at #2.

WingerBot on enwiktionary is affected: https://en.wiktionary.org/wiki/Special:Contributions/WingerBot

Good idea! I'll do that. Thanks.

Just in case anyone is wondering, I have a completed patch for this, but I had serious issues running the EditPage tests locally, which meant I wasn't able to write any tests. I idled in some of the above mentioned IRC channels for a few days but spotted precisely 0 active humans in any of them, which didn't really make me feel very welcome. One day I might be able to return to it.

Thank you very much to the Search team for your efforts to make this happen!

@Quiddity I'm so sorry, I only just saw this - the change isn't deployed yet, so the message should have read "You will soon be able ...". Would it be possible to pull the message from this week's Tech News? By next edition, the code should be deployed so it will be able to be reused as is in the next edition.

In T215716#7757991, @MPhamWMF wrote:

this patch is ready to move ahead with code review and merging.

In T265716#7729403, @MusikAnimal wrote:

The first approach is always a safe assumption, I think, but this is not necessarily true for the second approach. It might be an edge case, but if someone explicitly set a watchlist expiry on a page, it may be reasonable to assume they intended to unwatch it at that exact time. For example, say it's Today's Featured Article, which they only watch for 24 hours. They have the "Add pages where I have performed a rollback to my watchlist" preference set to watch for 24 hours. If they revert an edit at the 23rd hour, they probably don't care to watch for another 24 hours on that particular page. So all in all, in my opinion is approach #1 of only applying an expiry if one doesn't already exist seems the most logical.

In T215716#7726070, @Gehel wrote:

• Since we have multiple search interfaces (SpecialSearch, AdvancedSearch, MediaSearch), it is a bit confusing on which of those interfaces are impacted by this setting

I proposed this in the Community-Wishlist-Survey-2022 and it only got 25 votes (#135 in the ranking), but I'm working on it myself nonetheless.

In T215716#7724472, @Ladsgroup wrote:

Is there a way to move this to another tab? Having one tab with only one option is weird plus having many tabs is bad UX.

In T215716#7716703, @tstarling wrote:

it seems like the simplest thing, less than one day of work.

On mw.org at least, only wikipedia: is affected.

The mystery here is why only the wikipedia: interwiki appears to be affected. If this is indeed the case, it's not actually a blocker to deploying to group2 (Wikipedia sites don't use the wikipedia: interwiki). But it's a bad regression on the group0/group1 sites currently impacted, including big ones like Commons, Meta and Wikidata.

Repurposing this task slightly in light of my comment at T66184: Allow searching also by new/target name on moving log page.

This task looks set to come in 10th in the Community-Wishlist-Survey-2022 ; it didn't look particularly difficult to code up, so I thought I'd have a crack.

In T170737#6760087, @matmarex wrote:

Probably… but there's now also T224321: Run populateCategory.php and I'm not sure what's the difference.

Isn't the problem of generating abstracts already solved by the Page-Previews extension?

@Reedy or anyone else - any chance of a look at that patch?

It seems that content.parser-output.less is no longer being included in the minified CSS. @Jdlrobson @Ammarpad @matmarex

We have noticed a rendering change on English Wiktionary after this deployment. The first report was 22:44 UTC yesterday, a few hours after the deployment.

In T108792#6802631, @TTO wrote:

On enwiki on the beta cluster, the "Import as subpages" option is selected by default for both XML and transwiki import. It should default to "Import to default locations" in the first instance, then when the form is reloaded, the option the user previously selected should be chosen.

On enwiki on the beta cluster, the "Import as subpages" option is selected by default for both XML and transwiki import. It should default to "Import to default locations" in the first instance, then when the form is reloaded, the option the user previously selected should be chosen.

@Reedy I see agreement at the Beer Parlour; what are the next steps?

I posted at https://en.wiktionary.org/wiki/Wiktionary:Beer_parlour/2021/January#PageNotice_extension_again to start a discussion/vote.

This task is assigned to me, but I am so far out of the loop at this point that I don't think I can make any useful contributions to it any longer. (Yes, despite appearances, <poem> is surprisingly subtle and requires the attention of someone with a decent, up-to-date understanding of MediaWiki parsing infrastructure.)

Based on:

Not sure why this task was assigned to me; I don't have, and have never had, shell access.

I guess I created this task for my own reference, but never got around to doing it. The issue still exists. The function doesn't get a lot of use though.

Thanks for the explanation!

Thanks. To be 100% clear, does that mean that this extension has successfully passed its security review?

Re number 6, there are already many avenues to deface the wiki if you have edit access to the MediaWiki: namespace. Editing MediaWiki:Sitenotice would have a similar effect as creating a page notice. I don't think the fact that this extension adds another avenue is of any special concern.

In T61245#5389385, @Reedy wrote:

Extension wants converting to extension registration before we'd deploy it (should be trivial)

I am still happy to act as maintainer of this extension; I rewrote it a few years ago, and it is awfully simple (barely 100 lines of code). Plus I am irregularly active on English Wiktionary :)

It was five years ago, and the code has since been heavily refactored; I'm afraid I am not of any help here.

This is on purpose; the long names always link to the English project. To change this would be incredibly disruptive.

I'm removing the import and export project - it's possible that a bug existed in 2007 when the import(s) took place, but we're not going to try and solve an import bug based on evidence from 12 years ago.

It's all good, @TJones. Thanks to you and @debt for investigating this in such detail back in 2017. I remember I was very impressed when I read the comments on this task, and especially the blog post! I regret not expressing my gratitude or commenting here at the time.

In T162517#4811531, @Jamesmontalvo3 wrote:

This change seems to have made group expiry a requirement rather than optional. Personally I'd like to disable this feature (or at least limit it only to certain users) because I get people applying expiries when they should not. Is there a reason this is no longer optional?

Is this the same as the ancient task T31961: Special:Export of a single page with huge history occasionally forgets </page> and </mediawiki> closing tags?

The old toolbar is going away.

I would suggest that d: could be added to the beginning of the links. This way, they should work both on Wikidata itself and other wikis. This isn't really an interwiki linking issue (well, philosophically speaking, this happened because the interwiki links system is fundamentally flawed, but that's a tale for another day).

I don't think this has anything to do with change tagging. The stack trace makes it clear that $revid is null at https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/MassMessage/+/master/includes/job/MassMessageJob.php#233.

Sorry for the bikeshedding and delay.