The 1.36.0-wmf.8 version of MediaWiki is blocked[0].
The new version is deployed to groups 0,1[1], but can proceed no
further until these issues are resolved:
* skins.vector.styles.legacy sets hr{height:0}, hiding horizontal
rules - https://phabricator.wikimedia.org/T262507
(fix being confirmed in beta)
Once these issues are resolved train can resume. If these issues are
resolved on a Friday the train will resume Monday.
Thank you for your help resolving these issues!
-- Your humble train toiler
[0]. <https://phabricator.wikimedia.org/T257976/>
[1]. <https://versions.toolforge.org/>
--
Jeena Huneidi
Software Engineer, Release Engineering
Wikimedia Foundation
Hello,
This email contains updates for September 9, 2020. For the HTML version,
see: https://www.mediawiki.org/wiki/Scrum_of_scrums/2020-09-09
Cheers,
Deb
------------------------
*= 2020-09-09 =*
== Product ==
=== Web ===
* Updates:
** '''Summary''': moving the search header for Vue.js search.
** [[Reading/Web/Desktop Improvements|Desktop Improvements Project (Vector
/ DIP)]]:
*** [[phab:T260867|PrefUpdate captures user preference modifications at
registration]]
*** [[phab:T261686|Refinements to search box in site header]]
*** [[phab:T260412|[Spike 10hrs] Determine steps necessary for switch to
header-first DOM]]
*** [[phab:T259761|Reduce space between sidebar and content]]
*** [[phab:T259250|A/B test setup for search changes]]
*** [[phab:T249363|Move the existing search to the header in preparation
for Vue.js search development]]
*** [[phab:T252774|Checkbox and mediawiki.toc.styles styles should be
merged into a single ResourceLoader module]]
*** [[phab:T251544|Add user journey performance tests for Vector's Legacy
and Vue.js search]]
*** [[phab:T244392|Vue.js search case study]]:
**** See [[Reading/Web/Desktop Improvements/Vue.js case study/Status
log|weekly status updates]].
** Mobile website (MinervaNeue / MobileFrontend):
*** [[phab:T261971|TypeError: e.on is not a function. (In
'e.on("hide",(function(){e.emit("_om_hide")}))', 'e.on' is undefined)]]
*** [[phab:T259291|Image loader is not resilient (Uncaught Error:
'retryPath' must be set in options param. Received:)]]
*** [[phab:T258096|Regression: Nested references do not open if user clicks
on [ or ] (which are wrapped in span)]]
** Standardization
*** [[phab:T256897|Decide on and clean up naming of CSS classes identifying
menus in toolbars and the sidebar.]]
** Page Previews
*** [[phab:T259652| TypeError: u.abort is not a function]]
** Miscellaneous
*** [[phab:T262092|Update to user styles and scripts required: .menu,
.vectorTabs and .vectorMenu no longer supported]]
*** [[phab:T260519|ToggleSwitchWidget: widget has wrong role 'checkbox'
when it should be 'switch']]
*** [[phab:T259630|TypeError: results.error is undefined]]
*** [[phab:T258428|TypeError: element is undefined (getAccessKeyLabel)]]
*** [[phab:T258337|Advanced search doesn't handle removing template
name]][[phab:T260519|ToggleSwitchWidget: widget has wrong role 'checkbox'
when it should be 'switch']]
*** [[phab:T249167|Removing category filter in Advanced search shows
"[object Object]"]]
*** [[phab:T203023|skins.monobook.mobile.uls dependency doesn't do mobile?]]
*** [[phab:T262098|SkinMustache should provide standard portlet (menu)
data]]
*** [[phab:T235008|ExampleSkin should use SkinMustache]]
*** [[phab:T259912|Keyboard Tabbing Order for PopupWidget in
Reverse(shift-tabbing) is out-of-order]]
*** [[phab:T259906|Add 'volumeUp' icon in OOUI]]
*** [[phab:T253938|Future proof addPortletLink and work towards a standard
mw-portlet class for all menus across all skins]]
*** [[phab:T106244|URL encoded values using fallback 8-bit encoding
(invalid UTF-8) cause mediawiki.Uri to crash]]
--
deb tankersley (she/her)
sr program manager, engineering
Wikimedia Foundation
It does the same as the @ operator, except that it takes care to prevent a
very bad bug that existed before PHP 7. Details at
https://phabricator.wikimedia.org/T253461
If there are other issues or benefits, please write them on the task. The
overhead of AtEase is prerty minor, so really any benefit at all is likely
to tip the balance toward keeping it. But, in the event that there isn't
any, then perhaps we should slowly phase it out.
Best,
-- Timo
[---- Long mail - but only relevant to extension developers ----]
Greetings!
As some of you might know, on the Parsing Team [0], we are aspiring to
replace the core wikitext parser with Parsoid [1] on Wikimedia wikis late
next year and start to put to rest the two-parser ghost that has haunted us
for many years. In recent years, we achieved two major milestones along
the way: replace HTML4 tidy with HTML5 Remex [2], and port Parsoid from
Javascript to PHP [3].
Given that context, if you (help) maintain an extension that:
* uses a "parser hook" and/or
* uses the "parser API" (i.e. uses public properties / methods in
Parser.php, ParserOutput.php, ParserOptions.php, etc.)
please read on. If you don't fit that description, you can stop reading now!
Parsoid models and processes wikitext quite differently from the
core parser - all that Parsoid guarantees is that the rendering is largely
identical, not the specific process of generating the rendering. This
means that extensions that extend the behavior of the parser will need to
adapt to work with Parsoid instead to provide similar functionality. With
that in mind, we have been working to more clearly specify how extensions
need to adapt to the Parsoid regime.
PARSOID & EXTENSIONS:
At a high level, here are the questions we needed to answer, along with
some highly simplified answers:
1. How do extensions "hook" into Parsoid?
A. Extensions need to think in terms of transformations (convert this
to that) instead of parser pipeline events (at this point in the
pipeline, call this listener). An additional detail here is that
extensions cannot maintain global ordered state within extension code
since Parsoid doesn't guarantee handlers will be invoked in the same
order in which they showed up in page source. See the wiki [4] for
more details.
As for the mechanics of registration, Parsoid uses existing mechanisms
based on the extension.json file.
2. When the registered hook listeners are invoked by Parsoid, how do they
process any wikitext they need to process?
A. Parsoid provides all registered listeners with an API object to interact
with it. Direct use of Parsoid internals code is strongly discouraged
and will be enforced in various ways including via code review.
3. How is the extension's output assimilated into the page output?
A. The output is treated as a "fully-processed" page/DOM fragment (with
some caveats which will be clarified on wiki). It is appropriately
decorated with additional markup, and slotted into place into the page.
Extensions need not make any special efforts (aka strip state) to
protect it from the parsing pipeline.
Slides 8-12 of the August 12 2020 Tech Talk [7] goes over the differences.
Check the wiki [4] for more details of Parsoid's Extension API. It also
maps core parser hooks to Parsoid's extension functionality.
CURRENT STATUS:
We consider the current proposal to be in late draft stage. That said, as
we discover unsupported functionality, we will augment the set of hooks and
the Parsoid Extension API as needed.
While there are a wide variety of extensions in the MediaWiki universe
with varied use cases, our initial goal for the next year is just Wikimedia
wikis and hence extensions that are deployed on the Wikimedia wikis.
Once we are done with that, we will turn our attention to supporting
extension use cases in the wider MediaWiki universe. But, now is a
good time for all extension developers to study and review this API
and give us feedback.
Since the beginning of this year, we've refactored all of the extensions
we've written Parsoid versions of (Cite, Gallery, Poem, Pre, JSON) to
now strictly use the Parsoid Extension API without cheating by virtue
of being in the Parsoid codebase. So, this proposal is actually backed
by an implementation that is in production for Wikimedia wikis.
FEEDBACK:
Here is where you come in.
* If you maintain / develop an extension, please review the document
to see if your extension's use case is covered.
Ideally, leave your feedback on the Parsoid Extension API talk page [5]
since it helps keep it all in one place. Alternatively, you can also
leave questions / concerns / other feedback on the Phabricator task
we've filed for TechCom's RFC process [6].
* If you feel bold, start the process of updating your extensions *now*.
Note that your extension will need to operate with both the existing
core parser as well as Parsoid till such time we deprecate and stop
using the core parser.
There are known functionality gaps related to exposing ParserOutput
object and providing setFunctionHook functionality. If your extension
needs those, you should probably wait for us to fill that gap.
DOCS / MORE INFO / CONTACT:
* Check the wiki page [4] for docs and discuss on the talk page [5]
* Check the August 12, 2020 Tech Talk [7]
* Look at Parsoid code for extensions [8]
* Look at Parsoid docs for the Ext/ namespace [9]
* Talk to us on IRC in the #mediawiki-parsoid channel
* Email us at parsing-team(a)wikimedia.org
Thanks!
Subbu (on behalf of the Parsing Team).
-------------------------------------------------------------------------
0. https://www.mediawiki.org/wiki/Parsing
1. https://www.mediawiki.org/wiki/Parsing/Parser_Unification
2. https://blog.wikimedia.org/2018/07/09/tidy-html5-replacement/
3.
https://techblog.wikimedia.org/2020/02/12/parsoid-in-php-or-there-and-back-…
4. https://www.mediawiki.org/wiki/Parsoid/Extension_API
5. https://www.mediawiki.org/wiki/Parsoid/Talk:Extension_API
6. https://phabricator.wikimedia.org/T260714
7. Slides:
https://commons.wikimedia.org/wiki/File:Parsoid_%26_Extensions_August_2020_…
Video: https://www.youtube.com/watch?v=lS1xPkERWCM
8. https://github.com/wikimedia/parsoid/tree/master/src/Ext
9. https://doc.wikimedia.org/Parsoid-PHP/master/
Hello,
This is Amir from the CoC committee. Currently, there are two open
amendment proposals that haven't had much progress in the past years and I
would like to close them or at least make some progress. One of them in
particular is really important.
There are two major issues with the current appeal process:
* According to the CoC, the appeal body is a team in WMF that doesn't exist
anymore (for years now) [1] People in this team (who all are still working
for WMF) have moved to other teams and some haven't done anything with
technical communities for years now. We need to find an appeal body to
replace this. One suggestion is to have CRC [2] and its successor review
these cases but WMF legal should give the green light on this. Any other
suggestion is more than welcome.
* It's not clear that the appeal body would have the authority to override
the outcome of cases or they are just advisory or they are peers (they need
to discuss until there's a consensus among both).
Given the confidential nature of TCoC cases, having a robust appeal body
ensures a fair and just environment for technical contributions. Please
take a look and participate in the discussion:
https://www.mediawiki.org/wiki/Topic:Uay0vz6no8ayac3m
Thank you very much.
[1] https://meta.wikimedia.org/wiki/Community_Relations/Community_health
[2] https://meta.wikimedia.org/wiki/Trust_and_Safety/Case_Review_Committee
--
Amir (he/him)
Hello,
Due to the current situation, there are more and more collaborations
happening online instead. and now you can see Wikimedia-related discussion
groups in Slack, Discord, Telegram, Facebook, and many more. Besides being
scattered and inaccessible to people who don't have accounts in those
platforms (for privacy reasons for example), these platforms use
proprietary and closed-source software, are outside Wikimedia
infrastructure and some harvest our personal data for profit.
IRC on freenode is a good alternative but it lacks basic functionalities of
a modern chat platform. So we created Wikimedia Chat, a mattermost instance
in Wikimedia Cloud. Compared to IRC, you have:
* Ability to scrollback and read messages when you were offline
* Push notification and email notification
* You don't need to get a cloak to hide your IP from others
* Proper support for sharing media
* Two factor authentication
* A proper mobile app support
* Ability to add custom emojis (yes, it's extremely important)
* Profile pictures
* Ability to ping everyone with @here
* much much more.
You can use Wikimedia Chat by going to https://chat.wmcloud.org, anyone can
make an account. This is part of Wikimedia Social suite [1], the oher
similar project is "Wikimedia Meet". [2]
Some notes:
* This is done in my volunteer capacity and has been maintained by a group
of volunteers. If you're willing to join the team (either technical or
enforcing CoC, kicking out spammers, other daily work), drop me a message.
* Privacy policy of Wikimedia Cloud applies: https://w.wiki/aQW
* As a result, all messages older than 90 days get automatically deleted.
* As a Wikimedia Cloud project, all of discussions, private and public are
covered by Code of conduct in technical spaces: https://w.wiki/AK$
Hope that would be useful for you, if you encounter any technical issues,
file a bug in the phabricator.
[1] https://meta.wikimedia.org/wiki/Wikimedia_Social_Suite
[2] https://meta.wikimedia.org/wiki/Wikimedia_Meet
Best
--
Amir (he/him)
I'm pleased to announce the immediate availability of MediaWiki
1.35.0-rc.3, the fourth (and hopefully final; only minor documentation and
packaging changes are expected) release candidate for 1.35.x, the next LTS
version to replace 1.31 which is due to go end of life in June 2021.
Download links at the end of the e-mail. The tag has been signed and pushed
to Git.
Please note that the PHP version requirement has been raised from 7.2.9 in
MediaWiki 1.34 (and 7.0 in MediaWiki 1.31), to 7.3.19.
This is not a final release and should not be used for production websites.
Known issues are tracked in Phabricator on the release workboard [1]. As
always please do try out the release candidate in a test environment and
report any issues that you discover. Please use the #MW-1.35-Release [2]
tag in Phabricator when reporting issues specific to this release.
It is expected that MediaWiki 1.35 will become final in mid September 2020
(apologies for the delay), and will be supported for 3 years after that.
Known/outstanding issues/things to test:
* The PHP requirement for MediaWiki 1.35 has been raised to 7.3.19.
* Both the Vector skin and the underlying skin infrastructure are
undergoing numerous changes, so there might be things broken that are
already fixed in master and as such need backporting.
* VisualEditor and Parsoid are now bundled in the tarball and no longer
need a separate nodejs service. The documentation for this still may still
require some updates.
* Watchlist expiry (behind the $wgWatchlistExpiry flag) is currently
experimental. It should be finished for the 1.35.0 final release.
* If you're on Windows and use 7zip and had issues in the previous release
candidates (and the last round of security releases) extracting the
tarball, this should be fixed for this release.
Changes since 1.35.0-rc.2:
* (T258662) mediawiki.visibleTimeout: Update the nextVisibleTimeoutId value.
* Ensure Parsoid doesn't throw when <ref> is used w/o Cite installed.
* Remove maintenance/createCommonPasswordCdb.php.
* (T260468) Increase "sites.site_global_key" to varbinary(64).
* (T183759) Fix shell edge-cases in Windows.
* (T257879) Drop PHP 7.2 support; require 7.3.19.
* (T251661) User::pingLimiter: add user-global rate limit type.
* (T246991) User: enforce pingLimiter() expiry time.
* (T256831) Rest: Handle Uri constructor exception.
* (T259094) Fix RequestFromGlobalsTest failing in Travis CI.
* (T256831, T261344) Rest: Use try/catch to handle URIs with embedded colon.
Preliminary release notes:
https://phabricator.wikimedia.org/source/mediawiki/browse/REL1_35/RELEASE-N…https://www.mediawiki.org/wiki/Release_notes/1.35
Open Bugs:
[1] https://phabricator.wikimedia.org/project/board/4035/
Bug report form:
[2]
https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?tags=MW-1.35-…
**********************************************************************
Download:
https://releases.wikimedia.org/mediawiki/1.35/mediawiki-1.35.0-rc.3.tar.gz
Download without bundled extensions:
https://releases.wikimedia.org/mediawiki/1.35/mediawiki-core-1.35.0-rc.3.ta…
Patch to previous version (1.35.0-rc.2):
https://releases.wikimedia.org/mediawiki/1.35/mediawiki-1.35.0-rc.3.patch.gz
GPG signatures:
https://releases.wikimedia.org/mediawiki/1.35/mediawiki-core-1.35.0-rc.3.ta…https://releases.wikimedia.org/mediawiki/1.35/mediawiki-1.35.0-rc.3.tar.gz.…
Public keys:
https://www.mediawiki.org/keys/keys.html
Hi all,
Here are the minutes from this week's TechCom meeting:
=== New RFC: Challenges of developing with npm dependencies ===
* The “frontend build step” RFC is overly broad, and has drifted over time, see
https://phabricator.wikimedia.org/T199004
* Dan will draft a new RFC focused on some of the issues we encounter in the
Analytics team when developing Node.js services. Specifically around code
review, CI/deploy, and dependency auditing.
=== Parsoid extension API ===
* https://phabricator.wikimedia.org/T260714
* TT: this is a major milestone RFC, the new parser will replace the old one.
Hooks and methods not mentioned here will likely be deprecated/removed. I
believe that’s well-understood and the
* Parsoid team did great outreach over the past year. This should be detailed
and summarised on the RFC, or linked to.
=== Session expiry ===
* Pywikibot users have been experiencing CSRF tokens, see
https://phabricator.wikimedia.org/T261050
* This may be due to the fact that we have become more strict about expiring web
sessions after a given time since we moved session storage to the Kask
service.
* It is currently unclear from the documentation for how long a CSRF token is
valid for. This should be made more clear.
=== Removal of unused code without deprecation ===
* Daniel proposed a change to the stable interface policy on wikitech-l, in a
thread titled “Making breaking changes without deprecation?”
* Reactions are mixed, more feedback welcome.
* The input from the mailing list will be used to update the current policy
You can also find our meeting minutes at
<https://www.mediawiki.org/wiki/Wikimedia_Technical_Committee/Minutes>
If you prefer you can subscribe to our newsletter here
<https://www.mediawiki.org/wiki/Newsletter:TechCom_Radar>
--
Daniel Kinzler
Principal Software Engineer, Core Platform
Wikimedia Foundation
I 've already sent the email below to otrs related mailing lists, but
I think wikitech-l can also benefit from this, so here it is.
--
Hello everyone,
This is to let you know that per
https://phabricator.wikimedia.org/T187984#6433997 on September 14th
2020 a 48 hour maintenance window for OTRS from 5.0 to 6.0 will begin.
While this is an unusually large time window, the migration process
from 5.0 to 6.0 is rather slow. We have looked into optimizing it, but
at the end preferred to stick with the software developers
recommendations.
During the maintenance window the system will be completely offline. That means:
* No access over the web to the interface
* No scheduled jobs of any kind will be run
* Email will not be delivered but rather backlogged. It will not be
lost as our MX systems will accept them and put them in the queue.
Once the system is back to being fully functional, the emails will
flow into the system.
We will have a rollback plan ready of course, just in case the
migration goes awry. We already have tested it but something might
arise anyway.
I am sorry for any inconvenience this might cause.
--
Alexandros Kosiaris
Principal Site Reliability Engineer
Wikimedia Foundation
Hello,
The current logo of MediaWiki was adapted slightly more than fifteen years
ago and hasn’t changed since. This logo despite having the nice concept of
sunflower, is old. The sunflower represents the diversity, the constant
growth and also the wildness.
Among its biggest issues I can point out that it’s a bitmap picture so it’s
unusable in large sizes (like large posters) and it’s too realistic making
it unusable in small sizes.
Most, virtually all, software products use a simpler and more abstract
form. For example, docker, kubernetes, Ubuntu, VueJs, React, Apache Kafka,
and many more. It’s a good time for MediaWiki to follow suit.
My request is for changing the logo of MediaWiki and I have no plans or
interest in changing logo of any other project.
Please show your support, oppose or your comments in the discussion page.
You can also add more suggestions.
The discussion page:
https://www.mediawiki.org/wiki/Project:Proposal_for_changing_logo_of_mediaw…
Best
--
Amir (he/him)