Has the parser just been changed with regards to tildes (~~~~) inside
HTML comments? It appears they used to be ignored, and are now
suddenly being replaced en masse the next time someone edits the page
(and can't be easily reverted - it just changes the sig to the
reverter's instead). See
http://en.wikipedia.org/wiki/Wikipedia:Articles_for_creation/2006-06-02-ear…
for an example.
I distinctly remember there was a way to add a title to a special page
simply by entering in a URL, then adding the title to the wiki edit
field, and then saving. The new "writing a new special page" how-to is
very confusing - and it wants me to write PHP to get the title to show
up. There was an easier way...
I can't find this how-to anywhere- though I'm sure it used to exist. FX
can you walk me through how you've added a wiki page title to a special
page?
Thanks!
-----Original Message-----
From: mediawiki-l-bounces(a)Wikimedia.org
[mailto:mediawiki-l-bounces@Wikimedia.org] On Behalf Of Rick DeNatale
Sent: Thursday, May 19, 2005 2:33 PM
To: MediaWiki announcements and site admin list
Subject: Re: [Mediawiki-l] Re: How to create a new Special page
On 5/13/05, FxParlant <f-x.p(a)laposte.net> wrote:
> Hello;
> There is a paragraph on how to create a special page in the FAQ
>
>
>
http://meta.wikimedia.org/wiki/Meta:FAQ#How_do_I_add_my_own_dynamic_cont
ent_to_MediaWiki.3F
>
> It's not so difficult. At the end,it says you have to create a simple
> page and write the name of your special page in it. If you forget this
> the title of your special page will have < and > around. I
haven't
> got a clue why creating a page with the name in it solves this, but it
works
That page seems to have changed, it now just has a pointer to an
article about writing an extension which really doesn't seem to build
a special page.
I just figured out how to build a new special page which is like the
Uncategorized pages page, but looks at the Image namespace. I wrote it
up at http://meta.wikimedia.org/wiki/Writing_a_new_special_page
_______________________________________________
MediaWiki-l mailing list
MediaWiki-l(a)Wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
I'm currently trying to adapt several gadgets that are meant for wikis using the Monobook/Vector skins to the Monaco skin, and so far, I've managed to successfully port over the UTC Clock gadget and Sandbox page gadget to Monaco, but aside from those I've been having trouble since, frankly, my knowledge of Javascript/JQuery is slim and I'm not familiar with all the variables used in writing user scripts. I've fairly decent with CSS style sheets, but I still need help with Javascript, so does anyone know of some good resources I could look into, preferably tailored for writing scripts on MediaWiki?
Also, if anyone wants to see what I have done so far (and have released publicly), the wiki I have been testing my live gadget/user script code on is here:
https://mediawikitesters.orain.org/wiki/Main_Page
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--------