Hi Everyone,
We’re happy to announce the July 2020 edition of the Technical Community
Newsletter
<https://www.mediawiki.org/wiki/Technical_Community_Newsletter/2020/July>
is now available. The newsletter is compiled by the Wikimedia Developer
Advocacy Team. It aims to share highlights, news, and information of
interest from and about the Wikimedia technical community.
Check it out, and learn about what technical contributors have been up to
this past quarter, upcoming conferences & calls for papers, and how to get
involved.
The Wikimedia Technical Community is large and diverse, and we know we
can't capture everything perfectly. We welcome your ideas for future
newsletters. Let us know what you would like to see or highlights you would
like us to include.
Subscribe to the Technical Community Newsletter
<https://www.mediawiki.org/wiki/Newsletter:Technical_Community_Newsletter>,
if you'd like to keep up with essential updates and information.
Kindly,
Sarah R. Rodlund
Technical Writer, Developer Advocacy
<https://meta.wikimedia.org/wiki/Developer_Advocacy>
srodlund(a)wikimedia.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi,
I'm proposing a breaking change to
MediaWiki\Shell\Command::restrict(). I made a mistake in my original
implementation of this function that I believe we're better off
fixing. For background on what shell restrictions are, see
<https://www.mediawiki.org/wiki/Manual:Shell_framework#Restrictions>.
To summarize the ticket I filed
<https://phabricator.wikimedia.org/T257278>:
Command manages $restrictions as bitfields and by default sets it to
Shell::RESTRICT_DEFAULT (39). To disable restrictions, the idea was to
call ->restrict( Shell::RESTRICT_NONE );. However, ->restrict() adds
to $restrictions (using |=) instead of overwriting...so it's
impossible to disable a default restriction.
My proposal is to have ->restrict() overwrite the current
$restrictions instead of adding to it. Based on codesearch, every
non-test caller is already set up to work this way, so in practice, it
shouldn't be a breaking change.
The Gerrit patch for this is
<https://gerrit.wikimedia.org/r/c/mediawiki/core/+/609870/> and
contains multiple examples of the correct way to call the fixed function
.
Comments, alternative suggestions welcome. I would like to get this in
for 1.35 if possible.
Thanks,
- -- Legoktm
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEE2MtZ8F27ngU4xIGd8QX4EBsFJpsFAl8Fs30ACgkQ8QX4EBsF
JptHyA//Uo5h3l4EUTJlBNIoOR1jKlN7onKfzHZrxDPKvLDlBCrAYB9YLkxZ6Pfb
/SP8c0mUH5UvQBH+SL/qZPmHTfwbnB1auOuyzu+XedFZxET26kh29glWSwbxf9KL
i+7dAuO8gFM/q7gIuYMCc+TmZu+SQEOgr4Ek+iD/fIcQondpxmzaAdTUJ8UPn9a0
OLONdqo7elFM8VRID0YlIzO4DCKymmpW/aEiJChOTxy11IUr4ZQ8n1r8aY66LZ2y
qlsm00hofPkVH19Pjqj5T1E80etUcMwh6uVdpctgJBNFXNYIuaAG6sHatbZXH3WJ
/zIfzhNBXB19233fQ3Cn/f+fLYXQPGxw5Z/ATEtlHSAFAeWwXtkpvOED0fAO0X8r
0BbAdHkWYPkbGTPimrf5R1dwvmnw09p4qGUMGGb9Nw6KwsJpOMoZL8oBMa120ktI
FzJ6EPB3iv1XbsY1IOaekmdThISV/V1pB4PpteqpK44li+1kPCg4sJIqyaFMG86p
ejgzlXMiLw8g9skezFGsZJeaUbGwu+Fu0GuAQ/4+py50jsmAEsO49u6md7TtzhUu
Loa39JpisHk6Kk5otfL+f1b8MWNBBVuqixQTCL/T78G3jfotG9swjuqqKq8MNY6U
qgx2lL8LEEaUik7MwhvxJ00A6p89HV9KTezTdwmlwWwmKA83ec0=
=HouQ
-----END PGP SIGNATURE-----
Hey,
Has anyone created a GitHub action to run tests for a MediaWiki extension
yet?
I'd like to run the PHPUnit tests for some of my extensions via GitHub
actions. Unfortunately this is not as simple as in the typical PHP project,
since doing composer install + vendor/bin/phpunit does not cut it. It'd be
fantastic if someone already created a clean action to do this that I can
copy.
Best
--
Jeroen De Dauw | www.EntropyWins.wtf <https://EntropyWins.wtf>
Professional wiki hosting and services: www.Professional.Wiki
<https://Professional.Wiki>
Entrepreneur | Software Architect | Open Source | Longtermism
Hi all,
This week, we're sending out a more detailed version of the TechCom
meeting minutes. Let us know if you find this helpful.
Present: Dan Andreescu, Daniel Kinzler, Timo Tijhof, Alex Paskulin,
Niklas Laxstrom
== RFC Frontend build step ==
<https://phabricator.wikimedia.org/T199004> ==
* Recently moved from open to stalled
* Discussion of the issues presented in the RFC from a process perspective:
* DA: The question on the RFC was originally: How can we implement a build
step? The discussion on the RFC has been centered around whether we should
implement a build step. The authors are trying to address concerns to enable
them to implement it since it’s an industry-wide practice.
* TT: We should focus on the underlying problems this is trying to solve.
A build step is inevitable. Many problems discussed so far on the RFC don’t
call for a build step. There are some architecture issues in the things
proposed that can’t be reconciled. We can build towards a deliverable of
compiling a Vue component.
* DK: Process-wise, what is the problem with a team deciding that they want
a server side build step? What’s the impact? In theory, we want to maximize
coherence and autonomy; there’s a polarity between the two.
* DA: If they find a mainstream way, they’ll migrate to it. I don’t think
it’s problematic. They’re saying that they’ll address all the concerns if
they can.
* TT: This impacts security for the developers running insecure code on
developer host machines, security for production (can be contained/network
isolated), and security for the end-user (this isn’t just helping create
commits or run tests, it modifies and adds code we sent to a billion
people’s
devices). Reproducing the same locally, in CI and prod. Workflow problems
like cherry-pick and revert in production branches.
* DK: To what extent are we willing to run arbitrary code on our systems?
Which communities do we trust? (Example: Debian maintainers are vetted, NPM
packages are not)
* TT: NPM packages are known for depending on a lot of unreviewed/unknown
code. See <https://phabricator.wikimedia.org/T199004#6045136>. But, there
are communities within the NPM ecosystem that follow different principles,
and use fewer dependencies.
* DA: We could set a policy about reviewing and vendoring such service,
run in a sandbox, pinned to specific versions. We could set a requirement
that packages need to be vetted.
== Send regular overview about Wikimedia development policies ==
<https://phabricator.wikimedia.org/T164538>
* Moved from Inbox to In progress on TechCom board
== RFC: Amendment to the Stability interface policy ==
<https://phabricator.wikimedia.org/T255803>
* On last call ending July 8
* Discussion ongoing
== RFC: Hybrid extension management ==
<https://phabricator.wikimedia.org/T250406>
* In Phase 3: Explore
* Discussion ongoing
== Next week public IRC discussion ==
No discussion scheduled for next week
See also the TechCom RFC board
<https://phabricator.wikimedia.org/tag/mediawiki-rfcs/>.
--
Alex Paskulin
Technical Writer
Wikimedia Foundation
The Wikimedia Engineering Productivity team has decided that Wikimedia
projects will move from Gerrit to GitLab for code review and
continuous integration.
They have decided that this decision is not subject to any formal RFC.
Previous attempts to change the code review system went through an
RfC. They are, however, looking for feedback.
More information is at
<https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/GitLab>
and the associated talk page.
Regards,
AntICompositeNumber
As of 950cf6016c, the mediawiki/core repo was updated to use DB_REPLICA
instead of DB_SLAVE, with the old constant left as an alias. This is part
of a string of commits that cleaned up the mixed use of "replica" and
"slave" by sticking to the former. Extensions have not been mass
converted. Please use the new constant in any new code.
The word "replica" is a bit more indicative of a broader range of DB
setups*, is used by a range of large companies**, and is more neutral in
connotations.
Drupal and Django made similar updates (even replacing the word "master"):
* https://www.drupal.org/node/2275877
* https://github.com/django/django/pull/2692/files &
https://github.com/django/django/commit/beec05686ccc3bee8461f9a5a02c607a023…
I don't plan on doing anything to DB_MASTER, since it seems fine by itself,
like "master copy", "master tape" or "master key". This is analogous to a
master RDBMs database. Even multi-master RDBMs systems tend to have a
stronger consistency than classic RDBMs slave servers, and present
themselves as one logical "master" or "authoritative" copy. Even in it's
personified form, a "master" database can readily be thought of as
analogous to "controller", "governer", "ruler", lead "officer", or such.**
* clusters using two-phase commit, galera using certification-based
replication, multi-master circular replication, ect...
**
https://en.wikipedia.org/wiki/Master/slave_(technology)#Appropriateness_of_…
***
http://www.merriam-webster.com/dictionary/master?utm_campaign=sd&utm_medium…
--
-Aaron
Hello.
(Apologies for cross-posting, and that you are likely not reading this
message in your native language: translations of the full announcement may
be available on Meta [1], and will be posted to all the wikis in the next
few days. Please consider helping with translations in the meantime.
Thanks!)
The Wikimedia Foundation Board of Trustees has approved a new sister
project, temporarily titled "Abstract Wikipedia" [2].
Its goal is to generate baseline encyclopedic content in a multilingual
fashion, allowing more contributors and more readers to share more
knowledge in more languages. You can learn more on Meta [1] and can also
join the new dedicated mailing list [3].
Talk to you soon!
[1]
https://meta.wikimedia.org/wiki/Special:MyLanguage/Abstract_Wikipedia/June_…
[2] https://meta.wikimedia.org/wiki/Special:MyLanguage/Abstract_Wikipedia
[3] https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
--
Erica Litrenta
Manager, Community Relations Specialists
https://meta.wikimedia.org/wiki/User:Elitre_(WMF)
Hi,
I'm excited to share the release of the Vue.js Migration Project
Charter[0] today.
This is an update on the Foundation's evaluation and adoption of
Vue.js framework for building user-interfaces in a modern,
developer-friendly, inclusive, and internationalization-ready way. It
is a result of the platform evolution program[1] recommendations.
We aim to achieve this with help of the shared components and patterns
library Wikimedia Vue UI (WVUI). We project to implement first,
slimmed-down components for it as part of the Vue.js Search Case
Study[2].
Please find further details on the article. Also keep in mind, that
the shared charter reflects current planning and is subject to
repeated evaluation and possible change. Provide any feedback or
questions, on the talk page[3], technical issues and ideas on
Phabricator tagged with 'Vue.js'[4] or directly to me.
Thanks specifically to Jazmin Tanner, who has played an essential part
in gathering inputs from all stakeholders and interested groups in
synthesizing the charter.
Also to Stephen Niedzielski as a thoughtful driver of the Vue.js
Search Case Study – one of the first major milestones. And generally,
thanks to all members of FAWG, WMDE, Product and Technology department
teams (Reading Web, Editing, Growth, Language, Multimedia, Design,
Core Platform, Performance) involved and leadership for continuous
strong support of this wide-reaching project.
Best,
Volker
[0] - https://www.mediawiki.org/wiki/Vue.js/Migration_Project_Charter
[1] - https://www.mediawiki.org/wiki/Platform_Evolution
[2] - https://phabricator.wikimedia.org/project/view/4767/
[3] - https://www.mediawiki.org/wiki/Talk:Vue.js/Migration_Project_Charter
[4] - https://phabricator.wikimedia.org/tag/vue.js/
Hi,
for HTML version see https://www.mediawiki.org/wiki/Scrum_of_scrums/2020-07-01
Željko
--
= 2020-07-01 =
== Callouts ==
* Release Engineering
** [All] Review guidance at [[wikitech:Deployments/Covid-19]] and Code
Deployment Office Hour at 17:00UTC in #wikimedia-office
** "scap sync" will be renamed to "scap sync-world" in the next
release. If you use "scap sync" non-interactively, please add a note
to: [[phab:T250302]] (and also, explain why you're using it)
** scap sync now has option --canary-wait-time; [[phab:T217924]]
** Gerrit was updated over the weekend to version 3
== Product ==
=== iOS native app ===
* Updates:
** Early development and research on new experiments for 6.7 -
[[phab:project/view/4661]]
** WWDC research
=== Android native app ===
* Updates:
** User contribution history screen now in production.
** Starting next development phase: [[phab:project/view/4819/]]
=== Web ===
* Updates:
** '''Summary''': sidebar instrumentation and content max-width for
Desktop Improvements Project (DIP), building initial component
primitives for Vue.js search.
** [[Reading/Web/Desktop_Improvements|Desktop Improvements Project
(Vector / DIP)]]:
*** [[phab:T254195|<nowiki>Implement a core 'clearfix' mixin in
mediawiki.mixin and evaluate deprecation/removal of 'visualClear'
class</nowiki>]]
*** [[phab:T254851|<nowiki>Current checkbox hack doesn't provide
<Enter> or <Space> as toggle action</nowiki>]]
*** [[phab:T253178|<nowiki>UniversalLanguageSelector should stop using
the SkinTemplateOutputPageBeforeExec hook</nowiki>]]
*** [[phab:T250282|<nowiki>Build sidebar instrumentation</nowiki>]]
*** [[phab:T246420|<nowiki>Limit content width, and refine alignment &
styling of relevant elements</nowiki>]]
*** [[phab:T246419|<nowiki>Build collapsible sidebar and sidebar
button </nowiki>]]
*** [[phab:T60137|<nowiki>Deprecate the
SkinTemplateOutputPageBeforeExec hook</nowiki>]]
*** [[phab:T256092|<nowiki>[Modern Vector] Fix broken rendering of
`main` and `dialog` elements in IE9-11</nowiki>]]
*** [[phab:T251212|<nowiki>[Dev] Drop VectorTemplate usage in Vector</nowiki>]]
*** [[phab:T255319|<nowiki>Eventually deprecate
SkinTemplateNavigation::SpecialPage and SkinTemplateNavigation hooks
in favor of SkinTemplateNavigation::Universal </nowiki>]]
*** [[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:T255230|<nowiki>Align MinervaNeue's/MobileFrontend
variables to CSS variable naming scheme</nowiki>]]
*** [[phab:T251475|<nowiki>History page insert `ins`/ delete `del`
elements have accessibility issues </nowiki>]]
*** [[phab:T237036|<nowiki>ext.uls.interface should set targets and
explicitly not target the Minerva skin</nowiki>]]
*** [[phab:T235712|<nowiki>Fix the most common "Module not loadable on
target mobile" warnings (Oct 2019)</nowiki>]]
*** [[phab:T234550|<nowiki>Mobile version Star for Watchlist not
consistent</nowiki>]]
*** [[phab:T240622|<nowiki>[Technical debt payoff] Remove
InlineDiffFormatter and InlineDifferenceEngine from
MobileFrontend</nowiki>]]
*** [[phab:T219793|<nowiki>Mobile web donate link</nowiki>]]
*** [[phab:T212465|<nowiki>[EPIC] None of our View's should exhibit 2
levels of inheritance</nowiki>]]
** Standardization
*** [[phab:T256520|<nowiki>Consider 'normalize' stylesheet RL module</nowiki>]]
*** [[phab:T214477|<nowiki>Re-design progress bar for OOUI</nowiki>]]
*** [[phab:T112747|<nowiki>Devise a generic way for theme-agnostic
stylesheets to adapt to the current theme</nowiki>]]
*** [[phab:T253598|<nowiki>Focus not visible on checkbox in high
contrast dark mode</nowiki>]]
** Portals
*** [[phab:T128546|<nowiki>[Recurring Task] Update Wikipedia and
sister projects portals statistics</nowiki>]]
** Miscellaneous
*** [[phab:T255814|<nowiki>Latest version of SkinBlueSpiceCalumma is
not compatible with current version of Chameleon</nowiki>]]
*** [[phab:T255717|<nowiki>Scope and use of mediawiki.skinning's
'elements.less' file</nowiki>]]
*** [[phab:T248751|<nowiki>Adopt mustache templates in Modern and
Monobook</nowiki>]]
*** [[phab:T231615|<nowiki>Use project logo wordmarks on Wikimedia
projects in Timeless</nowiki>]]
*** [[phab:T212521|<nowiki>RFC: Reconsider how we run QUnit unit
tests</nowiki>]]
*** [[phab:T255299|<nowiki>Some images appear when Show Images is
disabled</nowiki>]]
*** [[phab:T247033|<nowiki>Add 'i18n-directionality.less' file to core
and extract overarching theme styles from legacy.less</nowiki>]]
=== Product Infrastructure ===
* Blocked by:
** RelEng: to review codehealth pipeline for push notifications
[[gerrit:604830]]
=== UI Standardization ===
* Updates:
* Design Style Guide
** Prep work for WVUI – technically and planning, including
WikimediaUI Base variables amendment and extension.
** Improved long-standing consistency imagery representation, both
desktop and mobile [[phab:T251347]]
** Icon additions: 'doubleChevronStart', 'doubleChevronEnd', 'userAdd'
** “Link” component got updated to reflect “new” treatment
https://design.wikimedia.org/style-guide/components/links.html
== Technology ==
=== Fundraising Tech ===
* Updates:
** Finishing up matching gifts data sync and form autocomplete
** Overhauling data export to bulk mailer house
** Implementing workaround for browsers blocking pixels from setting
cookies for hiding banners
=== Engineering Productivity ===
==== Release Engineering ====
* Blocking:
** Product Infrastructure - to review codehealth pipeline for push
notifications [[gerrit:604830]]
* Updates:
** [All] Deployments/Covid-19 [[wikitech:Deployments/Covid-19]]
** Train Health
*** Last week: 1.35.0-wmf.38 - [[phab:T254175]]
*** This week: 1.35.0-wmf.39 - [[phab:T254176]]
*** Next week: 1.35.0-wmf.40 - [[phab:T256668]]
=== Site Reliability Engineering ===
* Updates:
** Proton to be switched over to the k8s TLS enabled version.
** Work on mobileapps traffic being routed to k8s will start soon.
Hello,
TLDR: The following hooks are deprecated in 1.35:
SkinTemplateBuildNavUrlsNav_urlsAfterPermalink,
SkinTemplatePreventOtherActiveTabs, SkinTemplateTabAction,
BaseTemplateAfterPortlet, SkinTemplateToolboxEnd, BaseTemplateToolbox,
SkinTemplateOutputPageBeforeExe.
The longer version:
As part of the desktop improvements project
<http://mediawiki.org/wiki/Desktop%20improvements> we've been making some
exciting changes in MediaWiki's skin architecture. This has involved
migrating away from the BaseTemplate PHP class to Mustache as the render
engine for Vector. In 1.36, the Vector skin plans to use the new SkinMustache
class
<https://github.com/wikimedia/mediawiki/blob/master/includes/skins/SkinMusta…>
and do away with the BaseTemplate class. This meant that we had to
deprecate various BaseTemplate hooks, providing more suitable generic
alternatives in the shared Skin.php layer. We also took the opportunity to
reduce the number of active hooks that operate in the skin layer for
developer sanity.
>From now on it is intended that any skin modifications are done *prior *to
rendering. The renderer whether it is BaseTemplate or SkinMustache will
simply render the data that's been provided.
As a result of this I have various changes to report!
The *SidebarBeforeOutput
<https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Hooks/SidebarBefor…>
*hook now can be used to modify the toolbox and languages portals.
Previously these sidebar menus had their own bespoke hooks.
The SkinTemplateBuildNavUrlsNav_urlsAfterPermalink hook
<https://www.mediawiki.org/wiki/Manual:Hooks/SkinTemplateBuildNavUrlsNav_url…>
is deprecated and can be replaced with the new and improved
SidebarBeforeOutput hook.
The SkinTemplatePreventOtherActiveTabs and SkinTemplateTabAction hooks
<https://phabricator.wikimedia.org/T253814>were seldom used and replaced
with SkinTemplateNavigation::Universal .
All BaseTemplate hooks should now be considered deprecated per T253809
<https://phabricator.wikimedia.org/T253809>.
- BaseTemplateAfterPortlet
<https://www.mediawiki.org/wiki/Manual:Hooks/BaseTemplateAfterPortlet>
is replaced with the template-rendering agnostic SkinAfterPortlet
<https://www.mediawiki.org/wiki/Manual:Hooks/SkinAfterPortlet>
- SkinTemplateToolboxEnd
<https://www.mediawiki.org/wiki/Manual:Hooks/SkinTemplateToolboxEnd>is
replaced with the new and improved version of SidebarBeforeOutput
- BaseTemplateToolbox
<https://www.mediawiki.org/wiki/Manual:Hooks/BaseTemplateToolbox> is
replaced with the new and improved version of SidebarBeforeOutput
Finally a big one:
The SkinTemplateOutputPageBeforeExec hook is now deprecated
<https://phabricator.wikimedia.org/T60137>. Previously this hook could do a
lot of things and often in ways that were hard to reason with. For example,
previously this hook was used alongside other hooks to add items to the
footer and to override skin internals to display portals that were normally
hidden. We looked through all the use cases for this hook and are confident
we've caught the most confident use cases. Migration depends on what it was
previously used for but are documented on mediawiki.org
<https://www.mediawiki.org/wiki/Manual:Hooks/SkinTemplateOutputPageBeforeExe…>.
It's possible there are other use cases, we missed and if so we plan to
cover those during the 1.36 release.
If you are an extension developer and have any questions about migration
please feel free to ping me on the associated Phabricator ticket or hook
talk page, we will be happy to improve the documentation and help you find
the right way to upgrade your code.
As we go into 1.36 we plan to make changes that simplify MediaWiki skin
development and make the ecosystem friendlier to frontend developers and
make skins easier to maintain. In fact, in future, it will be possible to
write skins without a single line of PHP. If you are excited or intrigued
by these changes and want to get involved in the conversations I urge you
to subscribe to our board.
<https://phabricator.wikimedia.org/project/board/4795/>
I'm particularly interested in hearing from developers who are keen to make
skins in the new ecosystem. Your input and creativity would be much
appreciated. Feel free to drop me a private mail or engage in open
conversations.
In addition to all the extension developers who helped review changes to
their hook contracts, I would like to especially thank the following people
for getting us to this landmark: Ammarpad, Timo, Volker and Mainframe98.
I'd like to give a specific shout out for Ammarpad who has been a huge
driving force here, preventing various bugs from occurring and swiftly
responding to many of the unexpected regressions that we encountered during
this work. We couldn't have done this without you!
Thanks for reading!
Jon