We are pleased to announce the first MediaWiki Users and Developers Conference [0], the successor to EMWCon.
The conference will be held in Portland, Oregon, from April 17–19 at the Jupiter NEXT Hotel [1].
The MediaWiki Users and Developers Conference brings together the community that makes up MediaWiki – those who develop for MediaWiki, those who deploy MediaWiki, and those who use MediaWiki and are enthusiastic about the software. MediaWiki is used every day in a variety of contexts – educational projects, corporate knowledge bases, even online hobbyist communities – all valuing MediaWiki for its flexibility and its openness. By meeting together we can learn from our experiences and continue to build a true community of support for MediaWiki.
Registration is open now. [2] Register soon to take advantage of the early bird discount!
See the conference page for local accommodations. [3] Everyone who is attending is encouraged to stay at either of these hotels, where we have negotiated group rates.
If you have ideas for the program, add them to the wiki page. [4] While this will primarily be an in-person conference, we will consider remote presentations on a case-by-case basis.
Looking forward to seeing you in Portland!
Best regards,
the MediaWiki Users and Developers Conference Organizing Team
[0] https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_20…
[1] https://www.jupiterhotel.com/the-next
[2] https://www.eventbrite.com/e/mediawiki-users-and-developers-conference-spri…
[3] https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_20…
[4] https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_20…
Hi All,
Happy 2024 and welcome to the monthly MediaWiki Insights email!
We’re starting this year with celebrating contributors who got their first
patch merged in MW core, WMF deployed extensions or services in the months
of December and January:
A big thanks to Doğu Abaris, apasternak, Abador, Mehdi Zidani,
Oudedutchman, Cyn, Dominic mayers, and Houseblaster for their
contributions! Welcome :-)
Enable more people to know MediaWiki and contribute effectively
As shared in the previous MW insights email
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Reports/November_…>,
we have been thinking about ways to improve first time MediaWiki (core)
contributors’ experience. One key part of that is knowing who is new to be
able to say hi (and thank you). Bartosz created a script
<https://gitlab.wikimedia.org/matmarex/gerrit-new-contributors/-/blob/master…>
to find new MediaWiki contributors for a given month that got their first
patch merged (see above!). Another key part is code review for patches
submitted by (new) volunteer contributors. We’re currently thinking about
how we could organize code review for volunteer-submitted patches better
across MediaWiki Engineering and want to give a shared MW-Engineering
Gerrit dashboard a try, with primary focus on the components the group is
responsible for.
We ran a WMF-internal MediaWiki CodeJam event
<https://www.mediawiki.org/wiki/MediaWiki_Code_Jam#Results> in December,
with 54 participants (16 from the MW team) and 21 Phabricator tickets
completed. Areas of improvement included MediaWiki itself and multiple
essential extensions. See the project page for details!
Two notable “side projects” of the CodeJam: To support new contributors,
Timo has created a series of tutorials
<https://www.mediawiki.org/wiki/User:Krinkle/MediaWiki_Introduction_2023>
going over core MediaWiki concepts. The videos are also available on
youtube (part I: MediaWiki core concepts
<https://www.youtube.com/watch?v=-JnIjpRvgNY>, part II: Wikipedia’s
extensions <https://www.youtube.com/watch?v=4xYbqbabTwI>).
A "Quick" MW install
<https://www.mediawiki.org/wiki/Local_development_quickstart> was created
to make it possible to install MediaWiki in 3 steps and under 5 minutes.
See this ticket for the evaluation
<https://phabricator.wikimedia.org/T348899> on how this worked out for
testers during code jam. Thanks to Alex Paskulin, Timo Tijhof and Kosta
Harlan for their work <3
The materials as well as lessons learned from this first MW code jam will
help us run a second edition for everyone who’s interested, possibly ahead
of, and at the Wikimedia Hackathon
<https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2024>.
Project snapshot: Virtual domains, great namespaceisation, and first MW
Engineering cross-sub-team quarterly planning
We finalized the Q3 plan (= Jan-March) for MediaWiki Engineering in early
January. This is the first time where we applied a “cross-sub-team”
planning approach across MediaWiki Engineering & engaged as a group on
gathering proposals and then prioritized these. A few examples for high
priority work:
- Evolve central login to meet requirements of a changing environment
(“SUL3”): T348388 <https://phabricator.wikimedia.org/T348388>
- Support upgrade of WMF production from PHP 7.4 to 8.1: T319432
<https://phabricator.wikimedia.org/T319432>
- Continue work to move off RESTBase
<https://phabricator.wikimedia.org/project/profile/6289/>
- Continue work on exploring how essential workflows on the Wikimedia
projects are currently supported through the MediaWiki software ecosystem
(see below)
- Prepare MW-platform team owned components
<https://phabricator.wikimedia.org/T355377> for compatibility with the
upcoming Temporary Accounts for Unregistered Editors
<https://www.mediawiki.org/wiki/Help:Temporary_accounts> project.
We’ve already checked the box on preparing auth components
<https://phabricator.wikimedia.org/T326925> (OATHAuth and WebAuthn) for
compatibility - many thanks to Piotr and Gergö for their work on this!
Other highlights:
- We’ve made progress towards supporting Less 3.13
<https://phabricator.wikimedia.org/T288498> behavior: A series of bugs
were fixed in Less v2.5.3 to pave the way to enable new Less.js
capabilities to be used in the frontend.
- The Content Transform team has moved functionality out of Parsoid and
into Cite extension <https://phabricator.wikimedia.org/T354215>, which
allows both Parsoid and the default parser to use the same underlying
functionality and reduce maintenance burdens.
- To support SRE’s work, MediaWiki metrics were migrated from Graphite
to Prometheus. This is an ongoing effort with more upcoming work.
- Cleanup continued in dropping deprecated unused config variables
<https://phabricator.wikimedia.org/T166010> (also known as the great
namespaceisation effort).
- Virtual domains are now working well in MediaWiki core
<https://phabricator.wikimedia.org/T353948> and are supported in the
updater and installer.
- A minor task was to update the JavaScript syntax checker for gadgets
and user scripts for ES6 and ES7
<https://phabricator.wikimedia.org/T75714>.
- Database: Amir Sarabadani presented
<https://commons.wikimedia.org/wiki/File:Major_changes_to_MediaWiki%27s_rdbm…>
about changes done to the RDBMS library at SMW Con (video available
<https://www.youtube.com/watch?v=q0mjNEJP5Fo>). DBAccessObjectUtils is being
redesigned <https://phabricator.wikimedia.org/T354194>, including major
deprecation of indirect calls to IDBAccessObject constants.
How essential workflows are served through the MediaWiki software ecosystem
As part of developing a product strategy for MediaWiki, one research
question is how the MediaWiki software ecosystem currently supports
essential workflows on the Wikimedia projects. We also wanted to understand
commonalities and differences in how these workflows and use cases are
supported on different wikis - for example, Wikipedia A vs Wikipedia B,
Wikipedia A vs Wikidata, or Wikipedia A vs translatewiki.net - etc.
Moriel has been leading this work, in collaboration with many engineers
across different areas of expertise. A first outcome has now been
published: Unraveling Complexity: Mapping MediaWiki Software Components
into User-Driven Workflows
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Artifacts/Unravel…>
The next outcome is already in the making, with focus on exploring how
specific use cases are supported (differently) on 3 different Wikimedia
projects. The goal is to identify where conceptual behaviors diverge and
converge between the wikis, pinpointing base and common behaviors versus
those unique to specific cases. This brings us in the interesting fields of
software behavior on use cases such as: “An unregistered (not yet
temporary) user edits existing wikitext content (fixing typo) on desktop.”
Read the write-up above to learn more about why, and stay tuned for the
next outcome of this exploration, which will talk through some of the
findings in this multi-wiki modeling approach.
Thanks all for reading!
Birgit
--
Birgit Müller (she/her)
Director of Product, MediaWiki and Developer Experiences
Wikimedia Foundation <https://wikimediafoundation.org/>
Hi.
I am an operator of a small wiki. The log of the wiki is not preserved currently.
The wiki is running on a container which is on a Hashicorp Nomad node. You can assume it as just a docker container.
For a monetary reason, I want to use a free plan of a logging stack cloud service, for example Grafana Loki or OpenObserve.
I set up the mediawiki used monolog so that logs flowed to stdout, and let Vector[1] agent on a machine collected it and sent to the OpenObserve cloud. I wanted logs are not stored in the storage, because I did not want logrotate.d.
But for some reason, storage became closely full, I've disabled the whole logging system. I've not inspected it.
Before re-enable the logging system or inspect it, I hope to know how people deploy the log system. If you have some experience, please reply to this or review my approach.
Regards.
1: https://vector.dev/
Hello,
For many years, some classes in MediaWiki implemented the IDBAccessObject
interface (which only provides several public constants) and then would
call them indirectly (e.g. self::READ_NORMAL). Since these constants were
public, other parts of MediaWiki started to call them through the
implementing class as well (e.g. calling User::READ_LATEST).
This is inconsistent with the access pattern of other constants in
MediaWiki. it's also confusing (e.g. it's unclear to a newcomer why
UserFactory is implementing IDBAccessObject) and it's prone to clashes
(e.g. BagOStuff class has a clashing constant).
Since it's not possible to trigger a deprecation warning in such cases, It
can't follow the usual stable interface policy path [1] and here is the
email to wikitech-l as required by the policy.
In three weeks we will remove indirect access to these constants by
removing IDBAccessObject from implementation. This will take effect from
1.42 release.
Classes that won't have those constants anymore are including but not
limited to:
* User
* WikiPage (and its subclasses)
* File (and its subclasses)
* Title
* ActorStore
* RevisionStore
* UserOptionsManager
* And more.
To find such cases in extensions you maintain, you can search for
"(?<!IDBAccessObject)::READ_" (regex) and check if the constant being used
is an indirect call to IDBAccessObject. Be careful that there might be some
false positives such as custom defined constants, constants referring to
BagOStuff ones and similar cases like that.
We have already removed all cases in core and extensions deployed to
Wikimedia production.
You can follow the work and see examples of how the migration is done in
extensions (for example gerrit:993112
<https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Echo/+/993112>) in
T354194 <https://phabricator.wikimedia.org/T354194>.
[1] From the policy
<https://www.mediawiki.org/wiki/Stable_interface_policy#Hard_deprecation>:
"If it is not reasonably possible for the deprecated code to emit
deprecation warnings, hard deprecation can be applied by announcing the
removal on wikitech-l in a timely manner."
Thank you and sorry for the inconvenience,
--
*Amir Sarabadani (he/him)*
Staff Database Architect
Wikimedia Foundation <https://wikimediafoundation.org/>
Hello everyone!
I need some advice... I am currently stuck on MediaWiki 1.39.2 and can't
upgrade to newer versions within this LTS release.
I am using PluggableAuth and SimpleSAMLphp to authenticate users to our
wikis. Starting with MW 1.39.3, these extensions were updated to newer
versions (7.0.0) that don't work any more, at least with PostgreSQL as
database (see https://phabricator.wikimedia.org/T348543). I am still
using MW 1.39.2 with versions 6.2 of PluggableAuth and 5.0.1 of
SimpleSAMLphp.
I would like to combine MW 1.39.6 with the older versions of the
extensions, but here
https://extdist.wmflabs.org/dist/extensions/
only the newer ones are available.
I have tried to use composer (with which I have zero knowledge and IMHO
the documentation is ... challenging), and I was able to install
MediaWiki itself and PluggableAuth via composer, but not SimpleSAMLphp.
This extensions seems to be completely unknown to composer.
Switching from PostgreSQL to MySQL is a last resort. The migration does
not seem to be straight forward at all, and it is even unclear if it
would solve my problem in the first place.
Any ideas how to move forward are welcome!
Maybe what I really would like to ask for is: Don't make major updates
to (essential) extensions within an LTS release of MediaWiki, please
coordinate them with major updates of MediaWiki core.
Cheers,
Joern
--
Jörn Clausen
https://www.uni-bielefeld.de/bits
Lis ton message de Nganguem Victor avant qu'il ne soit effacé!
Pour lire ton message, suis simplement ce lien:
http://eu1.badoo.com/chatnoirxx/in/p4hxwt052ok/?lang_id=6
D'autres personnes sont aussi présentes:
Oded (Tel Aviv, Israël)
Priya (Udaipur, Inde)
RajaYogi BK (Udaipur, Inde)
Karuna (Udaipur, Inde)
Chika Reginald Onyia (Pnompen', Cambodge)
...Qui d'autre?
http://eu1.badoo.com/chatnoirxx/in/p4hxwt052ok/?lang_id=6
Les liens ne fonctionnent pas dans ce message? Copie les dans la barre d'adresse de ton navigateur.
Tu as reçu cet email suite à un message envoyé par Nganguem Victor de notre système. S'il s'agit d'une erreur, ignore simplement cet email. La requête sera alors effacée du système.
Amuse-toi bien !
L'équipe Badoo
Courrier automatique de Badoo suite à l'envoi d'un message à ton attention sur Badoo. Les réponses ne sont ni stockées, ni traitées. Si tu ne veux plus recevoir de message de Badoo, fais-le nous savoir:
http://eu1.badoo.com/impersonation.phtml?lang_id=6&mail_code=65&email=media…
Hi All,
Welcome to the monthly MediaWiki Insights email!
Enable more people to know MediaWiki and contribute effectively
In the last MW insights email
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Reports/October_2…>
we shared more about our approach to helping people contribute effectively
to MediaWiki
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Contributor_reten…>.
A few interesting data points:
The number of contributors to MediaWiki core who have more than > 5 patches
continued to grow: We just hit for the first time the goal of 20% since the
start of the Foundation’s fiscal year in July, compared to the
July-November time period last year. This is exciting to see - now it’s
about keeping the momentum and continuing on that path.
Many thanks to all the people who have contributed to MediaWiki core!
The average and median time to first review for patches in MediaWiki core
decreased significantly in the period July 1st to Nov 30 compared to the
same time period one year earlier.
- Average time to first review dropped from previously 16.5 days to 4.5
days
- Median time to first review dropped from previously 1.2 days to 0.6
days
Many thanks to all the code reviewers of MediaWiki core patches!
Keep in mind that this data is only one data point. There are many factors
that play into the experience of contributors; a helpful comment may be
more relevant than a fast +1/-1, etc.
Over the past weeks, we have been spending some time with planning
initiatives to further support people in onboarding and contributing to
MediaWiki:
- We are preparing for a WMF internal MediaWiki code jam in December to
try out a few things and focus specifically on the needs of teams.
- One thing we wanted to test in practice at the code jam is the “MediaWiki
Quick Install <https://phabricator.wikimedia.org/T347347>” guide. This
has been a collaboration between the Tech Docs team and the MediaWiki
Platform team - you can find the latest version of this experiment here:
https://www.mediawiki.org/wiki/Local_development_quickstart
- We discussed a possible focus project in the next quarter on improving
first time MediaWiki (core) contributors’ experience. We’re exploring a few
simple, small ideas that we could implement/try out in the next quarter
(ticket follows!).
Project snapshot: Analysis of MediaWiki execution timings, fixing issues
with logging in on Mobile, progress on RESTBase deprecation and more!
Performance: Piotr and Timo conducted an analysis of MediaWiki execution
timings <https://phabricator.wikimedia.org/T350593> and identified areas
for improvement. One of the fixes promises a 50ms improvement
<https://phabricator.wikimedia.org/T351807>! Timo and Derick worked on
bagOStuff improvements <https://phabricator.wikimedia.org/T336004> (cache
layer), shipped on MW-1.42. This work aims to lower the barriers for
contributors by making interfaces leaner and more intuitive and is reducing
storage access cost from 10ms to ~1 ms. Thank you for your work!
More highlights:
MediaWikiIntegrationTestCase now automatically tracks what database tables
get touched during the integration test, removing the need for developers
to keep track (T342301 <https://phabricator.wikimedia.org/T342301>). Many
thanks to Daimona and others for their work on this!
Work towards PHP 8.2 support continues, with one helpful outcome being a
new DynamicPropertyTestHelper feature (T326466
<https://phabricator.wikimedia.org/T326466>). Many thanks to TK-999 and all
reviewers!
Gergö worked on solving a variety of problems with logging in on mobile
(see https://phabricator.wikimedia.org/T257852#9347008 and below). Many
thanks to Gergö and everyone who provided support!
RESTBase sunset: Wikifeeds now calls the Parsoid endpoint in MediaWiki core
rather than RESTBase. Many thanks to Yiannis and Daniel for their hard work
on making this happen! Cxserver is preparing a deployment to the same soon
<https://gerrit.wikimedia.org/r/c/operations/deployment-charts/+/977983/>
(thank
you, Language team!).
Upcoming:
There is an OutputTransform
<https://www.mediawiki.org/wiki/Parsoid/OutputTransform> pipeline that is
being introduced to replace ParserOutput::getText(). This pipeline
initially targets content that comes from the ParserCache before it is
rendered (as a 1:1 getText() equivalent ). The team is likely going to
introduce another layer of cacheability of this output so that we can store
richer canonical Parsoid content and use this pipeline to transform it for
final rendering. Many thanks to Isabelle, CScott and Daniel for this work
in progress (Gerrit:967449
<https://gerrit.wikimedia.org/r/c/mediawiki/core/+/967449>)!
As one puzzle piece of our product research efforts and platform design
explorations, Moriel and others have been working on mapping high level
essential user workflows such as edit and patrol against platform
components to explore workflow patterns and potential architectural
opportunities in the platform. One outcome of this is going to be to
describe the key challenges when trying to model our system. Many thanks to
Moriel for leading on this work, and Daniel, Timo, Subbu, James, Cindy,
Emanuele and Amir S for their support, great questions and ideas!
Up next: Presentations at Semantic MediaWikiCon
Semantic MediaWikiCon
<https://www.semantic-mediawiki.org/wiki/SMWCon_Fall_2023#Program> is
coming up, virtual and in person from Dec 11-13. We shared about the
updates to the rdbms library in the last MW Insights email - if you want to
learn more about this work, check out Amir’s presentation at Semantic
MediaWikiCon
<https://www.semantic-mediawiki.org/wiki/SMWCon_Fall_2023/Major_changes_on_i…>!
Subbu and C.Scott are also going to give their yearly update on the parser
unification work
<https://www.semantic-mediawiki.org/wiki/SMWCon_Fall_2023/Updates_from_the_W…>,
Chris will be talking about Codex
<https://www.semantic-mediawiki.org/wiki/SMWCon_Fall_2023/Codex,_the_Design_…>,
and Stef about automated testing for complex MediaWiki topologies
<https://www.semantic-mediawiki.org/wiki/SMWCon_Fall_2023/Automated_Testing_…>.
Since the theme of this edition is MediaWiki in the age of AI, Mike will be
presenting on the recent experiences with the experimental Wikipedia
ChatGPT plugin
<https://www.semantic-mediawiki.org/wiki/SMWCon_Fall_2023/The_Wikipedia_Chat…>.
Keynote speaker of this years’ Semantic MediaWikiCon is Markus Krötsch
<https://www.korrekt.org/page/Short_biography>.
That’s the last insights email for 2023. The deployment train pauses for
the end of the year break, and so does the monthly MW Insights email!
We’ll be following up with a double-edition in January.
Thanks all for reading,
Birgit
--
Birgit Müller (she/her)
Director of Product, MediaWiki and Developer Experiences
Wikimedia Foundation <https://wikimediafoundation.org/>
As per the MediaWiki version lifecycle[1], I would like to announce the
formal end of life (EOL) of MediaWiki 1.35 as of today, Thursday December
21, 2023.
1.35.14 is expected to be the last release for this branch.
This means that MediaWiki 1.35 will no longer receive maintenance or
security backports. It is therefore strongly discouraged that you continue
to use it.
It is recommended to upgrade either to MediaWiki 1.39 (LTS), which will be
supported until November 2025, 1.40, which will be supported until June
2024, or to 1.41 (due to be released today, Thursday December 21, 2023)
which will be supported until December 2024.
Thanks!
Sam Reed
[1] https://www.mediawiki.org/wiki/Version_lifecycle