We're planning a brief window for Phabricator updates this (US) morning.
I do not expect significant noticeable downtime, but a handful of
requests are likely to error out during the restart.
This update includes fixes for last week's UI changes, and one lingering
patch from upstream.
Phab task:
https://phabricator.wikimedia.org/T333516
As usual, we'll track work on #wikimedia-operations.
Thanks,
--
Brennen Bearnes
Release Engineering
Wikimedia Foundation
Hello all,
Starting in April 2023, MediaWiki will end Grade A support for browsers that
do not implement ES6 JavaScript.[0] This mostly affects the small number of
Internet Explorer 11 users. A very small number of iOS users who have not
upgraded to iOS 10 (released in 2017) are also affected.
Users with these browsers will still be able to browse and contribute to the
projects. Enhanced features will become unavailable. For example, the 2010
wikitext editor will not appear, scripts and gadgets will not operate, and
notification buttons will take you to a page rather than open a pop-out.
This change will affect fewer than 0.1% of page views to Wikimedia wikis. We
previously raised the standard (from ES3 to ES5) in April 2017.[1]
Providing JavaScript for IE 11 and other ES5 browsers adds a significant
maintenance burden. It also hinders site speed for all users. Microsoft
ended its official support for Internet Explorer 11 in June 2022,[2] and
entirely removed it from Windows 10 in February 2023.[3]
This change will land in the development branch used on all Wikimedia wikis
this April, to be released as part of MediaWiki 1.41 around November 2023.
Please help carry this message into your communities.
(Tech News will announce this change as well.)
For details about the JavaScript-less experience, see
https://www.mediawiki.org/wiki/Special:MyLanguage/Compatibility#Browsers
[0] https://caniuse.com/es6 listing browser support for ES6
[1] https://phabricator.wikimedia.org/T128115
[2]
https://blogs.windows.com/windowsexperience/2021/05/19/the-future-of-intern…
[3]
https://techcommunity.microsoft.com/t5/windows-it-pro-blog/internet-explore…
Yours,
--
*James D. Forrester* (he/him <http://pronoun.is/he> or they/themself
<http://pronoun.is/they/.../themself>)
Wikimedia Foundation <https://wikimediafoundation.org/>
Hi all,
On Thursday we will be issuing a security and maintenance release to all
supported branches of MediaWiki.
The new releases will be:
- 1.35.10
- 1.38.6
- 1.39.3
This will resolve one issue in MediaWiki core, and two issues in bundled
extensions along with bug fixes included for maintenance reasons. This
includes various patches for PHP 8.0, PHP 8.1 and PHP 8.2 support.
We will make the fixes available in the respective release branches (plus
1.40 which is currently in alpha candidate status) and master in git.
Tarballs will be available for the above mentioned point releases as well.
A summary of some of the security fixes that have gone into non-bundled
MediaWiki extensions will also follow later.
As a reminder, 1.38 is due to become end of life (EOL) in June 2023. 1.38.7
(due in June 2023 on the usual release cadence) is expected to be the last
release for this branch. It is recommended to upgrade to 1.39 (the next LTS
after 1.35).
[1] https://www.mediawiki.org/wiki/Version_lifecycle
Hi,
I was surprised that the blocking interface followed others, and
automatically and unchangeably fills the field with the user name or IP.
Thus I cannot write a range after the IP any more. I captured a very small
image with the problem, but it is not allowed here.
Now, while range block for IPv4 anons is an everyday task, range block for
IPv6 anons is compulsory every time. We give /64, otherwise it is
senseless. By this time, I just wrote "/64" on the blocking interface after
the IP.
I don't know, when and why happened this change, but it makes blocking very
tricky uncomfortable. What I can do, write /64 into the URL at the
contributions of the vandal, but that is really not what I dreamt about.
Can somebody explain, why this happened? Is there a way of range blocking
that I am not aware of? Shall I ticket a bug?
--
Bináris
Hello
*Phabricator will be down for 30 minutes tomorrow (Tue, 28 Mar 2023)
between 14:00–16:00 UTC* due to network switch upgrades in its data center
row[0].
Apologies for the inconvenience :(
Tyler Cipriani (he/him)
Engineering Manager, Release Engineering
Wikimedia Foundation
[0]: <https://phabricator.wikimedia.org/T330165>
Hi all,
I wanted to quickly announce two new classes I added to MediaWiki core the
other day: ExtensionServicesTestBase
<https://gerrit.wikimedia.org/g/mediawiki/core/+/master/tests/phpunit/integr…>
and ExtensionJsonTestBase
<https://gerrit.wikimedia.org/g/mediawiki/core/+/master/tests/phpunit/integr…>.
Both are abstract base classes for PHPUnit tests; by adding a test class
extending one of these base classes, an extension can *opt into* additional
tests, with very little extra code in the extension itself. If you don’t
want to do that, nothing will change for you :)
ExtensionServicesTestBase can be used to test “ExtensionServices” classes
(e.g. CognateServices or WikibaseRepo). These classes are described on
mw:Dependency
Injection § Service registration in extensions
<https://www.mediawiki.org/wiki/Dependency_Injection#Service_registration_in…>;
basically, they’re a bunch of boilerplate code that makes an extension’s
services in the service container easier to work with (
CognateServices::getStore() is equivalent to $services->getService(
'CognateStore' ), but the former can be autosuggested by the IDE and also
has a known return type). An ExtensionServicesTestBase subclass tests that
this boilerplate code looks like you’d expect it to: the methods are
static, their name matches the service name, etc. Nothing exciting, but
nice to have if you use this “ExtensionServices” pattern.
ExtensionJsonTestBase is more exciting. The tests in this class read your
extension.json, and try to create the various API modules, special pages,
etc. that are specified in there, according to their factory
specifications. This ensures, for instance, that the list of services
specified in extension.json actually matches what the configured
constructor or factory method expects (e.g. in case you added a service to
the constructor and your unit test, but forgot to add it to
extension.json), which might otherwise only be caught by browser tests
(even integration tests don’t usually use the extension.json factories).
More importantly, the tests also ensure that no HTTP or database
connections are made when all these things are created. Services that make
network requests as soon as they’re created, rather than only when they’re
used, have been a performance issue in Wikibase in the past (T243729
<https://phabricator.wikimedia.org/T243729>), and these tests are meant to
prevent such a thing from happening again.
(In theory, all of this might work more or less well for skins as well as
extensions. I have no reason to try that, since I don’t work on skins, but
if you’re interested in it, feel free to experiment with it and see if it
works out. I’ll point out that MediaWiki’s ExtensionJsonValidationTest,
which “Validates all loaded extensions and skins using the
ExtensionRegistry against the extension.json schema in the docs/ folder”,
could be a precedent for an “ExtensionSomething” class actually covering
both extensions and skins, so I don’t think the two new TestBase classes
would necessarily need to be renamed.)
A minimal example of using both of these tests in an extension might look
like this:
class EntitySchemaServicesTest extends ExtensionServicesTestBase {
protected string $className = EntitySchemaServices::class;
protected string $serviceNamePrefix = 'EntitySchema.';
}
class EntitySchemaExtensionJsonTest extends ExtensionJsonTestBase {
protected string $extensionJsonPath = __DIR__ .
'/../../../../extension.json';
}
Cheers,
Lucas
--
Lucas Werkmeister (he/er)
Software Engineer
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0)30-577 11 62-0
https://wikimedia.de
Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
https://spenden.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.
Hi,
Does anybody know where this comes from, i.e., "view structure for view
'page_view'" (see below)? I was not able to find anything about this. Is
this from MediaWiki core or from some extension I do not know about?
Google suggests some Google Analytics-related stuff but ... Does not
look like it to me. For context: Line 50013 prevents me from importing a
database correctly.
Thanks a lot for a pointer or some insight.
Cheers, Karsten
--
-- Final view structure for view `page_view`
--
/*!50001 DROP VIEW IF EXISTS `page_view`*/;
/*!50001 SET @saved_cs_client = @@character_set_client */;
/*!50001 SET @saved_cs_results = @@character_set_results */;
/*!50001 SET @saved_col_connection = @@collation_connection */;
/*!50001 SET character_set_client = utf8 */;
/*!50001 SET character_set_results = utf8 */;
/*!50001 SET collation_connection = utf8_general_ci */;
/*!50001 CREATE ALGORITHM=UNDEFINED */
/*!50013 DEFINER=`root`@`localhost` SQL SECURITY DEFINER */
/*!50001 VIEW `page_view` AS select `page`.`page_title` AS
`page_title`,`page`.`page_counter` AS `page_counter` from `page` */;
/*!50001 SET character_set_client = @saved_cs_client */;
/*!50001 SET character_set_results = @saved_cs_results */;
/*!50001 SET collation_connection = @saved_col_connection */;
/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;
/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;
Hi everyone,
Do you want to present at Wikimania 2023 <https://www.wikimania.org>?
Wikimania program submissions are open now until the end of day Tuesday 28
March, anywhere on earth <https://zonestamp.toolforge.org/1680091140>.
After the 2020 edition of Wikimania was postponed and the two following
online editions, Wikimania is now back with an *in-person*, *hybrid* and
*on-demand* event in Singapore, from 16-19 August 2023!
The theme for Wikimania 2023 is *Diversity, Collaboration, Future*. There
are 11 tracks to choose from: familiar ones like Community Initiatives,
Governance, GLAM, or Technology; and new ones like Open Data and Wild
Ideas. You can submit an interactive workshop or panel, a lecture, a short
lighting talk or a poster for our dedicated poster session. Making a
submission is easy and we have upcoming conversation hours on Sunday March
19 at 00:00 and 14:00 UTC to help you out. You can also reach out to us on
the talk page or on Telegram. All the information you need is available on
wiki <https://wikimania.wikimedia.org/wiki/2023:Program/Submissions>.
To explore suggested topics for the track, please see here
<https://wikimania.wikimedia.org/wiki/2023:Program/Submissions#Tracks>: to
browse through the already submitted proposals, please go to the Program
Submission category
<https://wikimania.wikimedia.org/wiki/Category:Wikimania_2023_Program_submis…>
on the Wikimania wiki.
We welcome your session proposals. Read more on *Diff*
<https://diff.wikimedia.org/2023/02/28/be-part-of-the-wikimania-2023-program/>and
start preparing your ideas!
Kind regards,
*Ciell*
On behalf of the Wikimania 2023 Core Organizing Team