I rebase to master
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Sat, Apr 6
Fri, Apr 5
Jan 16 2024
Dec 1 2023
Sep 24 2023
Sep 19 2023
Dec 1 2022
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.
Nov 23 2022
Nov 6 2021
I am very interested in this task.
Oct 22 2021
Sep 16 2021
Duplicate with T250297.
Sep 13 2021
Aug 8 2021
Jun 3 2021
The patch need someone to review :)
May 26 2021
Oct 27 2020
Looks like already fix in other patch
Oct 25 2020
The same question will appear after you create MediaWiki:Licenses?
Oct 22 2020
This is not a releace blocker since related to titlekey extension.
Sep 16 2020
Aug 3 2020
I think it related to T259402.
Jul 29 2020
In T257879#6344561, @Tgr wrote:As it is now, 1.35 supports both 7.2 and 7.3.
Jul 23 2020
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?
Jun 27 2020
Jun 25 2020
Can we announce that MW 1.35 supports PHP 7.4?
Mar 20 2020
Does this ticket conflict with T207621?
Feb 13 2020
Can someone review this simple patch?
Feb 11 2020
Feb 10 2020
Feb 8 2020
We need to port assertArraySubset() to mediawiki. We have two plans:
- Copy the code to MediaWikiTestCaseTrait.
- Or add https://packagist.org/packages/dms/phpunit-arraysubset-asserts as a dev dependency and call it.
Feb 4 2020
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.
Feb 2 2020
This happens when a unix-like OS has no posix extension installed.
Dec 21 2019
There is currently no such needed, but it may need in the future.
Dec 8 2019
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
Nov 27 2019
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.
Nov 20 2019
Reopen as a backport patch haven't not merge yet .
Oct 14 2019
I think it is better to put relevant information in the manual namespace.
Oct 7 2019
Oct 4 2019
Can be mark as resolve?
Seem wikimedia/avro already bump up to 1.9.0 in composer.jsom.
Oct 2 2019
Tagging MW-1.35-release, make this ticket as a MW 1.35 release blocker.
Sep 30 2019
Sep 25 2019
I am trying to advance this ticket.
Sep 20 2019
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.
Sep 16 2019
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.
Sep 13 2019
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.
Sep 10 2019
About "Service disabled" warning, see T229601.
Sep 9 2019
Sep 7 2019
Sep 5 2019
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.
Aug 21 2019
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.
Aug 20 2019
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 missrainwang@163.com? Thank you!
Aug 15 2019
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.
Aug 14 2019
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).
Aug 10 2019
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)
Aug 9 2019
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().
Aug 8 2019
Aug 6 2019
In T229743#5395240, @Viztor wrote:While MediaWiki:Conversion-ns114 seems to be part of the LanguageConverter extension.
Aug 5 2019
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.
Aug 4 2019
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.