It would be great if it could be extended to other things like some page properties. For example, the Display Title extension causes a very noticeable slowness, because each title on a page needs to query the page_props table one by one.

El T388732#11661364, @lcawte escribió:

We've just run into this at ShoutWiki after upgrading to REL1_43. Did anyone ever work out what caused this, or if it is patchable? In my search for an existing fix, I ran into this thread where another third-party user caught this error.

I've created a patch to allow a list of configurable namespaces to not honor DisplayTitle in links.

I often encounter this issue on my wiki, and I have caching enabled in redis. This can happen even if the edit takes 15 minutes...

Another instance spotted:

Yes, tarballs and signatures are downloaded from releases.wikimedia.org

El T405165#11225510, @ssingh escribió:

I don't think this has anything to do with the UA. Is the command correct? Maybe try downloading via curl/wget and then piping to gpg --import '. curl https://www.mediawiki.org/keys/keys.txt | gpg --import - works for me for example.

Can this particular URL be exempted from the User-Agent policy?

What is the usefulness of changing the content model of an existing page? However, creating a new page with a different content model than the default can be useful. For example, required by MassMessages, TemplateStyles... However, I'm not sure changing the content model once the page has been created and has revision is really useful. Comparing revisions from different content models is probably unsupported or can't be meaningful. And it can be quite disruptive, since the new content model may disallow the use of page histories.

Why are transcoded regenerated instead of moved to their new location?

On my own MediaWiki instance (MediaWiki 1.43.3), today I've experience this issue. After ~30 minutes of editing a page with the visual editor, I received the "No stashed content found for" error. View changes (diff), saving the page, switching to source edit, even after adding more changes, always results in the same error. The only thing that works is the visual diff mode. I could only recover by opening the edit on a new tab, and copy&pasting the text on it. There was no conflict neither, since there were no more edits to the page.

In fact, there are 3 things displayed in a category:

I still believe the issue is in core. See T388058: DatabaseUpdater doesn't run scripts in order when using addExtensionUpdate and addExtensionUpdateOnVirtualDomain on the same extension

El T348484#10573854, @Ciencia_Al_Poder escribió:

Error running update.php upgrading to 1.43
...

El T58074#10806873, @kostajh escribió:

Email

El T55744#3165271, @Krinkle escribió:

I'm not sure what you meant by "deleting elements one by one" but from what I can see it's only sending one simple query, not iterating or deleting things one by one in any way.

El T248416#10605265, @Od1n escribió:

This current plan makes Minerva.css a de-facto Mobile.css. The problem with this approach is that it brings a strong mobile/Minerva coupling. It makes Minerva on desktop domain unmanageable (too much code conflicts), and much worse, it closes the door to implementing additional skins on mobile. I think this would be a bad move in the long term.

After doing some debugging, I found what the issue is.

Error running update.php upgrading to 1.43

El T273898#9773350, @JaydenKieran escribió:

I've uploaded a patch which changes the LinkSuggest extension to use the core prefixsearch API module, which in turn adds support for showing redirect targets as suggestions.

El T326071#10265847, @Maneatingcow escribió:

Could someone please confirm if this being fixed in 1.39.2 means I can upgrade a 1.32.1 install directly to 1.39.2 or greater (e.g. 1.39.10 as of today). The instructions on https://m.mediawiki.org/wiki/Manual:Upgrading give mixed instructions about this IMHO.

Since MCR is part of core and ExternalStorage is part of core (T362566), why was the migration script created on the WikimediaMaintenance extension instead of being in core?

El T92795#10100600, @SD0001 escribió:

Ideally yes, but it's almost impossible in today's MediaWiki architecture. Even just preparing to make an edit is a complex process that involves checking permissions, ip blocks, rate limits, unicode compatibility, page protections (including cascading ones), and other restrictions added by extensions (spam/title blacklists, abuse filters, captchas). Extensions do not try to do all (or any) of that by themself – they just rely on MediaWiki core. There's no way to tell core to "perform all other checks but skip the editcontentmodel right check".

That is, until someone rewrites EditPage. It's marked with Surgeon General's Warning: prolonged exposure to this class is known to cause headaches, which may be fatal so I wouldn't hold my breath.

File from 2016: https://upload.wikimedia.org/wikipedia/commons/9/9b/Icons8_flat_phone_android.svg (file description page) is served as Content-Type: image/x-icon

El T62399#9979538, @Scott escribió:

As a suggestion for how this could be implemented:

• check the title field value on keydown/paste event
• disable button if Foo:Foo:Bar and display a warning plus "yes, use this title" override checkbox which re-enables the button

Change #1043060 had a related patch set uploaded (by SD0001; author: SD0001):

[mediawiki/core@master] Don't check for editcontentmodel right while creating pages

https://gerrit.wikimedia.org/r/1043060

