I've tested setting blog-by-user-category to end in /e#, and it displays a PHP Warning: preg_match_all(): Unknown modifier '#'. That means the PCRE comment character isn't taken as a comment when present in the modifiers section of the regexp, making it not exploitable (unless a more ancient PHP version allows for that).

Maybe the message should be passed through preg_quote, and then replace $1 (without spaces) with (.*). Sadly I have no time now to test this :( Maybe in a couple of days...

With the previous patch, refreshLinks does not fatal anymore. It should be fixed now

Looks like this could be fixed by gerrit change 449761. The code path is not the same, but maybe the code was reorganized some time ago...

This actually is a fault of the Comments extension (incidentally, blogs have comments 😁). I'm not sure why this happens when the blog page is renamed, and not otherwise, though, although using $wgOut can be the source of a lot of problems.

Okay, I was looking for the $wgUserProfileDisplay['articles'] on the SocialProfile extension... Also, I forgot to run jobs, so the user category wasn't populated and hence nothing was displayed.

Okay, my comment was about the T45646#4447303 idea, which would be a major breakage in legal terms. Gerrit changeset 449626 would be fine, though, if it doesn't follow the path of renaming system messages.

Does a special page exists which lists all blog pages by author? I can't find it. Ideally, this shouldn't be a magic word, but an includable special page. The special page on its own could be linked from the social profile (see T146588)

In T146588#2665741, @ashley wrote:

You mean $wgUserProfileDisplay['articles'] = true; ?

You can try running populateRevisionSha1.php. I though it may not generate it for deleted revisions, that will have this issue on undeletion, but apparently it also takes cares of deleted revisions, so there shouldn't be any case missing. This script should have been run automatically on upgrade when the field was added.

It may be another instance of T195692: Attempt to undelete page causes error: Fatal exception of type IncompleteRevisionException: user_text field must not be ''!, but this one is on a different field

Adding ashley as cc since he's the only de-facto maintainer (at least in the previous 2-3 years). I can probably come up with a patch if nobody does that before. Tagging as easy because it looks easy to reproduce and fix.

edituserjs/editusercss/edituserjson permissions have been revoked from sysops in rMWdb888bc5ad

Yeah, sorry. The code is very complex and hard to test. I'll try to investigate in case I'm able to provide a patch, however feel free to submit a patch yourself if you can. This problem is blocking my ability to upgrade my wiki

Well, apparently this did surfaced on development (this task) but didn't got sufficient attention, maybe because thinking it only affected vagrant. But this affects real setups (see T200471)

This may be caused by rMW14ee3f210782 self-merged by @aaron

Looks like the second textarea may be intentional for the "autosize" property, because if I remove it later, the textarea does not autosize.

Why not simply change the usage of the current message as to not output raw HTML? Wikis which don't have the message customized, will continue to work. Wikis that use raw HTML, will display visible HTML code, but that will be also very noticeable for site admins that can adapt the message. This will prevent the problem of displaying a wrong copyright message: it would be correct, but badly formatted, only for the cases where non-allowed HTML tags are used.

From a comment in https://www.mediawiki.org/wiki/Topic:U7h4x03lzgbzd2qd#flow-post-uhgx58vkowl5xsoh:

The issue hasn't been resolved. I've just created a new page and the error appears again at the top of the page:

Done for SocialProfile (-core?), other satellite extensions may need update too.

Someone with access to google search console can add the Special:NewPages atom feed. This will help to index new articles created

What about a floating button on the bottom-right corner, that when pushed opens the table of contents? That way you can easily access the TOC, independently on the scroll position (also useful to reach the top of the page). Of course, this would be more an improvement to UX, not SEO itself (depending on how it's done)

@Hagarshilo I can view it with a program called VLC

In T198552#4362457, @Aklapper wrote:

We introduced the limit a few hours ago.

The problem can be easily reproduced by simply placing {{#translation:}} on the page.

Another instance of the error when logging to commons, on mobile: T198515

Is going to be any data loss for the edits made recently?

I've added a reminder of the "THIS IS NOT A RELEASE YET!" text on the comments section, just in case, because it's not the first time something like this happens :)

Ugh, I install every MediaWiki update on a different path, and then change the web published directory to point to the new one...

In T198005#4310057, @Daimona wrote:

2. Allow to retrieve info from any filter in a way like T186960#4310018

Where (2.) completely prevents order customization and thus isn't really good.

In T186960#4310025, @Daimona wrote:

I think that we'd better allow users to specify the execution order and avoid setting one without explicitly reporting it. This would give users more control and simplify coding the feature.

AbuseFilter tests filters ordering them by number. Thus, we may limit this functionality to only checking previous filter (=filters with smaller number).

I think sharing variables or add subroutines in Abuse Filter does not require to have a specific order of execution, or at least the implementation of those features shouldn't require this.

@DeepBlue: Wikiapiary is down atm. You probably know, but pinging just in case.

I use a custom-made extension that adds the file timestamp to the URLs (thumbnails and original file). If anyone is interested, the code is here and can be seen on wikidex.net

Do you plan to decide based on the number of user rights/permissions of each user? permissionCount(userA) > permissionCount(userB)

rvexcludeuser may be the problem here. Queries with explicitly exclude something are usually expensive (where not exists, where X not in, or where A <> B). Maybe this is causing the query to not using the proper indices.

An option to reduce the attack vector, while allowing other users to "clean" broken code, would be the ability to only blank or delete the page, instead of modifying it. Blanking the page wouldn't compromise anything.

I'd expect a centralized way to set uploads to readonly

Okay, I read from the documentation that this setting is "To disable file delete/restore temporarily. " This makes the variable useless.

In T117332#4269316, @MusikAnimal wrote:

Can you think of a way to find these uncategorized pages?

In T117332#4269288, @MusikAnimal wrote:

This happened again with https://en.wikipedia.org/wiki/User:TimSGearhart/sandbox. A speedy deletion tag was added on April 16 but the page was never put in the category. I have since made a null edit and that fixed it.

Maybe we could run a query to look for Template:Db (and variants) transclusions where the page is not in Category:Candidates for speedy deletion?

I'd say T167246: Refactor "user" & "user_text" fields into "actor" reference table

In T186456#4230198, @demon wrote:

My addition (removing non-composer support for SMTP) is in master and REL1_31.

In T194848#4212433, @mmodell wrote:

@Ciencia_Al_Poder Indeed that is probably caused by this one, however, I just merged the fix so if your problem persists it must be something else.

I'm not seeing any notifications since about 2 days in mediawiki.org from flow posts, even though my watchlist has changes from them. I assume the cause is this task, right? Or do you prefer to open a new task for investigation?

Ok, maybe I did not understood the problem correctly. With $wgAllowMicrodataAttributes = true;, <meta> tags are allowed on wikitext, but only as a normal element in the same place where they appear in wikitext, they aren't put in the <head> section.

Apparently, on SQLServer the default for varbinary should be (0x)