I rebase to master

In T322143#8388684, @Tgr wrote:

I think think the action would be to split the drop command into a separate file and wrap it in a try-catch. IMO we should fix this ASAP as 1.39 is pending release and that's when most people would encounter this bug.

I am very interested in this task.

Duplicate with T250297.

The patch need someone to review :)

Looks like already fix in other patch

The same question will appear after you create MediaWiki:Licenses?

This is not a releace blocker since related to titlekey extension.

I think it related to T286302.

In T257879#6344561, @Tgr wrote:

As it is now, 1.35 supports both 7.2 and 7.3.

From description:
tangentially, that line should be preceded by a comment listing the possible message keys

Should I write a comment before the output to list the possible i18n keys?

Can we announce that MW 1.35 supports PHP 7.4?

Does this ticket conflict with T207621?

Can someone review this simple patch?

We need to port assertArraySubset() to mediawiki. We have two plans:

1. Copy the code to MediaWikiTestCaseTrait.
2. Or add https://packagist.org/packages/dms/phpunit-arraysubset-asserts as a dev dependency and call it.

In my vision, directly add a method similar to getSize() (maybe getCharCount()) in Content implementation to get the number of characters. So I mark MediaWiki-ContentHandler.

@Aklapper What should I do if I want to advance this request to be approved? As long as people agree with this request, I can write code for this.

This happens when a unix-like OS has no posix extension installed.

There is currently no such needed, but it may need in the future.

I use PHP 7.3, error msg:

Your requirements could not be resolved to an installable set of packages.

In T192167#5681827, @gerritbot wrote:

Change 552166 merged by jenkins-bot:
[mediawiki/core@master] Upgrade PHPUnit to version 7

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

In T216345#5695930, @brion wrote:

Ah, OSs shipping old stuff is always fun. :D No real danger to it, and it's clear enough in the code if we refactor and clean it out later. :)

No special reason. Just because Centos system provides old ffmpeg by default.

Reopen as a backport patch haven't not merge yet .

I think it is better to put relevant information in the manual namespace.

FYI, https://www.php.net/ChangeLog-7.php#7.2.9.

Can be mark as resolve?

Seem wikimedia/avro already bump up to 1.9.0 in composer.jsom.

Tagging MW-1.35-release, make this ticket as a MW 1.35 release blocker.

I am trying to advance this ticket.

I think we can announce support for PHP 7.4 in MediaWiki 1.35 release.

Base on T137926, MW core no longer uses curl, the motive for this ticket note disappears.

In T233012#5496253, @TK-999 wrote:

The issue in the RemexHTML lib seems to have been fixed in https://gerrit.wikimedia.org/r/c/mediawiki/libs/RemexHtml/ /531022.

In T229992#5405026, @RazeSoldier wrote:

I wrote a test to illustrate the situation. But the integration test results are very strange, the test fails under PHP and the test passes under HHVM.

About "Service disabled" warning, see T229601.

In T229601#5469783, @Jdforrester-WMF wrote:

Hey there, should this be moved to 1.35? The cut is a couple of weeks away. If it needs to go out in 1.34, is there anything I can do to help get it out of the door?

In T217855#5469788, @Jdforrester-WMF wrote:

Hey there, should this be moved to 1.35? The cut is a couple of weeks away. If it needs to go out in 1.34, is there anything I can do to help get it out of the door?

It seems that this is because OOUI is not setup in the extension.

Before discussing when the change is causing the problem, we first need to find the time to first discover the problem. The start time for the problem may much earlier than this ticket was created.

In T225364#5423971, @missrainwang wrote:

I have met the same problem with you, and I want to know how to sove this problem……Could you please tell me, and send email to [email protected]? Thank you！

Why use a newer version? Here are a few of my insights:

• Developers can use the latest syntax to achieve a better system architecture
• Older versions are not supported and have security risks.
• The new version usually means an improvement in performance, and PHP 5 to 7 is an example.
• Only supporting fewer versions means that developers can only focus on compatibility between a small number of versions.

I see it in https://www.php.net/ChangeLog-7.php#7.3.8

Fixed bug [[ http://bugs.php.net/78269 | #78269 ]] (password_hash uses weak options for argon2).

I have to say that MediaWiki.org also has this problem. The sidebar I saw was completely different from what I saw before. (I use zh as my interface language)

I wrote a test to illustrate the situation. But the integration test results are very strange, the test fails under PHP and the test passes under HHVM.

Almost all interface messages are obtained via Message::fetchMessage(), it get real message from MessageCache::get().

In T229743#5395240, @Viztor wrote:

While MediaWiki:Conversion-ns114 seems to be part of the LanguageConverter extension.

I can reproduce the problem that pagetitle wrong when I set my interface language to zh. [[MediaWiki:Pagetitle/zh]] is the default message, but this should not be the cause of the problem, because wgLanguageCode for zhwiki is zh, and [[MediaWiki:Pagetitle]] will cover [[MediaWiki:Pagetitle/zh]]. But I don't know why the coverage didn't take effect.

I think this problem only appears on some wikis. In my development environment, I can't reproduce this problem.

In T229743#5390701, @Viztor wrote:

The practice has been for years, unless that consensus change, there is no reason to have inconsistency among zh projects and within zhwikisource itself specifically.

Pleace refer this case.

For this ticket, $wgExtraNamespaces unable to resolve different versions for different users (zh-hans/zh-hant). This variable defines "real name", not alias. So in this case, use [[MediaWiki:Conversion-ns<namespace ID>]] is recommended.