Hello everyone,
The Committee has finished selecting its new members. The new committee
candidates are (in alphabetical order):
- Amir Sarabadani
- Egbe Eugene Agbor (Eugene233)
- Jayprakash12345
- MusikAnimal
- Nuria Ruiz (Nurieta)
Auxiliary members will be (alphabetically):
- Effie Mouzeli
- Joris Darlington Quarshie
- Martin Urbanec
- SD0001
- Tony Thomas (01tonythomas)
You can read more information about the members at [1]. List of changes
from the last term:
- Jay is joining the main committee (served as auxiliary member for
several years)
- I'm moving to the aux committee
- SD0001 and Joris Darlington Quarshie are joining the aux committee
- Huji and Luke081515 are leaving the aux committee
This is not the final structure. According to the CoC [2], the current
committee publishes the new members and call for public feedback for *six
weeks* and after that, the current committtee might apply changes to the
structure based on public feedback.
Please let the committee know (via techconduct(a)wikimedia.org) if you have
any concern regarding the members and its structure until *30 July 2023*
and after that, the new committee will be in effect and will serve for a
year.
[1]
https://www.mediawiki.org/wiki/Code_of_Conduct/Committee/Members/Candidates
[2]
https://www.mediawiki.org/wiki/Code_of_Conduct/Committee#Selection_of_new_m…
Martin Urbanec, on behalf of the Code of Conduct Committee
Hello,
As part of work to make storage of external links in MediaWiki continue to
scale without risking site stability (T312666
<https://phabricator.wikimedia.org/T312666>), we are deprecating most of
the special functionalities around proto-relative URLs (URLs that start
with // instead of https:// or http://).
Proto-relative URLs were beneficial a decade ago, when Wikimedia projects
were being served in both encrypted and unencrypted traffic (http and
https). However, since 2015, all of our traffic has been served encrypted
only, and this functionality doesn’t provide much user benefit any more for
Wikimedia wikis. With HTTP/2, a similar circumstance applies to all
MediaWiki users.
As well as being low-value, our external links storage (the externallinks
table) has grown to be one of the biggest tables for each production wiki.
This is due to many duplications of URL information, added to serve
different use cases. With the changes, we are removing these duplications,
and some of the functionality. You can read more about the work in T312666
<https://phabricator.wikimedia.org/T312666>.
Storage of proto-relative URLs has changed to only store HTTPS URLs
Previously, if a proto-relative was added in an edit, MediaWiki internally
treated it as two links one with http:// and one with https://. From this
week forward, for all Wikimedia wikis, the storage will change to store
only https:// URLs. Once those wikis are switched to read the new database
schema, the links will be presented as https only in Special:LinkSearch and
their API counter-parts. This means effectively a proto-relative external
link will be treated like a HTTPS one. This change will also apply to
non-Wikimedia wikis using MediaWiki 1.41+.
expandurl option is deprecated and ignored in the exturlusage and extlinks
MediaWiki action API modules
This means “expandurl” argument in exturlusage and extlinks
<https://www.mediawiki.org/wiki/API:Extlinks> API modules will be ignored
and proto-relative URLs will be always expanded to HTTPS. This will happen
any time a wiki is switched to read from the new externallinks fields. (You
can track the progress in T335343
<https://phabricator.wikimedia.org/T335343>) This change will also apply to
non-Wikimedia wikis using MediaWiki 1.41+.
If your wiki heavily uses proto-relative URLs in articles' wikitext, we
recommend changing them to https instead which also improves storage as
every proto-relative URLs takes up two rows.
Thank you,
--
Amir Sarabadani, Staff Database Architect
James Forrester, Staff Software Engineer
Timo Tijhof, Principal Performance Engineer
Hello all,
The Code of Conduct Committee is a team of five trusted individuals (plus
five auxiliary members) with diverse affiliations responsible for general
enforcement of the Code of conduct for Wikimedia technical spaces.
Committee members are in charge of processing complaints, discussing with
the parties affected, agreeing on resolutions, and following up on their
enforcement. For more on their duties and roles, see
https://www.mediawiki.org/wiki/Code_of_Conduct/Committee.
This is a call for community members interested in volunteering for
appointment to this committee. Volunteers serving in this role should be
experienced Wikimedians or have had experience serving in a similar
position before.
The current committee is doing the selection and will research and discuss
candidates. Six weeks before the beginning of the next Committee term,
meaning July 16, 2023, they will publish their candidate slate (a list of
candidates) on-wiki. The community can provide feedback on these
candidates, via private email to the group choosing the next Committee. The
feedback period will be two weeks. The current Committee will then either
finalize the slate, or update the candidate slate in response to concerns
raised. If the candidate slate changes, there will be another two week
feedback period covering the newly proposed members. After the selections
are finalized, there will be a training period, after which the new
Committee is appointed. The current Committee continues to serve until the
feedback, selection, and training process is complete.
If you are interested in serving on this committee or like to nominate a
candidate, please write an email to techconductcandidates AT wikimedia.org
with details of your experience on the projects, your thoughts on the code
of conduct and the committee and what you hope to bring to the role and
whether you have a preference in being auxiliary or main member of the
committee. The committee consists of five main members plus five auxiliary
members and they will serve for a year; all applications are appreciated
and will be carefully considered. The deadline for applications is *the end
of day on May 31 2023*.
Please feel free to pass this invitation along to any users who you think
may be qualified and interested.
Best,
Martin Urbanec, on behalf of the Code of Conduct Committee
Hello,
We have two breaking changes to announce.
Breaking change to Rdbms Database subclasses
There are no Database subclasses currently known in Codesearch (besides
those built-in to core). But, since the class is documented as "stable to
extend" in API, an announcement is in order.
First, an explanation on what is happening. Currently, queries flow in the
Rdbms library as follows: When Database::select() or similar is called
(directly, or via the query builders), the Rdbms library internally builds
the SQL text and then calls the general-purpose function Database::query().
Subsequently, ::query() then runs several regexes over the SQL text to
figure out information about this query (which tables are affected, whether
it’s a write query, what the query “verb” is, and so on). This is taxing
and slow. The appservers at WMF, for example, spend 0.34% of CPU on web
requests just to extract information from already-formatted SQL queries for
logging purposes. This logic drastically reduces readability and
maintainability of Rdbms internals.
To fix this, we've internally introduced a new class called Query, to
represent the SQL text in a more structured way in the first place. This
avoids having to first format structure data into SQL text only to
reverse-engineer it right afterwards.
This change requires changing the protected Database::executeQuery() method
to no longer accept a string argument and instead require a Query object.
Additionally IDatabase::getTempTableWrites() has become a private method.
See the patch <https://gerrit.wikimedia.org/r/c/mediawiki/core/+/910756> or the
ticket <https://phabricator.wikimedia.org/T326181> for more information.
The public Database::query() method continues to support a string argument,
but now also supports a Query object. When given a string, it falls back to
the old regexes to extract and create a Query object. With the newly
introduced UnionQueryBuilder, we believe there are no longer cases where
MediaWiki extensions have to call Database::query, and can instead adopt
query builders for all their queries. Direct calls to Database::query
outside of MediaWiki core are now highly discouraged.
Breaking change to typehints of IDatabase
Many parts of core typehint to IDatabase, but most times these always
return a replica database. For example, ApiBase::getDB(). This means the
interface technically allows calling insert(), and this is indeed valid,
but would also immediately throw a fatal error once the method is entered.
Going forward, most of these will be typehinted to IReadableDatabase
instead, which is a narrower interface (34 public methods instead of 83).
This is not a breaking change in practice, because calls to those methods
would already produce an error, but the typehint makes it official now. This
<https://gerrit.wikimedia.org/r/c/mediawiki/core/+/911269> is the patch
changing ApiBase::getDB(), and we expect more such changes to other parts
of MediaWiki over the coming months. Those will not be individually
announced.
Best
--
*Amir Sarabadani (he/him)*
Staff Database Architect
Wikimedia Foundation <https://wikimediafoundation.org/>
Hello,
As part of ongoing refactors and improvements to the Rdbms component in
MediaWiki, we have made some changes that might affect your work. Read
the February
announcement
<https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/…>
for previous changes in this area.
New DeleteQueryBuilder and UnionQueryBuilder
We introduced the chainable SelectQueryBuilder
<https://www.mediawiki.org/wiki/Manual:Database_access#SelectQueryBuilder>
in 2020 to create SELECT queries. This "fluent" API style allows each
segment of the query to be set through a discoverable method name with rich
documentation and parameter types. Last February we introduced
UpdateQueryBuilder in the same vein.
The new DeleteQueryBuilder similarly supersedes use of IDatabase::delete()
for building DELETE operations. Check change 913646
<https://gerrit.wikimedia.org/r/c/mediawiki/core/+/913646/1/includes/user/Us…>
for how this is used in practice.
Union queries are fairly rare in our codebases. Previously, one would have
to bypass the query builders (by calling the underlying SQL text formatters
like Database::selectSqlText) and pass several raw SQL strings through
Database::unionQueries and then to Database::query. As you can see, this is
not optimal. The new UnionQueryBuilder enables you to combine several
SelectQueryBuilder objects and then use the familiar fetchResultSet()
method on the resulting UnionQueryBuilder object. You can see an example of
this in change 906101
<https://gerrit.wikimedia.org/r/c/mediawiki/core/+/906101/5/maintenance/find…>
.
IConnectionProvider typehint
In February, we introduced the LBFactory->getPrimaryConnection() and
LBFactory->getReplicaConnection() methods to improve ergonomics around
getting database connections, and the IReadableDatabase typehint for
replica connections.
We're now introducing the IConnectionProvider typehint as a stable
interface holding the above methods without the rest of LBFactory. Meaning,
if you all you need is a connection, you can typehint to
IConnectionProvider. This is an extremely narrow interface (four public
methods!) compared to LBFactory (42 public methods). This will reduce
coupling and should ease testing as well. We already adopted
IConnectionProvider in several MediaWiki core components, which made a
notable dent in MediaWiki's PhpMetrics complexity score
<https://doc.wikimedia.org/mediawiki-core/master/phpmetrics/complexity.html>
.
This backwards-compatible change can be adopted through only a change in
typehint. MediaWiki’s LBFactory service implements IConnectionProvider.
Dependency injection remains unchanged.
You can see an example in change 913649
<https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DiscussionTools/+/913…>.
We recommend changing variable names like $lbFactory to $dbProvider for
consistency in usage.
Future changes
We will continue transforming MediaWiki core to adopt query builders,
IConnectionProvider, and IReadableDatabase. And, we'll continue helping
various core components and extensions to phase out their direct calls to
LoadBalancer::getConnection(). This should improve code health,
readability, testability, and overall coupling scores in MediaWiki.
Our next announcement will introduce InsertQueryBuilder, and we're
considering a query builder for "UPSERT" queries as well. Lastly, we are
planning to discourage remaining use of raw SQL in "where" conditions by
introducing an expression builder (T210206
<https://phabricator.wikimedia.org/T210206>).
You can help
Nearly every feature of MediaWiki requires retrieving or storing
information from a database at one point or another. Reworking these is a
long tail of effort. Any help in adopting query builders, and updating code
away from ILoadBalancer and ILBFactory would be really appreciated.
Together we can improve readability and code health (now with less
footguns!).
Until the next update,
--
Amir Sarabadani (he/him), Staff Database Architect
Timo Tijhof, Principal Performance Engineer
Hello all,
I would like to draw your attention to the BlueSpice Product Days on May 10 and 11.
https://bluespice.com/bluespice-product-days-2023/
I briefly thought about whether this mailing list is the right place to draw attention to it. But I think you can get a good impression of what is going on technically in organizations and companies when it comes to MediaWiki and what is being discussed about content and structuring. And since we produce and publish in the Wikimedia context, all developments are available to the community. So the announcement really makes sense.
We will show nice new things like the ContentDroplets, talk about real-time editing, templates, cloud, AI and hashchains. We also have a number of interesting speakers on knowledge management.
You can attend online via Hopin. Participation is of course always free. It's best to register now.
We look forward to your participation, your feedback and thoughts.
All the best!
Dr. Richard Heigl
CEO
Hallo Welt! GmbH
We would like to announce the release of MediaWiki Language Extension
Bundle 2023.04. This bundle is compatible with '''MediaWiki >=
1.38.0''' and requires '''PHP >= 7.4.0'''.
The next MLEB is expected to be released in 3 months. If there are
very important bug fixes, we will do an intermediate release. Please
give us your feedback at
[[Talk:MLEB|https://www.mediawiki.org/wiki/Talk:MLEB]].
* Download: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2023.04.tar…
* sha256sum: c39c9d969255808a628e9fe2a9a2eceefd14ee5d3d0ef8d1fd1a4765804ad896
* Signature: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2023.04.tar…
Quick links:
* Installation instructions are at: https://www.mediawiki.org/wiki/MLEB
* Announcements of new releases will be posted to a mailing list:
https://lists.wikimedia.org/postorius/lists/mediawiki-i18n.lists.wikimedia.…
* Report bugs to: https://phabricator.wikimedia.org/project/view/1464
Release notes for each extension are below.
== Highlights ==
* This is the last release of MLEB supporting '''MediaWiki >= 1.38'''
== Babel ==
* Fix "User categories creation should be able to use templates"
({{phab|T211665}}, {{gerrit|881947}})
* Add ability to override Babel categories ({{gerrit|881944}})
* Fix "Some language tags show wrong language ("English") in Babel
boxes" ({{phab|T64714}}, {{gerrit|884400}})
== CleanChanges and cldr ==
* Localisation and maintenance updates.
== Translate ==
* Optionally allow setting a source language for aggregate groups
({{phab|T281073}})
* Allow fetching translation statistics for messages with similar
prefix ({{phab|T298966}})
* Fix bug with importing fuzzy translations from .po files ({{phab|T323430}})
* Add back-links in various special pages in the Translate extension
* Use a text-based group selector in Special:ExportTranslations in
order to improve usability when a large number of message groups are
present ({{phab|T331843}})
* Show error message if group being exported has no translations for
selected language ({{phab|T331824}})
* Display "Translate" tab if a user has permission to translate
irrespective of whether public editing is enabled ({{phab|T334330}})
* Add support to configure readable and writable translation memory
services separately ({{phab|T322284}})
** Support for the <code>mirrors</code> configuration parameter will
be dropped in the next MLEB release.
== UniversalLanguageSelector ==
* Localisation and maintenance updates.
* Fix issues with up/down keys navigation for the ULS menu ({{phab|T328956}})
* Remove ULSMobileWebfontsEnabled configuration option ({{phab|T332837}})
--
Kartik Mistry | કાર્તિક મિસ્ત્રી
kartikm.wordpress.com
Hello Everyone,
Today it was identified that the Graph extension [1], which uses the older
Vega 1 & Vega 2 libraries, had a number of security vulnerabilities.
In the interest of the security of our users, the Graph extension was
disabled on Wikimedia wiki's. We know that this is disruptive for editors
and readers, and WMF teams are working quickly on a plan to respond to
these vulnerabilities.
We recommend that any other third party users of the Graph extension should
disable the use of that extension on their wikis.
A configuration change will suppress the exposed raw tags and graph json
definition to avoid excess disruption to the end user experience when the
extension is disabled. [2] This also provides a tracking category
"Category:Pages with disabled graphs" showing the pages that used to
contain graphs. Local administrators can localise the name of the category
and its description by editing [[MediaWiki:Graph-disabled-category]],
[[MediaWiki:Graph-disabled-category-desc]] interface messages on your local
wiki.
On Wikimedia projects, graphs created via the extension will remain
unavailable. This means that pages that were formerly displaying graphs
will now display a small blank area. To help readers understand this
situation, communities can now define a brief message that can be displayed
to readers in place of each graph until this is resolved. That message can
be defined on each wiki at [[MediaWiki:Graph-disabled]] by local
administrators.
Wikimedia Foundation staff are looking at options available and expected
timelines. For updates on this topic, follow the public Phabricator task
for this issue: https://phabricator.wikimedia.org/T334940
We are seeking translation to be able to distribute a massmessage about
this to various language wikis tomorrow. Please help us translate here:
https://meta.wikimedia.org/wiki/User:Seddon_(WMF)/Graph_massmessage
Thank you,
Seddon
[1] https://www.mediawiki.org/wiki/Extension:Graph
[2]
https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/…
Seddon (he/him they/them)
*Engineering Manager*
*Wikimedia Foundation*