During a Mediawiki 1.34.3 to Mediawiki 1.34.4 upgrade... When updating
vendor components using 'php -d extension=phar.so composer.phar
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
/var/www/html/wiki# find . -name php-parallel-lint
I recently upgraded our wiki from 1.29.1 to 1.35.2, and I enabled some new
extensions along the way. One of these was OATHAuth. Since the upgrade, I
have had about 5 different users complain that they were being prompted for
a 2FA code despite never having set it up. I did a bit of digging in the
database and found that none of the user IDs matched the IDs in the
oathauth_users table, and I'm currently under the impression that those
should be user IDs. We do use CentralAuth, as we have multiple wikis, but
neither the global nor local IDs matched up. I'm not sure if we've hit a
bug or if I'm misinterpreting what that field is supposed to represent, but
I was hoping someone could help point me in the right direction. I've had
to disable the extension because it was preventing legitimate logins, but
we would like to have it enabled if we can fix this.
A quick question. I work for a large corporation which uses Sharepoint to share files and pages (but does NOT yet use the Sharepoint Wiki feature). Instead of using Sharepoint's wiki, I want to install MediaWiki on the platform. Is this possible?
In other words, is it possible to access and maintain a MediaWiki site, through a Sharepoint page?
Hope the question makes sense, and apologies if this is a silly question. I know nothing much about Sharepoint, and only very recently heard of a Sharepoint Wiki.
Thanks for any comments or pointers.
I installed the latest release (1.2) of the DataTransfer Extension via Git.
I installed it on a 1.31 MW system per the INSTALL file. I went to
the Spezial:XMLview page as instructed. I selected one of the categories
and the main namespace and hit 'view XML'. After a few seconds (< 10) I got
a 500 page. I see the 500 error in the PHP logs (so this isn't a web
timeout). The PHP debug logs show only the following:
PHP Notice: Undefined index: 0505261 in
$IP/local/extensions/DataTransfer/includes/DT_PageStructure.php on line 139
($IP is the full installation path, redacted for security reasons)
We just upgraded from Mediawiki 1.36 to Mediawiki 1.36.1. Mediawiki
1.36 was OK. Mediawiki 1.36.1 has the problem. It looks like CSS
formatting no longer works.
Deprecated: Use of BaseTemplate::getFooterIcons was deprecated in
MediaWiki 1.35. [Called from VectorTemplate::getFooterData in
/var/www/html/w/skins/Vector/includes/VectorTemplate.php at line 223]
in /var/www/html/w/includes/debug/MWDebug.php on line 376
Tomorrow we will be issuing a security and maintenance release to all
supported branches of MediaWiki.
The new releases will be:
This will resolve 1 minor issue in MediaWiki core and also includes some
fixes previously committed to git, including minor security and hardening
patches along with bug fixes included for maintenance reasons.
We will make the fixes available in these respective release branches, and
also master. Tarballs will be available for the above mentioned point
releases as well.
A summary of some of the security fixes that have gone into non-bundled
MediaWiki extensions will also follow.
As a reminder, 1.31 (the old LTS) was due to become end of life (EOL) in
June 2021. 1.35 (the new LTS) is supported until September 2023. However,
to try and meet our LTS-LTS overlap commitments (1.35 was late due to
COVID), 1.31 will get best-efforts extra support until the end of September
2021. Practically, this will mean 1.31 is only tested on PHP 7.2, removing
the burden of testing on PHP 7.0 and 7.1 which both became EOL in 2019.
This will also mean 1.31 is eligible for one final security release in late
September 2021 before formally becoming EOL.
I recently discovered that the OOUI library, when an input is declared as
"required" (i.e., mandatory), accomplishes this by adding the "required"
parameter to the input, which is an HTML parameter that's part of HTML5.
When "required" is specified, the browser checks the input when the form
gets submitted, and, if it's blank, displays an error message and prevents
It's certainly convenient to be able to use HTML's "required", but I see
some weaknesses with this approach, compared to a built-in MediaWiki
- There is less i18n support. Some browsers have quite impressive language
support - Google Chrome seems to support around 150 languages - but none
have the comprehensiveness of MediaWiki.
- The error message is displayed in the language of the user's browser
settings, rather than in the language they have for the wiki. (Why the two
would be different, I don't know, but it's possible.)
- The display of the error message does not match the OOUI look-and-feel.
Any thoughts about all of these? Was the use of "required" a conscious
decision, or just a matter of convenience?
WikiWorks · MediaWiki Consulting · http://wikiworks.com
my skin uses the global parser in order to render some parts of the
navigation bar via templates (Parser::recursivePreprocess). This works
fine on all normal pages (and even some special ones like
Special:Version), but not on special pages like Special:AllPages.
Some debugging revealed that on Special:AllPages the global parser
object (\MediaWiki\MediaWikiServices::getInstance()->getParser()) is not
properly initialized. Member variables like mOptions and mTitle are null
which results in tons of NPEs.
Any idea why that is? Is that a bug or am I mis-using the parser?
We are having a little trouble with HitCounters and deprecated warnings.
We use extensions and skins from the GitHub mirror to easily pull in
changes on the REL1_36 branch. Tracking a branch like REL1_36 is a lot
easier than manually downloading a zip file with a non-relevant name,
like v4.3.5.zip (especially with 30+ extensions and skins).
HitCounter is stale. The author, @WikiForMen, said he updated the
extension to fix the warnings (see the Talk page). It appears the
changes have not trickled into the GitHub repo. Confer,
Would it be possible to update the HitCounters repo, please?
Thanks in advance.