Hi Everyone,
During a Mediawiki 1.34.3 to Mediawiki 1.34.4 upgrade... When updating
vendor components using 'php -d extension=phar.so composer.phar
update':
Package wikimedia/password-blacklist is abandoned, you should avoid
using it. Use wikimedia/common-passwords instead.
Package jakub-onderka/php-parallel-lint is abandoned, you should avoid
using it. Use php-parallel-lint/php-parallel-lint instead.
Package jakub-onderka/php-console-color is abandoned, you should avoid
using it. Use php-parallel-lint/php-console-color instead.
Package jakub-onderka/php-console-highlighter is abandoned, you should
avoid using it. Use php-parallel-lint/php-console-highlighter instead.
Package phpunit/php-token-stream is abandoned, you should avoid using
it. No replacement was suggested.
Package phpunit/phpunit-mock-objects is abandoned, you should avoid
using it. No replacement was suggested.
I don't add things to vendor/, and I did not install packages like
password-blacklist or php-parallel-lint. It looks like these are part
of a Mediawiki installation.
/var/www/html/wiki# find . -name password-blacklist
./vendor/wikimedia/password-blacklist
/var/www/html/wiki# find . -name php-parallel-lint
./vendor/jakub-onderka/php-parallel-lint
Jeff
As per the MediaWiki version lifecycle,[1] I would like to announce the
formal end of life (EOL) of MediaWiki 1.34 as of today, Monday November 30,
2020.
This means that MediaWiki 1.34 will no longer receive maintenance or
security backports. It is therefore strongly discouraged that you continue
to use it.
It is recommended to upgrade to MediaWiki 1.35, the current Long Term
Support (LTS) version which is not due to become EOL until September 2023.
The legacy Long Term Support version of MediaWiki, MediaWiki 1.31, is older
and downgrading is not supported.
MediaWiki 1.35 bumps the required PHP version from 7.2.9 in 1.34 (which is
unsupported upstream), to PHP 7.3.19 or later.
Thanks!
Sam Reed
[1] https://www.mediawiki.org/wiki/Version_lifecycle
I upgraded a Debian 9 "Stretch" server to Debian 10 "Buster", which also
upgrades Mediawiki to version 1.31.
Trying to run update.php, it fails with "Cannot access the database: No
database connection":
/var/lib/mediawiki/maintenance# php update.php
MediaWiki 1.31.10 Updater
Your composer.lock file is up to date with current dependencies!
[6b70dd5bdc9deadcca99506a] [no req] Wikimedia\Rdbms\DBConnectionError from line 1004 of /usr/share/mediawiki/includes/libs/rdbms/database/Database.php: Cannot access the database: No database connection
Backtrace:
#0 /usr/share/mediawiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1140): Wikimedia\Rdbms\Database->reportConnectionError(string)
#1 /usr/share/mediawiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php(750): Wikimedia\Rdbms\LoadBalancer->reportConnectionError()
#2 /usr/share/mediawiki/includes/GlobalFunctions.php(2813): Wikimedia\Rdbms\LoadBalancer->getConnection(integer, array, boolean)
#3 /usr/share/mediawiki/maintenance/Maintenance.php(1311): wfGetDB(integer, array, boolean)
#4 /usr/share/mediawiki/maintenance/update.php(147): Maintenance->getDB(integer)
#5 /usr/share/mediawiki/maintenance/doMaintenance.php(94): UpdateMediaWiki->execute()
#6 /usr/share/mediawiki/maintenance/update.php(248): require_once(string)
#7 {main}
The database is Postgresql, and I can access it fine with psql etc.
In LocalSettings.php I have
## Database settings
$wgDBtype = "postgres";
$wgDBserver = "localhost";
$wgDBname = "wikidb";
$wgDBuser = "...hidden...";
$wgDBpassword = "...hidden...";
# Postgres specific settings
$wgDBport = "5432";
$wgDBmwschema = "mediawiki";
$wgDBts2schema = "public";
Thanks for any help...
MI
Hi everyone,
I need to have my bot mark a page for translation. AFAICS the only way
to mark a page for translation is Special:PageTranslate.
Is there another way?
Can I have my bot call the Special Page?
If so how do I go about creating a session with the bot?
Or do I need to create my own extension which exposes the feature as an
API call?
Thanks in advance.
Regards,
Sebastian
MW 1.35.0, TemplateData 0.1.2: I have an issue editing via Visual Editor (VE) templates defined using TemplateData once the pages containing these templates have been saved. I am not using subpages for the documentation. The templates work except for this issue with editing.
Specifically, editing these templates works fine in VE up through the first save (i.e., for initial template population and any editing before save), for example: https://imgur.com/a/dTKW7xv <https://imgur.com/a/dTKW7xv>
but upon subsequent edits it cannot find the template as shown here: https://imgur.com/a/q9kla6J <https://imgur.com/a/q9kla6J> : It strangely believes that :index.php?title=Template:<Template Name> is the name of the Template page!
I would like to know if others have experienced this issue. I have attached some technical analysis outlining what the problem may be.
Ben
Analysis of the javascript in the VE module indicates tha3t there seems to be a problem with how the template page names are being extracted:
1) the href referring to the clicked-on template is passed to normalizeParsoidResourceName
dm/models/ve.dm.MWTemplateModel.js
----------------------------------
ve.dm.MWTemplateModel = function VeDmMWTemplateModel( transclusion, target ) {
// Parent constructor
ve.dm.MWTemplateModel.super.call( this, transclusion );
// Properties
this.target = target;
for (var i in target)
{
console.log("BJS "+i+" "+target[i]);
}
// TODO: Either here or in uses of this constructor we need to validate the title
this.title = target.href ? mw.libs.ve.normalizeParsoidResourceName( target.href ) : null; /// BJS ********* href ./index.php%3Ftitle=Template:Book
this.sequence = null;
this.params = {};
this.spec = new ve.dm.MWTemplateSpecModel( this );
this.originalData = null;
};
2) normalizeParsoidResourceName is essentially a wrapper to parseParsoidResourceName, which in turn passes the decoded URI to decodeURIComponentIntoArticleTitle
modules/ve-mw/preinit/ve.utils.parsoid.js
————————————————————
mw.libs.ve.normalizeParsoidResourceName = function ( resourceName ) {
return mw.libs.ve.parseParsoidResourceName( resourceName ).title;
};
mw.libs.ve.parseParsoidResourceName = function ( resourceName ) {
// Resource names are always prefixed with './' to prevent the MediaWiki namespace from being
// interpreted as a URL protocol, consider e.g. 'href="./File:Foo.png"'.
// (We accept input without the prefix, so this can also take plain page titles.)
var matches = resourceName.match( /^(\.\/|)(.*)$/ );
console.log("BJS utils.parsoid matches "+matches);
console.log("BJS utils.parsoid matches decoded "+mw.libs.ve.decodeURIComponentIntoArticleTitle( matches[ 2 ] ));
return {
// '%' and '?' are valid in page titles, but normally URI-encoded. This also changes underscores
// to spaces.
title: mw.libs.ve.decodeURIComponentIntoArticleTitle( matches[ 2 ] ),
rawTitle: matches[ 2 ]
};
};
3) However, and I believe this is where things go horribly awry, decodeURIComponentIntoArticleTitle does nothing of the sort, it simply runs decodeURIComponent against the string, without extracting the article title (which is presumably what is intended per the function name) - so everything that subsequently uses template.title is in fact still using the URI, not the article name.
modules/ve-mw/preinit/ve.utils.parsoid.js
————————————————————
mw.libs.ve.decodeURIComponentIntoArticleTitle = function ( s, preserveUnderscores ) {
try {
s = decodeURIComponent( s );
} catch ( e ) {
console.log("BJS error");
return s;
}
if ( preserveUnderscores ) {
return s;
}
return s.replace( /_/g, ' ' );
};
Hi everyone,
I would like to force a redirect to another page after the successful
saving of pages in a certain namespace. I was able to do that in the
most ugly way possible via a "ArticleUpdateBeforeRedirect" hook:
public static function onArticleUpdateBeforeRedirect(
$article,
&$sectionanchor,
&$extraq)
{
if ($article->getTitle()->getNamespace() == NS_DESCRIPTION) {
$extraq = "title=" . $article->getTitle()->getDBKey();
}
}
What I would really like is to overwrite the "Location" header but that
seems to be set after this hook is called.
Any ideas?
Cheers,
Sebastian
Hello!
I just tried to upgrade some wikis from 1.31.6 and 1.34.1 to 1.35.0. The
process fails with
...recentchanges table does not contain rc_user_text field.
...logging table does not contain log_user field.
...logging table does not contain log_user_text field.
Adding index redirect_pkey to table redirect
...Wikimedia\Rdbms\DBQueryError from line 1699 of
/data/mediawiki/software/mediaw
iki-1.35.0/includes/libs/rdbms/database/Database.php: Error 23505:
ERROR: could not create unique index "redirect_pkey"
DETAIL: Key (rd_from)=(2527) is duplicated.
Function: Wikimedia\Rdbms\Database::sourceFile(
/data/mediawiki/software/mediawiki-1.35.0/maintenance/postgres/archives/patch-
redirect-pk.sql )
Query: ALTER TABLE redirect ADD PRIMARY KEY (rd_from)
and the table "redirect" indeed contains duplicate and triplicate
entries for a lot of my wikis.
IMHO either the update script should collapse these entries, or the
requirement for an index should be dropped from the installer. Does
anyone have a quick SQL snippet to fix these tables?
Joern
--
Jörn Clausen
BITS - Bielefelder IT-Servicezentrum
https://www.uni-bielefeld.de/bits
Hi everyone,
I am very pleased to announce that the next EMWCon, or Enterprise MediaWiki
Conference, will be an in-person event, to be held in Nashville, Tennessee
(in the United States) next year. We don't have a date yet, but it will
probably be sometime in April or May.
EMWCon is an annual conference, since 2016, for all users of "enterprise
MediaWiki" (essentially any usage of MediaWiki outside the Wikimedia sites).
If you are considering attending - either in-person or remotely - please
add your name to the wiki page here, so we can try to get a sense of what
the attendance will be:
https://www.mediawiki.org/wiki/EMWCon_Spring_2021
-Yaron