Hi,
The SelectQueryBuilder class was introduced a year ago
<https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/…>
and it's seen some adoption, mostly in core. I've also noticed that
there are two classes that extend it in core, the PageSelectQueryBuilder
and UserSelectQueryBuilder. I really like how this approach allows for
better separation of DB code from the rest, which has always been a
complete and utter mess in MW. I would like to do something similar in
an extension, but the base class is currently not explicitly marked as
stable to extend and thus, according to the stable interface policy
<https://www.mediawiki.org/wiki/Stable_interface_policy#Stable_to_extend>,
the interface could be broken at any time. My question is – are there
any plans to make the class stable to extend? Is there a rough roadmap
for its development? If the class is unstable to extend for some reason
– what are the expected changes to come?
Thanks!
--
Ostrzyciel
Hello,
If you don't do anything with metadata fields of file tables (image table
for example) in replicas, you can ignore this email.
"image" table in Wikimedia Commons is extremely big (more than 380GB
compressed) and has been causing multiple major issues (including an
incident recently). Deep inspections revealed that more than 80% of this
table is metadata of PDF files, around 10% is metadata of DjVu files and
the 10% left is the rest of the information. This clearly needs fixing.
The work has been done on this by Tim Starling and we are slowly rolling
out two major changes:
First, format of metadata in the database (for example img_metadata field
in image table) will change for all files. It used to be php serialization
but it will be changed to json. You can see an example of before and after
in https://phabricator.wikimedia.org/T275268#7178983 Keep it in mind that
for some time this will be a hybrid mode that some files will have it in
json format and some will have it in php serialization. You need to support
both formats for a while if you parse this value.
Second, some parts of metadata for PDF and later DjVu files won't be
accessible in Wikimedia Cloud anymore. Since these data will be moved to
External Storage and ES is not accessible to the outside. It's mostly OCR
text of PDF files. You can still access them using API
(action=query&prop=imageinfo).
Nothing to the outside users will change, the API will return the same
result, the user interface will show the same thing but it would make all
of Wikimedia Commons more reliable and faster to access (by indirect
changes such as improving InnoDB buffer pool efficiency), improves time to
take database backups, enables us to make bigger changes on image table and
improve its schema and much more.
I hope no one heavily relies on the img_metadata field in the cloud
replicas but if you do, please let me know and reach out for help.
You can keep track of the work in https://phabricator.wikimedia.org/T275268
Thank you for understanding and sorry for any inconvenience.
--
Amir (he/him)
Hello,
Platform Engineering Team is going to make breaking changes to the MediaWiki core CentralIdLookup class [1]
We are changing the accepted types for the $user parameter from User to UserIdentity. This should not affect
any callers, but any class that extends CentralIdLookup will be broken. The only extensions known to us that
implement CentralIdLookup are CentralAuth and Wikibase, and we are updating them alongside with the core class.
If you maintain an extension which implements a custom CentralIdProvider, please respond to this email
and we will either help you update your extension, or work out a new plan for converting the core class.
Additionally, we are loosening the return type guarantees for CentralIdLookup::localUserFromCentralId from
User to UserIdentity. This could potentially affect the callers, but we’ve updated all extensions to be compatible
with the new guarantees. If you maintain an extension that is not available on codesearch[2] please reach out to us.
Best regards. Petr.
Staff Software Engineer.
Platform Engineering Team.
WMF
1. https://gerrit.wikimedia.org/r/c/mediawiki/core/+/700991 <https://gerrit.wikimedia.org/r/c/mediawiki/core/+/700991>
2. https://codesearch.wmcloud.org/extensions/?q=localUserFromCentralId&i=nope&… <https://codesearch.wmcloud.org/extensions/?q=localUserFromCentralId&i=nope&…>
Hi,
Lots of people thanked me for deploying mailman3 but I want to mention that
it would have not been possible without Wikimedia Cloud Services team
giving a lot of resources to me so I could have a test setup and puppetize
mailman3 easily which in turn made deployment to production much easier.
Thank you for providing such a critical infrastructure to us! Keep up the
great work.
Best
Hello all,
I have a bot at toolforge, running weekly once in cron job using "jsub"
Followed the below link for the setup.
https://wikitech.wikimedia.org/wiki/Help:Toolforge/Pywikibot
Getting the JOBNAME.out and JOBNAME.err files at the home folder.
Is there any other way like email notification to get alerts, if some
error happens?
I think the files JOBNAME.out and JOBNAME.err will be keep on growing
on the bason host login.toolforge.org
How to avoid this?
Thanks.
--
Regards,
T.Shrinivasan
My Life with GNU/Linux : http://goinggnu.wordpress.com
Free E-Magazine on Free Open Source Software in Tamil : http://kaniyam.com
Get Free Tamil Ebooks for Android, iOS, Kindle, Computer :
http://FreeTamilEbooks.com
Hi all,
Tomorrow we will be issuing a security and maintenance release to all
supported branches of MediaWiki.
The new releases will be:
- 1.31.15
- 1.35.3
- 1.36.1
This will resolve 1 minor issue in MediaWiki core and also includes some
fixes previously committed to git, including minor security and hardening
patches along with bug fixes included for maintenance reasons.
We will make the fixes available in these respective release branches, and
also master. 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.
As a reminder, 1.31 (the old LTS) was due to become end of life (EOL) in
June 2021. 1.35 (the new LTS) is supported until September 2023. However,
to try and meet our LTS-LTS overlap commitments (1.35 was late due to
COVID), 1.31 will get best-efforts extra support until the end of September
2021. Practically, this will mean 1.31 is only tested on PHP 7.2, removing
the burden of testing on PHP 7.0 and 7.1 which both became EOL in 2019.
This will also mean 1.31 is eligible for one final security release in late
September 2021 before formally becoming EOL.
[1] https://www.mediawiki.org/wiki/Version_lifecycle
Hello,
does Mailman 3 (as-installed by Wikimedia) have an API I could use?
I'm an administrator of WMCZ's internal maillist, and it would help me if I
could sync the addresses with evidence of members with a script rather than
having to do it manually each time a new member is admitted (or quits).
Thanks,
Martin
There's an ongoing discussion about how PHP return typehints should be
formatted in MediaWiki code:
function foo(): int {
or
function foo() : int {
If you are interested, please vote here:
https://phabricator.wikimedia.org/T220719
(The permission system for votes is somewhat inflexible. If you want to
vote but can't, please leave a comment.)