I see a surge in backlog for WebVideoTranscodePrioritized

There's a solution that doesn't involve schema changes: auto create the page when the first comment is posted

El T10482#9737567, @Tgr escribió:

For enhanced watchlists, (top) is probably not very useful, since edits are already grouped by page so most of the time it's obvious that the first of the group is the top edit.
(Only most of the time, because they are also grouped by date - T10681.)

Fixed, sorry, I didn't catch that strings are not nullable by default in php

In T361993#9696193, @Fersteax_Pasique wrote:

I can't run anything, my wiki is on Miraheze, a wikifarm, I have no access to my wikis files.

In T362013#9695476, @Killarnee wrote:

Expected behavior is that there are no reverted and manual revert tags attached to these two edits, because in this case the following edit doesn't revert the previous edit.

Check the Job queue manual page to see how the queue works. You may need to run runJobs.php to speed up the process of deleting pages

Oh! Sorry, I didn't notice that! That's correct indeed

I'm not sure if this is the same reason, but sometimes the update just doesn't happen, even if it's not a revert, deletion or done in quick succession.

If patroller X has a patrolling script that adds tags to some existing edit, will it work?

No. If https://gerrit.wikimedia.org/r/992763 gets merged, the right will only be granted to bots and sysops.

If AbuseFilter triggered by autoconfirmed adds tags to theirs edit, will it work?

Yes. Extension's actions are not affected by user rights.

Apparently, renaming an audio/video file doesn't automatically rename transcodes. Instead, new transcodes are queued, and only when purging the file description page. File renames should also rename the corresponding transcodes too

I've updated the patch and it should catch those corner cases, because I'm using the same logic as normalizeUserName from ActorStore

Looking at T353766, even if I have no details about the cause, I've amended the patch to check for general validity, which should also work for that other task

Apparently, you can't have a user name "ßéÿßlâÐëRèvêñgë". The first character "LATIN SMALL LETTER SHARP S" is detected by MediaWiki as a lowercase character and the user name converted to "SSéÿßlâÐëRèvêñgë" automatically by MediaWiki classes handling revisions and inserting the actor name.

Apparently, Discord has changed the way it displays embeds and now it displays 3 images, too. It was displaying only one until today.

I'm not sure why the task was repurposed. Create a new one? Apparently, when Safari is unable to display transparency, it chooses black as the background, which is exactly what your repurposed task wants to do. Supporting transparency should work for all browsers except Safari, which would display a black background instead.

Indeed, it works now. Closing...

Can I reopen this?

Thanks for the fix! I've tested it and it now works

In T54647#9313754, @alistair3149 wrote:

As for Reader Web, it shouldn't affect the mobile footprint as they serve pages through MobileFrontend, which can strip the metadata out of needed.

I have the same issue. MediaWiki 1.39, PHP 7.4.33. I have more than 28000 *:rootjob:* keys on redis right now

Another option may be to add metadata to the pages that use the image. See https://developers.google.com/search/docs/appearance/structured-data/image-license-metadata

If anyone else encounters this problem and wants to recover the data from backup (only this data, and not rollback the entire database), follow this steps:

I'm pretty sure Nuke doesn't need to check IP addresses on Recent Changes. It should work using actor only. Looking at the code, I think usages of rc_user_text should be replaced by an actor name

In T117279#9255216, @Sollyucko wrote:

I would like to have side by side available as an option on mobile, since inline diffs are sometimes an illegible mess of alternating words, e.g. an extreme case in https://en.m.wikipedia.org/wiki/Special:MobileDiff/1180439256: F38450324

In T189989#9137913, Krinkle wrote:

Given that the social convention around MediaWiki, as originated on Wikipedia, is to use /doc pages I would generally suggest going along with that. It is not sustainable for the entire ecosystem to support multiple ways to do the same thing. In some cases we need to due to mutually exclusive requirements between important use cases, but I don't see that being the case here. I believe you could transition slowly/gradually, so there's no big barrier there either.

For the original request, I would suggest declining this request.

An additional benefit, in contrast to what WMF does to serve WebP instead of PNG/JPG on the CDN layer, is that files will be served with the correct file extension. Currently on WMF, some thumbnails are served as WebP with .png extension, confusing users when downloading those thumbnails to their devices for later viewing/editing or uploading them somewhere else.

In T18691#9034663, @Prototyperspective wrote:

This would be especially useful needed on mobile where one doesn't have a TOC.

When fixing this, debugging the resulting SQL query, I noticed something strange. The default value as defined in extension.json is [ 0 ]. If I set $wgNamespacesForEditPoints = [ 0, 6, 10, 14 ], the resulting query results in [ 0, 0, 6, 10, 14 ] (notice how the value 0 is repeated)

No, it doesn't fix the issue...