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.
The 2021 Board of Trustees election is coming soon. Candidates from the
community are needed to fill the available seats.
The Wikimedia Foundation Board of Trustees oversees the Wikimedia
Foundation's operations. Community trustees and appointed trustees make up
the Board of Trustees. Each trustee serves a three-year term. The Wikimedia
community has the opportunity to vote for community trustees.
Wikimedia contributors will vote to fill four seats on the Board in 2021.
This is an opportunity to improve the Board's representation, diversity,
and expertise as a team.
For potential candidates:
- *Traits:* Wikimedia is a global movement and seeks candidates from the
broader community. Candidates should think about what experiences and
perspectives they will bring to the Board. Ideal candidates align with the
Wikimedia mission and are thoughtful, respectful, and community-oriented.
The Board would like to find perspectives and voices that are
under-represented and essential for our movement. They should bring what
Wikimedia needs from a new Trustee.
- *Commitment: *Trustees serve a three-year term and can serve up to
three consecutive terms. The time commitment is about 150 hours per year,
excluding travel. This time is not evenly spread throughout the year. The
time is concentrated around meetings. The expectation is that Trustees
serve on at least one of the Board’s committees.
- *Requirements*: English is the language of business for the Board.
Candidates need a basic understanding of English, but support and training
are part of onboarding. Candidate applications will be translated into
several languages to reach a broad audience of voters.
- *Apply*: Candidates from all projects and communities who meet the
needs of Wikimedia Trustee are welcome. If you know someone who could be a
good trustee, encourage them to run for election. Candidates can find
information and submit their nomination on the Apply to be a Candidate page.
- *Resources*: A toolkit has been developed for community members who
are considering submitting their candidacy for the Wikimedia Foundation
Board of Trustees, and who want to better understand what to expect and how
to prepare for the role.
Thank you for your support,
The Wikimedia Foundation Board of Trustees
Krishna Chaitanya Velaga (he/him)
Board Governance Facilitator, Wikimedia Foundation