This email is a summary of the Wikimedia production deployment of
1.40.0-wmf.7
Conductor: Jaime Nuche
Backup Conductor: Antoine Musso
Blocker Task: T320512 <https://phabricator.wikimedia.org/T320512>
Current Status: Live everywhere <https://versions.toolforge.org/>
_____
*📊 Stats*
Sparklines comparing the last 5 trains.
213 Patches ▁▆█▃▁
0 Rollbacks ██▁█▁
0 Days of delay █▁▁▁▁
0 Blockers ▂█▂█▁
Moar stats in the train-stats repo
<https://gitlab.wikimedia.org/repos/releng/train-stats>
_____
*🎉 Traintastic Folks ✨*
It was a quiet week. And—wow—a release with no blockers, no delays, and no
rollbacks!
So thanks to the folks who backported some needed changes over the past
week:
- *Tim Starling* for handling multi-byte unicode capitalization changes
between php7.2 and php7.4: https://phabricator.wikimedia.org/T292552
- *Amir Sarabadani *for finishing work to make running maintenance
scripts that interact with the database better and safer:
https://phabricator.wikimedia.org/T298485
Until next train!
Tyler Cipriani (he/him)
Engineering Manager, Release Engineering
Wikimedia Foundation
Hi,
The method ContentHandler::getDataForSearchIndex() is used by (non-core) MW
SearchEngine implementations and was added in MW 1.28 to gather the data to
be indexed.
In 1.40 this signature will change to let SearchEngine implementations pass
an optional RevisionRecord param
<https://gerrit.wikimedia.org/r/c/mediawiki/core/+/832957/10/includes/conten…>
to clarify what revision is being indexed (instead of assuming that the
"latest" was requested).
This is a breaking change if you maintain a ContentHandler subclass and
have overridden the getDataForSearchIndex() method, you will have to change
your method signature from:
public function getDataForSearchIndex( WikiPage $page, ParserOutput
$output, SearchEngine $engine )
to
public function getDataForSearchIndex( WikiPage $page, ParserOutput
$output, SearchEngine $engine, RevisionRecord $revision = null )
If you own a SearchEngine implementation and rely on
ContentHandler::getDataForSearchIndex() this is not a breaking change but
it is advised to pass this new RevisionRecord parameter when calling it.
Relatedly the hook SearchDataForIndex
<https://www.mediawiki.org/wiki/Manual:Hooks/SearchDataForIndex> will be
deprecated (silently) and SearchDataForIndex2
<https://www.mediawiki.org/wiki/Manual:Hooks/SearchDataForIndex2> should be
used instead.
Please let me know if you have questions/strong objections to this approach.
--
David Causse
Hi there, I know this must be frustrating for you guys, but keep in mind
I've just figured out all this a few weeks ago so please have patience with
me.
JHartnick
Hi,
I work with large categories. My dream is to upload a list of articles to a
wikipage, where there are checkboxes next to the titles, and I can click.
The page would return a filtered lists which I can use with my bot to
change the category.
On an advanced level, several columns of checkboxes could exist do divide
the category to subcats.
Checkbox is not the aim, it is only a way I can explain what I want to do.
Of course, I can do it in Excel, but 1. on a wikipage I can move my mouse
on the title and see the part of the content, and in Excel I cannot, 2. I
can offer a wikipage to another user to make the filtering, an then do the
work with bot.
As far as I see, the most natural way is to code this in PHP, which needs a
MediaWiki extension, if anyone feels like, and likes my idea...
By that time, do you know about such service on the tolserver? Or can I do
it myself somehow with Lua?
--
Bináris
Hi everyone,
Today I created a task proposing that exception handling and annotations be
standardized in MediaWiki: https://phabricator.wikimedia.org/T321683.
This would affect all MediaWiki code written in PHP (core, extensions, and
skins), and the standardization itself will require a lot of effort.
Therefore, I invite you to share any questions, thoughts, or concerns that
you may have on the task.
Thank you,
--
https://meta.wikimedia.org/wiki/User:Daimona_Eaytoy
"Daimona" is not my real name -- he/him
hello
can somebody help with reviewing technical aspects of a cyrillic <->
latin converter ?
it has been said that the file is too big and the commit is too big.
the code is nearly 3500 lines. i think it is not worth to divide it
into separate library or files. as library it would be very fit for
this conversion, not usable for other things. i feel making library as
"premature optimisation". and laziness, feeling as useless work. also
just dividing into files, into classes. 3500 lines is not very hard
for me to browse.
if anybody wants to separate it into classes and files, feel free to
edit, if you think it is good for mediawiki. i do not want to make
such change by myself. i can help with proper names (for classes,
variables).
i said variables because it is possible to convert some lists of php
commands into for cycles with arrays, just to make it look shorter. i
think it is also like premature optimisation, i have more freedom when
they are as they are, in further editing. i do not want to make such
change by myself. feel free to edit.
quick link to the newest version of the code:
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/164049/219/includes/langu…
.
also it was suggested to get rid of regex lookahead and lookbehind.
and strtr was like suggested. i think i probably cannot easily make
those changes. and i think, is strtr really faster than preg_replace?
i googled for benchmark results and i do not see, in the first page,
like 10 results.
the code is big, but it just modifies a string.
tatar wikipedians have asked me about this code, yesterday, and now i
try this approach, to write to this mailing list, before other ways to
go. maybe there is just a lack of some people who can review this code
and approve it, and maybe this mailing list can help.
other ways to go to the problem's pages:
https://phabricator.wikimedia.org/T27537 ,
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/164049 .
