Hi!
We've recently noticed on Polish Wikiquote that abuse filters set to
prevent creation of accounts during waves of vandalism are leaky.
Some `autocreateaccount` actions do not trigger the filter, even though
they would satisfy the conditions. We have first observed this behavior
at the end of March (https://phabricator.wikimedia.org/T391096), but
these leaks seem to be present now as well.
The expected action was that filter prevents an account to be created.
Is it possible that introduction of SUL3 changed some aspect of filters
that prevent account creation? Has someone maybe also noticed a similar
issue on their wiki project?
Regards,
Marcin
User:Msz2001
Hello all!
The Search Platform Team usually holds an open meeting on the first
Wednesday of each month. Come talk to us about anything related to
Wikimedia search, Wikidata Query Service (WDQS), Wikimedia Commons Query
Service (WCQS), etc.!
Feel free to add your items to the Etherpad Agenda for the next meeting.
Details for our next meeting:
Date: Wednesday, May 7, 2025
Time: 15:00-16:00 UTC / 08:00 PST / 11:00 EST / 17:00 CET
Etherpad: https://etherpad.wikimedia.org/p/Search_Platform_Office_Hours
Google Meet link: https://meet.google.com/vgj-bbeb-uyi
Join by phone: https://tel.meet/vgj-bbeb-uyi?pin=8118110806927
Have fun and see you soon!
Guillaume
--
*Guillaume Lederrey* (he/him)
Engineering Manager
Wikimedia Foundation <https://wikimediafoundation.org/>
Hello everyone,
As part of the RESTBase Sunset effort, some endpoints will be phased out in
favor of better and more stable alternatives.
The /page/data-parsoid
<https://en.wikipedia.org/api/rest_v1/#/Page%20content/get_page_data_parsoid…>
endpoint is now ready for deprecation. After some investigation we
discovered that this endpoint hasn't been used since VisualEditor migrated
to direct calling Parsoid in MediaWiki
<https://phabricator.wikimedia.org/T320529>.
Next steps: the endpoint is being marked as deprecated
<https://github.com/wikimedia/restbase/pull/1353>, following the existing
policy for REST endpoints
<https://www.mediawiki.org/wiki/API_versioning#Experimental> and it will be
turned off in 1 month. Traffic to this endpoint will be blocked starting
June 7th 2025 (06/07/2025) and code will be removed after that. Details
about the deprecation can be found in this phabricator task, T393557
<https://phabricator.wikimedia.org/T393557>.
Don't hesitate in getting in touch in case you have any questions or
concerns.
Best regards,
--
Mateus Santos
Product Manager - MediaWiki Engineering Group
Wikimedia Foundation
Hey all,
This is a quick note to highlight that we've created the REL1_44 branch for
MediaWiki core and each of the extensions and skins in Wikimedia git [0].
This is the first step in the release process for MediaWiki 1.44.0, which
should be out in June 2025, approximately six months after MediaWiki 1.43.0.
The branches reflect the code as of the last 'alpha' branch for the
release, 1.44.0-wmf.28, which is being deployed to Wikimedia wikis this
week for MediaWiki itself and those extensions and skins available there.
From now on, patches that land in the main development branch of MediaWiki
and its bundled extensions and skins will be slated for the MediaWiki 1.44
release, unless specifically backported [1].
If you are working on a critical bug fix that will affect the code in the
release, once the patch has been merged into the development branch, you
should propose it for backporting by cherry-picking to the REL1_44 branch.
If you are working on a new feature, that should now not be backported. If
you have an urgent case where the work should block release for everyone
else, please file a task against the `mw 1.44-release` project on
Phabricator [2].
If you have tickets that are tagged for `mw-1.44-release`, please finish
them, untag them, or reach out to get them resolved in the next few days.
We hope to issue the first release candidate, 1.44.0-rc.0, in two weeks'
time, and if all goes well, to then release MediaWiki 1.44.0 a few weeks
after that.
[0]: https://www.mediawiki.org/wiki/Bundled_extensions_and_skins [1]:
https://www.mediawiki.org/wiki/Backporting_fixes [2]:
https://phabricator.wikimedia.org/tag/mw-1.44-release/
Best regards, -- Mateus Santos (he/him) Product Manager MediaWiki
Engineering Group
MediaWiki now supports adding context fields to all log events within the
current request. You can use
LoggerFactory::getContext()->->add( [ 'myCustomField' => ... ] );
to add a field to all subsequent logs in the request, or
$scope = LoggerFactory::getContext()->->addScoped( [ 'myCustomField' =>
... ] );
to do it within a given scope.
For some of the existing usage, see
https://gerrit.wikimedia.org/r/q/hashtag:%22global-logging-context%22
(For example, you can now filter Logstash to events logged in a specific
job class with context_job_type, or a given special page with
context_special_page_name.)
For more information, see https://phabricator.wikimedia.org/T142313
I want to build something to monitor the [[WP:DYK]] system on enwiki. I want to look at the length of various queues: nominations, approved nominations, number of hook sets ready for publication, perhaps a few more. Update times will be perhaps as low as once per day, certainly no faster than once per hour. Initially all I want to do is graph these. Eventually I might want to do some alerting.
In the old days, I would just have a simple script that threw some numbers as statsd. Looking at https://wikitech.wikimedia.org/wiki/Prometheus, it looks like that translates into using the pushgateway, but it's far from clear what I need to do to set this up. The docs talk about puppet, and certificates. Can somebody walk me through the setup?
Hello,
I'm currently verifying the technical viability of a category entry sorting problem on Chinese Wikipedia:
As is known to everyone, Chinese Wikipedia is a multi language variant wiki. This raises a problem as different regions have different Romanization system of Chinese. For instance, Mainland China exclusively use Pinyin as for sorting, while Taiwan uses Zhuyin (or Bopomofo), and there isn't even a popular one in Hong Kong so people tend to use stroke count for sorting. This situation brings requirements for separating category collations by user language variant preference.
However, MediaWiki only allows settings a single $wgCategoryCollation currently (https://www.mediawiki.org/wiki/Manual:$wgCategoryCollation). I'm writing to ask:
- Is it possible to have different category collations according to the current language variant?
- If not, does it require a significant amount of work (such as changing database schema) to implement this feature?
Best regards,
diskdance
Hi all,
If you use the mwscript-k8s tool to launch MediaWiki maintenance scripts on
Kubernetes at WMF, or anticipate doing so due to deprecation of the classic
mwscript tool, then this message is relevant to you.
*What is changing?*
Starting Thursday, 8th of May, the mwscript-k8s tool will *only* support
launching maintenance scripts on PHP 8.1. From that point forward,
selecting 7.4 via the --php_version flag is no longer supported.
This follows an earlier change to default to PHP 8.1 on the 2nd of April.
See "Maintenance scripts launched with mwscript-k8s will migrate to PHP
8.1" [0] or [1] for details.
*What actions should I take?*
* If you have not yet adopted mwscript-k8s for launching maintenance
scripts, we recommend that you do so. The ability to launch scripts (e.g.,
on maintenance servers) using the classic mwscript tool will go away soon.
See also "Maintenance scripts are moving to Kubernetes" [2].
* If you have adopted mwscript-k8s, but have not used it since the switch
to PHP 8.1 on 2nd of April, we recommend that you do so in order to test
your script(s) on 8.1.
If you encounter an issue specific to PHP 8.1 compatibility, please open a
sub-task of [3] to report it.
*What about periodic maintenance jobs launched automatically on a timer?*
As before, this announcement pertains only to manually launching
maintenance scripts using the mwscript-k8s tool.
There is an ongoing parallel effort to migrate periodic jobs from the
maintenance servers to Kubernetes [4], where they already use PHP 8.1.
Please feel free to reach out if you have any questions or concerns, either
by responding to this email or reaching me on IRC (swfrench-wmf).
Many thanks,
Scott French
Service Ops SRE
[0]
https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/…
[1] https://phabricator.wikimedia.org/T387917
[2]
https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/…
[3] https://phabricator.wikimedia.org/T379874
[4] https://phabricator.wikimedia.org/T341555