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…
Hey all,
This is a quick note to highlight that in six weeks' time, the REL1_40
branch will be created for MediaWiki core and each of the extensions and
skins in Wikimedia git, with some (the 'tarball') included as sub-modules
of MediaWiki itself[0]. This is the first step in the release process for
MediaWiki 1.40, which should be out in May 2023, approximately six months
after MediaWiki 1.39.
The branches will reflect the code as of the last 'alpha' branch for the
release, 1.40.0-wmf.27, which will be deployed to Wikimedia wikis in the
week beginning 13 March 2023 for MediaWiki itself and those extensions
and skins available there.
After that point, patches that land in the main development branch of
MediaWiki and its bundled extensions and skins will be slated for the
MediaWiki 1.41 release unless specifically backported[1].
If you are working on a new feature that you wish to land for the release,
you now have a few days to finish your work and land it in the development
branch; feature changes should not be backported except in an urgent case.
If your work might not be complete in time, and yet should block release
for everyone else, please file a task against the `mw-1.40-release` project
on Phabricator.[2]
If you have tickets that are already tagged for `mw-1.40-release`, please
finish them, untag them, or reach out to get them resolved in the next few
weeks.
We hope to issue the first release candidate, 1.40.0-rc.0, two weeks after
the branch point, and if all goes well, to release MediaWiki 1.40.0 a few
weeks after that.
Tyler Cipriani (he/him)
Engineering Manager, Release Engineering
Wikimedia Foundation
[0]: <https://www.mediawiki.org/wiki/Bundled_extensions_and_skins>
[1]: <https://www.mediawiki.org/wiki/Backporting_fixes>
[2]: <https://phabricator.wikimedia.org/tag/mw-1.40-release/>
If your code doesn't read or write to databases in MediaWiki, feel free to
ignore this email.
Hello,
We have made changes to MediaWiki's Rdbms library that simplify and improve
how to get database connections and how to perform UPDATE queries. We
encourage you to adopt these and provide feedback here or via Phabricator.
== 1. Get a database connection ==
What changed:
To get a connection to the primary database, you previously needed the
following:
$lbFactory = MediaWikiServices::getInstance()->getDBLoadBalancerFactory();
$lbFactory->getMainLB()->getConnection( DB_PRIMARY );
And for a replica connection:
$lbFactory->getMainLB()->getConnection( DB_REPLICA );
You may now adopt the simpler $lbFactory->getPrimaryDatabase() and
$lbFactory->getReplicaDatabase().
In other words, instead of needing knowledge of the internal LoadBalancer,
its getConnection methods, and the DB_ constants, you only call
getPrimaryDatabase() or getReplicaDatabase().
We won’t deprecate LoadBalancer::getConnection() any time soon. If your
code depends on other LoadBalancer methods, feel free to keep your code
as-is. This change is aimed at the most common use case where you only need
a database connection.
The optional parameters have gotten more usable as well.
getPrimaryDatabase() only takes $domain, which means you no longer need to
skip over the non-applicable $groups parameter. getReplicaDatabase() takes
a string for $group (instead of an array in LB::getConnection).
If you maintain service classes that inject a LoadBalancer object, we
recommend transitioning to inject and type against LBFactory instead. This
removes exposure to LB altogether in most cases.
Currently, getPrimaryDatabase/getReplicaDatabase do not yet support
connection to external clusters (LB::getExternalLB). This is coming soon
(see below).
Reasoning:
We have been reducing complexity around LB/LBF for a while (T326274
<https://phabricator.wikimedia.org/T326274>). The distinction between these
is arbitrary in practice, each wears too many hats, and are not well
encapsulated internally.
Most importantly, LB is mostly internal to the Rdbms library. Most
developers only need a connection to perform read or write queries. The
added coupling can lead to mistakes, misunderstandings, and can feel
overwhelming. The LB documentation includes jargon aimed at Rdbms
maintainer, such as references to internal methods like
isReadyForRoundOperations, setTempTablesOnlyMode, getAnyOpenConnection,
appendShutdownCPIndexAsQuery, etc.
The getConnection() signature is fragile and has led to major outages due
to $domain being set incorrectly. E.g. if you need to connect to another
wiki, you have to set $domain in *both* getMainLB() and getConnection(),
otherwise *fireworks in production*. We keep this internally now to prevent
future outages.
Lastly, this change makes it possible to add a narrow typehint dedicated to
read-only connections on replica databases, separate from primary database
connections (more below).
Example adoption:
-
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/891357
-
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DiscussionTools/+/890…
Adaption is being tracked in T330641
<https://phabricator.wikimedia.org/T330641>
What is next:
getPrimaryDatabase() and getReplicaDatabase() don't support "external"
databases yet (e.g. x1 at WMF
<https://wikitech.wikimedia.org/wiki/MariaDB#Extension_storage>). This is
coming soon. Details and discussion at T330590
<https://phabricator.wikimedia.org/T330590>.
In addition to reducing service dependencies to the ILBFactory typehint, we
are working on an even narrower interface (that ILBFactory extends) called
IConnectionProvider
<https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/…>
which only has four methods. It’s marked @internal for now, but that will
change after we hammer out some details.
== 2. IReadableDatabase typehint for replica connections ==
What changed:
When you typehint a parameter or class member to IDatabase where a replica
database is expected (DB_REPLICA), you may change it to the narrower
IReadableDatabas interface.
LBFactory::getReplicaDatabase returns IReadableDatabase.
Reasoning:
MediaWiki developers have at times performed write queries on a replica
connection by mistake, which reached production. While we have effective
protections against data corruption, our only option in production is to
throw a fatal error, which leads to an outage. With this change we move
detection to the very start of the development cycle, verified fully by
static analysis in CI, regardless of test coverage!
The new interface also helps you to self-document in a standard way whether
your service class only reads or also writes to the database. And in IDEs
we will no longer autocomplete write methods on what are known to be
replica connection objects. It’ll also make the coupling between the rest
of MediaWiki and extension with the rdbms library looser
<https://en.wikipedia.org/wiki/Loose_coupling#In_programming>.
Note that the IDatabase::query() is not part of IReadableDatabase. This
method is discouraged as it executes raw SQL that may include write
queries. If you call this method, continue to typehint IDatabase until you
transition to safe methods like select() or SelectQueryBuilder.
Example adoption:
-
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GrowthExperiments/+/8…
== 3. Introducing UpdateQueryBuilder ==
What changed:
In 2020, we introduced a chainable SelectQueryBuilder
<https://www.mediawiki.org/wiki/Manual:Database_access#SelectQueryBuilder>
for SELECT queries. To complement this, we now added a class called
UpdateQueryBuilder, for UPDATE queries. The following existing code uses
update() with unnamed positional parameters:
$db->update(
'image',
[ 'img_name' => 'foo' ],
[ 'img_name' => 'bar' ],
__METHOD__
);
You may now use the fluent style like so:
$db->newUpdateQueryBuilder()
->update( 'image' )
->set( [ 'img_name' => 'foo' ] )
->where( [ 'img_name' => 'bar' ])
->caller( __METHOD__ )
->execute();
Reasoning:
Similar to the SelectQueryBuilder, the fluent style is more readable. It
simplifies building of conditions, is less prone to mistakes, and is more
aligned with widely-used frameworks such as Doctrine (PHP) and Jooq (Java).
We have had at least two data corruption incidents in production due to
passing the wrong order of $set and $where condition (swapping them by
mistake). This reduces the chance of such data corruptions happening, which
alone was worth developing the builder for, before we get to the improved
ergonomics.
Example adoption:
-
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/889627/5/includes/Categor…
Adaption is being tracked in T330640
<https://phabricator.wikimedia.org/T330640>.
What is next:
We will continue to develop query builders for DELETE and INSERT queries.
The work on migrating calls from ::select() to SelectQueryBuilder is
on-going (T311866 <https://phabricator.wikimedia.org/T311866>).
Thank you
--
*Amir Sarabadani (he/him)*
Staff Database Architect
Wikimedia Foundation <https://wikimediafoundation.org/>
I would like to announce the availability of MediaWiki 1.39.2.
This release primarily is to fix various issues around database upgrades
that users have reported on both MySQL/MariaDB and PostgreSQL.
In the case of MySQL/MariaDB, there may have been the chance of data loss
(as always, please backup before upgrading!), and page views may have
resulted in an error like "The revision #0 of the page named "x" does not
exist." This was seen only when upgrading in a bigger jump between versions
(for example 1.31 to 1.39). More information can be seen in
https://phabricator.wikimedia.org/T326071.
https://phabricator.wikimedia.org/T328169 has been filed to write a
maintenance script to fix the issues caused by these upgrades. It is
expected this will be included in a later point release.
Various patches aimed at support for PHP 8.0, 8.1, and 8.2 have been
back-ported. This should fix some log spam, and MediaWiki should work fully
on versions PHP 8.0 and 8.1.
Reports of bugs with PHP 8.0, 8.1, or 8.2 support are particularly welcome,
and fixes will be back-ported when possible. Please see
https://phabricator.wikimedia.org/tag/php_8.0_support/,
https://phabricator.wikimedia.org/tag/php_8.1_support/ and
https://phabricator.wikimedia.org/tag/php_8.2_support/ for the relevant
work boards.
The tarballs have already been uploaded as of this email; the git tag has
also already been pushed.
== Release notes ==
Full release notes for 1.39.2:
https://phabricator.wikimedia.org/diffusion/MW/browse/REL1_39/RELEASE-NOTES…https://www.mediawiki.org/wiki/Release_notes/1.39
== Changes since MediaWiki 1.39.1 ==
* Localisation updates.
* (T325872) ChangeTags: Remove table name from condition.
* (T324895) MWCallbackStream: Add explicit $stream property.
* (T297031, T326039) PostgresUpdater: Move setDefault ahead of
changeNullableField.
* (T321319) Produce HTML for invalid JSON.
* (T215466, T326071) MigrateActors: Write to revision table (Follow-up
24115a8).
* (T223027) ReservedUsernames config: Add reserved names from maintenance
scripts.
* (T325000, T324896, T307631) Updated OOUI from v0.44.3 to v0.44.5.
* Remove /images .htaccess rules that are no longer relevant.
* Disable php in .htaccess of images directory as a hardening measure.
* (T322583) Include missing message parameter in message.
* LocalFileTest: use encodeBlob/decodeBlob for img_metadata.
* DatabaseSqlite: fix null blobs.
* rdbms: avoid pg_escape_bytea() call-style deprecation notices.
* (T322278) Improve LocalisationCache post-merge validation check.
* (T324408, T326367) Updated wikimedia/remex-html from 3.0.2 to 3.0.3.
* (T322278) Fix the remaining Phan failures on PHP 8.1.
* (T322278, T326367) Respond to some messages from Phan on PHP 8.1.
* Fix phan error when Excimer is enabled.
* (T326021) Add matrix: to $wgUrlProtocols.
* (T314099) stream wrapper: Declare $context class property.
* (T314099) libs\jsminplus: Declare JSNode::$expression.
* (T314096) composer.json: Updated composer/spdx-licenses from 1.5.6 to
1.5.7.
* (T326472) Upgrading cssjanus/cssjanus (v2.1.0 => v2.1.1).
* (T308536) rdbms: Remove deprecation mark for $wgSharedDB.
* (T215466, T326071) installer: Split drop action out of the SQL patch for
actor migration.
* (T322603) SqliteMaintenance.php: Fix fatally broken instanceof check.
* (T326377) rdbms: Use DBConnRef in SelectQueryBuilder.
* api/en.json: api-help-datatype-expiry add missing 'may'.
* (T317329) OutputPage: Fix undefined ['host'] in ImagePreconnect code.
* (T328222) Pass empty string to strlen() if schema is null for
PostgresDatabase.
* (T289926) SpecialRevisionDelete: Set default of '' for wpReason.
* (T155582, T328503) Fix XML dumps for content types with non-string
getNativeData().
* (T326886) PoolCounterRedis: Fix wrong cast, locks weren't being released.
* (T314099) revisiondelete: Replace dynamic property Status::$itemStatuses
* (T327821) skin: Restore default 'value' attribute in makeSearchButton().
* (T329198) ParamValidator: Improve paramvalidator-help-multi-max message.
* (T329415) Clear the statsd data buffer regardless of StatsdServer config.
* (T292348) WikiImporter: do not fail if upload entry in dump lacks 'text'
tag.
* (T330049) UnregisteredLocalFile: Don't call MimeAnalyzer if no path.
* (T324894 TempFSFile: Use a WeakMap for reference tracking if available.
* (T295637) Add no to fallback chain of nb and nn.
**********************************************************************
Download:
https://releases.wikimedia.org/mediawiki/1.39/mediawiki-1.39.2.tar.gzhttps://releases.wikimedia.org/mediawiki/1.39/mediawiki-1.39.2.zip
Download without bundled extensions:
https://releases.wikimedia.org/mediawiki/1.39/mediawiki-core-1.39.2.tar.gzhttps://releases.wikimedia.org/mediawiki/1.39/mediawiki-core-1.39.2.zip
Patch to previous version (1.39.1):
https://releases.wikimedia.org/mediawiki/1.39/mediawiki-1.39.2.patch.gzhttps://releases.wikimedia.org/mediawiki/1.39/mediawiki-1.39.2.patch.zip
GPG signatures:
https://releases.wikimedia.org/mediawiki/1.39/mediawiki-core-1.39.2.tar.gz.…https://releases.wikimedia.org/mediawiki/1.39/mediawiki-core-1.39.2.zip.sighttps://releases.wikimedia.org/mediawiki/1.39/mediawiki-1.39.2.tar.gz.sighttps://releases.wikimedia.org/mediawiki/1.39/mediawiki-1.39.2.zip.sighttps://releases.wikimedia.org/mediawiki/1.39/mediawiki-1.39.2.patch.gz.sighttps://releases.wikimedia.org/mediawiki/1.39/mediawiki-1.39.2.patch.zip.sig
Public keys:
https://www.mediawiki.org/keys/keys.html
Hello,
I have some array declarations in my LocalSettings.php from many years ago
that I am worried may not be compatible with PHP 8+. When I try to run
/maintenance/update.php in PHP 8.1 I get errors. It runs fine in PHP 7.4.3,
fortunately. However, is it okay to set arrays like this in PHP 8+?:
$wgSitemapNamespaces = array( 0, 100, 102 );
Thank you :)
Roger
teflpedia.com <- MediaWiki 1.39.1 recently upgraded
-----example from my LocalSettings.php-----
# Site Map see https://www.mediawiki.org/wiki/Manual:$wgSitemapNamespaces
#$wgSitemapNamespaces = array( 0, 2, 4, 12 ); # example, to site map
Main-0, User-2, Project-4, Help-12 namespace
$wgSitemapNamespaces = array( 0, 100, 102 ); # let's site map ONLY Main,
Essay, Lesson namespace
## Extra namespaces
$wgExtraNamespaces[100] = "Lesson";
$wgExtraNamespaces[101] = "Lesson_talk";
$wgExtraNamespaces[102] = "Essay";
$wgExtraNamespaces[103] = "Essay_talk";
$wgExtraNamespaces[104] = "Debate";
$wgExtraNamespaces[105] = "Debate_talk";
## Enable subpages in all namespaces
$wgNamespacesWithSubpages = array_fill(0, 200, true);
$wgNamespacesWithSubpages[NS_MAIN] = false; # per Duncan request Jan 11,
2022
## Set default searching. Roger 2012.11.03, updated array syntax 2023.02.13
$wgNamespacesToBeSearchedDefault = [
NS_MAIN => true,
NS_TALK => false,
NS_USER => false,
NS_USER_TALK => false,
NS_PROJECT => false,
NS_PROJECT_TALK => false,
NS_IMAGE => false,
NS_IMAGE_TALK => false,
NS_MEDIAWIKI => false,
NS_MEDIAWIKI_TALK => false,
NS_TEMPLATE => false,
NS_TEMPLATE_TALK => false,
NS_HELP => false,
NS_HELP_TALK => false,
NS_CATEGORY => false,
NS_CATEGORY_TALK => false,
100 => true,
101 => false
];
-------/example--------
The Tech Department at Wikimedia Foundation [1] invites you to a* special
event on February 09, 2023, at 1600 UTC* [2].
*Richard Evans, Electronics & Data Systems Engineer At NASA Glenn Research
Center *[3], will be presenting on *how MediaWiki is being used within NASA*
to help manage the testing of very large spacecraft to prove they can
survive the harsh conditions of launch, orbit, and re-entry. The management
platform is built from MediaWiki and several key extensions that provide
workflow support. This evolving platform plans to incorporate the
extensions that form the MediaWiki-powered Open CSP platform [4]. This talk
will explain the architecture and benefits of the NASA platform and
motivate the need for Open CSP. We’ll also be recording the event to share
with those who can’t make it. You can join the event through Google Meet
[5].
Looking forward to seeing you there,
*--on behalf of the Tech Department, Wikimedia Foundation.*
*(For follow-ups, please reach out to *lnguyen(a)wikimedia.org.)
[1] https://www.mediawiki.org/wiki/Wikimedia_Technology
[2] https://zonestamp.toolforge.org/1675958415
[3] https://www.wikidata.org/wiki/Q618728#sitelinks-wikipedia
[4] https://www.open-csp.org/Main_Page
[5]
https://stream.meet.google.com/stream/ce81307c-cdb7-4a5e-9697-65c423f27614
--
________________________________
Erica Litrenta (she/her)
Senior Manager, Community Relations Specialists (Product)
Wikimedia Foundation
Hi everybody,
we want to import and integrate some older MediaWiki databases (xml
export / import) and shut down some old instances.
For that we do want to move the content to separated namespaces.
Sadly these wikis were using different licenses.
Is there a way to change the license based on namespaces?
Best regards,
Dennis