Project:Support desk

Welcome to the MediaWiki Support desk, where you can ask MediaWiki questions!

(Read this message in a different language)

See also

• Other places to ask for help

Before you post

• Check the basic How does MediaWiki work? guide.
• Check the FAQ and Errors and symptoms .
• If your question is about a specific feature, check the relevant technical manual , end-user help or extension page and consider asking on its talk page .
• For issues about the mediawiki.org website, report to Village Pump instead.
• For trying out wiki editing, use the Sandbox instead.

Post a new question

1. To help us answer your questions, please indicate which versions you are using, as found on your wiki's Special:Version page:
   • MediaWiki version
   • PHP version
   • Database type and version
2. Please include the web address (URL) to your wiki if possible. It's often easier for us to identify the source of the problem if we can see the error directly.
3. To start a new thread, click "Start a new topic".

Hi all,

I have two related questions:

My images are being stored in the default folder on mediawiki, and I'm deployed on kubernetes and leveraging a PVC. Is there a way to migrate those images to AWS S3 without causing any breaking changes

or

Is there a way to utilize a second PVC for only images?

According to Manual:Database.php#Functions, we use the following code (extract):

$dbr = wfGetDB( DB_REPLICA );
$res = $dbr->query( ... some DB Query ... );
.... $dbr->numRows( $res ) ....

But we get:

Error: Call to undefined method Wikimedia\Rdbms\DatabaseMysqli::numRows()

Backtrace:

from /var/www/test/mediawiki/includes/libs/rdbms/database/DBConnRef.php(103)
#0 /var/www/test/mediawiki/extensions/PPcheckRedirects/SpecialPPcheckRedirects.class.php(118): Wikimedia\Rdbms\DBConnRef->__call()
#1 /var/www/test/mediawiki/includes/specialpage/SpecialPage.php(701): SpecialPPcheckRedirects->execute()
#2 /var/www/test/mediawiki/includes/specialpage/SpecialPageFactory.php(1428): SpecialPage->run()
#3 /var/www/test/mediawiki/includes/MediaWiki.php(316): MediaWiki\SpecialPage\SpecialPageFactory->executePath()
#4 /var/www/test/mediawiki/includes/MediaWiki.php(904): MediaWiki->performRequest()
#5 /var/www/test/mediawiki/includes/MediaWiki.php(562): MediaWiki->main()
#6 /var/www/test/mediawiki/index.php(50): MediaWiki->run()
#7 /var/www/test/mediawiki/index.php(46): wfIndexMain()
#8 {main}

Prior to 1.39, the above code worked. Could this be an installation problem or has there been an undocumented redesign of the db access objects?

per the Release-notes file included with 1.39, numRows was removed

Use $res->numRows() instead.

And in general, you will want to rewrite it to use the new query builders Manual:Database access#SelectQueryBuilder going forward.

$res->numRows, that was the piece of information I have been missing and wasn't able to find. Just to be sure: same problem with $dbr->freeResult, but there's no replacement ... right?

Works fine now, thank you.

@TheDJ no, I really don't want to. Non-voluntary. These are the sort of "improvements" that make Mediawiki worse, not better. I know someday I must but that's nothing I am looking forward to. I've seen many "closed circles" of software developers drifting away to outer space, your companions are en route. Honestly: we only stick to Mediawiki because there's no alternative.

freeResult() basically didn't do anything, so i wouldn't worry about it. Resources will automatically be freed when the variable falls out of scope.

$res does have a ->free() method that is equivalent, its just kind of pointless.

See https://doc.wikimedia.org/mediawiki-core/master/php/interfaceWikimedia_1_1Rdbms_1_1IResultWrapper.html#a7af97691969ee08d6f19e333a613b204 for list of methods of $res

Manual:FAQ#How_can_I_hide_the_table_of_contents.3F

#toc ul{
    display:none;
}

I don't mean to get rid of it. I would refer that TOCs were displayed hidden with the show link being used to expand them. I've poked around through the manual and faq, but I haven't found anything about that. I guess another way to word this (which I've also searched for) is to have TOCs displayed collapsed by default, and opened by the viewer when desired. I do not want to use __NOTOC__. I want the TOC to be available, just not taking up the entire page before the article begins.

I could swear I saw this at Wikipedia somewhere, but I can't seem to find it.

I don’t have a complete answer but there is Manual:Table of contents where possibly there is a link to your desired feature. For Wikipedia, when you close the TOC, it is saved (in a cookie) and the next TOCs are then closed (well, it’s JavaScript, so it is closing when you open the page); when you re-open the TOC, it will then appear opened, etc.

Thanks, @Seb35. I was not aware of the cookie setting. That would explain why I've seen it collapsed before. I looked through the Manual and the FAQ several times and didn't find the answer. I also found a template Template:TOC hidden, but it has no documentation, and the template code is beyond confusing.

The cookie info is useful.

#toc ul{

display.none;

}

Will permanently hide the TOC. That is NOT what I want.

Nope, the CSS won't permanently hide the table of contents, a user can still click the show / hide link to show it.

I put that code in MediaWiki:Common.css, and it didn't do anything. I put it in my personal common.css, and it didn't do anything. Perhaps I'm missing something?

Seb35's suggestion works though. If I close it, the next time I open the page, the TOC is closed.

I tried the CSS 197 gave, it works mostly but the word 'show' (or 'hide') is not always consistent with the real state.

If it does not work after you modified MediaWiki:Common.css, perhaps you need to force a hard refresh of the browser (Ctrl+F5 or Ctrl+R depending on the browser).

That's probably true, but I like your fix better anyway. If you want it hidden when you open a page, hide it before you leave.

Apologies if this isn't the correct place to mention this, but it appears to be. As https://en.wikipedia.org/w/index.php?title=List_of_NATO_country_codes&diff=next&oldid=1195025114 demonstrates, sometimes people use https://en.wikipedia.org/w/index.php?title=Help:Section&oldid=1194575476#Hiding_the_TOC on articles which I'd like to have a TOC on. Does anyone know how to always have the TOC render irrespective of NOTOC?

When running findMissingFiles.php, I get a few files for which there is a database record but no image in the mediawiki/images directory. But what to do next? What I am missing is some documentation or hint of how to get rid of those database entries.

Some of our own extensions are based on existing special pages. According to Mediawiki programming gudelines, the code looks like this:

class WantedPagesNeo extends WantedPagesPage {

        function __construct( $name = 'WantedPages_(PR_Neo)' ) {
                parent::__construct( $name );
        }

...

Prior to 1.39, this used to work but now it crashes:

[739319141d78cf5548ef724f] /wiki/Spezial:Spezialseiten TypeError: Argument 1 passed to WantedPagesPage::__construct() must implement interface Wikimedia\Rdbms\ILoadBalancer, string given, called in /var/www/test/mediawiki/extensions/PPaddons/src/SpecialPages/WantedPagesNeo.php on line 26

Backtrace:

from /var/www/test/mediawiki/includes/specials/SpecialWantedpages.php(39)
#0 /var/www/test/mediawiki/extensions/PPaddons/src/SpecialPages/WantedPagesNeo.php(26): WantedPagesPage->__construct()
#1 /var/www/test/mediawiki/vendor/wikimedia/object-factory/src/ObjectFactory.php(247): PP\SpecialPages\WantedPagesNeo->__construct()
#2 /var/www/test/mediawiki/vendor/wikimedia/object-factory/src/ObjectFactory.php(152): Wikimedia\ObjectFactory\ObjectFactory::getObjectFromSpec()
#3 /var/www/test/mediawiki/includes/specialpage/SpecialPageFactory.php(1279): Wikimedia\ObjectFactory\ObjectFactory->createObject()
#4 /var/www/test/mediawiki/includes/specialpage/SpecialPageFactory.php(1314): MediaWiki\SpecialPage\SpecialPageFactory->getPage()
#5 /var/www/test/mediawiki/includes/specials/SpecialSpecialpages.php(53): MediaWiki\SpecialPage\SpecialPageFactory->getUsablePages()
#6 /var/www/test/mediawiki/includes/specials/SpecialSpecialpages.php(42): SpecialSpecialpages->getPageGroups()
#7 /var/www/test/mediawiki/includes/specialpage/SpecialPage.php(701): SpecialSpecialpages->execute()
#8 /var/www/test/mediawiki/includes/specialpage/SpecialPageFactory.php(1428): SpecialPage->run()
#9 /var/www/test/mediawiki/includes/MediaWiki.php(316): MediaWiki\SpecialPage\SpecialPageFactory->executePath()
#10 /var/www/test/mediawiki/includes/MediaWiki.php(904): MediaWiki->performRequest()
#11 /var/www/test/mediawiki/includes/MediaWiki.php(562): MediaWiki->main()
#12 /var/www/test/mediawiki/index.php(50): MediaWiki->run()
#13 /var/www/test/mediawiki/index.php(46): wfIndexMain()
#14 {main}

What does it mean and where can I find documentation on how to correct it?

This is a Dependency Injection (DI) related issue.

If you look at the source code of SpecialWantedpages.php as of REL1_39, you'll notice that the constructor's function signature has changed. These kind of changes are all over the place and will be in the future as well. Honestly, it's a mess.

Anyway, try changing your code to something like this, maybe:

	function __construct() {
		WantedQueryPage::__construct( 'WantedPages_(PR_Neo)' );
	}

This may or may not work (also, I should note that the use of parentheses in a special page name like that is quite unusual). Having access to the actual code would aid in debugging.

Someone who understand's MW's DI and its current state can probably chime in and explain it more and better.

You need to pass the correct arguments to parent::__construct(). This can change between versions.

You can adjust your special page registration in extension.json to match what WantedQuery does so it gets the same arguments, which you could just pass on. Alternatively you can use the methods of MediaWiki\MediaWikiServices::getInstance() to get the relavent objects.

> According to Mediawiki programming gudelines, the code looks like this

When you say guidelines, is there a specific page you are referencing? I'm asking because if there is incorrect information somewhere i would like to correct it.

Seems the signature was accidentally/deliberately changed/broken in REL1_36 https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/ab4d80512c2d5c6d028e885fd66c85f2e6096d14%5E%21/#F1. Probably because people assumed it was unused.

The documentation talks about a special page implementation subclassing the generic SpecialPage class, it is not a general example on how to do that for every single imaginable special page class. The best way to implement this is to, after calling the parent constructor, set $this->mName directly. This is how core classes like SpecialPrefixIndex.php do it.

I am facing this problem and I have tried opening php.ini file and deleting ; this from extension I am using Xampp local host for all process can somone help to get out fro this.

MediaWiki 1.41 internal error

Installing some PHP extensions is required.

Required components

You are missing a required extension to PHP that MediaWiki requires to run. Please install:

• intl (more information)

You need to install the PHP intl extension. I am not sure how to rephrase the error message to make it clearer, please elaborate what is unclear.

The problem as I has mentioned is the exact problem it says for installation of php so how could I do it.

What happened when you deleted the ; ?

Did you restart xampp? You have to restart for changes to take effect

I have restarted xamppp but it's not working.

We have a new server where we are installing MediaWiki version 1.41.1.  We also have an older version 1.34.  We need to bring the data from the old version to the new version. What would be the best method for this?  Would exporting the pages from the old version & importing them to the new version be a good solution?

Thanks. Problem solved.

After moving our site to another server, a problem occurred. If a page of the site has 'background' code, it is now not possible to edit that page. This error occurs:

'403 Forbidden Access to this resource on the server is denied!'

https://sheki.org/wiki/index.php?title=%C5%9Eablon:15_aprel&action=submit

But after deleting the "background" code on that page, everything is fine. How to solve this problem?

Judging by some quick googling, it sounds like a problem with mod_security (no surprise there...). Try disabling it or if you don't have the access to do that, contact your hosting company to do so.

Thanks. Problem solved.

The Wiki as I have already talked about Shout Wiki I actually exactly not know that the founder of wiki should update wiki version or it can be done with MW Shout Wiki was just emerging wiki host but due to their own founder and staffs became inactive so I would know what should be done now.

You would have to take that up with ShoutWiki admins.

There is no single admin active or Stewards or Staff none is active that's why I am asking here for a way.

We have no control over shoutwiki.

ShoutWiki is very much around and we're not going anywhere. If you have questions about the upgrade schedule, please post those on the ShoutWiki Community Forum. Thanks!

User's mistake, wrong version of ParserFunctions extension.

Done. Migration failed for 9 row(s).

Very cool error message. Everything is absolutely clear at the first glance.

scnr

[error] [ba7e546ea33fc2ecb983341e] /wiki/Hauptseite   PHP Unknown error: Cannot access non-public property Parser::$mOutp

ut

#0 [internal function]: MWExceptionHandler::handleError()

#1 /var/www/test/mediawiki/includes/debug/DeprecationHelper.php(202): trigger_error()

#2 /var/www/test/mediawiki/extensions/ParserFunctions/includes/ParserFunctions.php(388): Parser->__get()

#3 /var/www/test/mediawiki/extensions/ParserFunctions/includes/ParserFunctions.php(414): MediaWiki\Extensions\ParserFunct

ions\ParserFunctions::ifexistInternal()

#4 /var/www/test/mediawiki/includes/parser/Parser.php(3437): MediaWiki\Extensions\ParserFunctions\ParserFunctions::ifexis

t()

#5 /var/www/test/mediawiki/includes/parser/Parser.php(3122): Parser->callParserFunction()

#6 /var/www/test/mediawiki/includes/parser/PPFrame_Hash.php(275): Parser->braceSubstitution()

#7 /var/www/test/mediawiki/includes/parser/Parser.php(3313): PPFrame_Hash->expand()

#8 /var/www/test/mediawiki/includes/parser/PPFrame_Hash.php(275): Parser->braceSubstitution()

#9 /var/www/test/mediawiki/includes/parser/Parser.php(3030): PPFrame_Hash->expand()

#10 /var/www/test/mediawiki/includes/parser/PPFrame_Hash.php(275): Parser->braceSubstitution()

#11 /var/www/test/mediawiki/includes/parser/Parser.php(3313): PPFrame_Hash->expand()

#12 /var/www/test/mediawiki/includes/parser/PPFrame_Hash.php(275): Parser->braceSubstitution()

#13 /var/www/test/mediawiki/includes/parser/PPTemplateFrame_Hash.php(97): PPFrame_Hash->expand()

#14 /var/www/test/mediawiki/includes/parser/Parser.php(3310): PPTemplateFrame_Hash->cachedExpand()

#15 /var/www/test/mediawiki/includes/parser/PPFrame_Hash.php(275): Parser->braceSubstitution()

#16 /var/www/test/mediawiki/includes/parser/PPTemplateFrame_Hash.php(97): PPFrame_Hash->expand()

#17 /var/www/test/mediawiki/includes/parser/Parser.php(3310): PPTemplateFrame_Hash->cachedExpand()

#18 /var/www/test/mediawiki/includes/parser/PPFrame_Hash.php(275): Parser->braceSubstitution()

#19 /var/www/test/mediawiki/includes/parser/Parser.php(2951): PPFrame_Hash->expand()

#20 /var/www/test/mediawiki/includes/parser/Parser.php(1609): Parser->replaceVariables()

#21 /var/www/test/mediawiki/includes/parser/Parser.php(723): Parser->internalParse()

#22 /var/www/test/mediawiki/includes/content/WikitextContentHandler.php(301): Parser->parse()

#23 /var/www/test/mediawiki/includes/content/ContentHandler.php(1721): WikitextContentHandler->fillParserOutput()

#24 /var/www/test/mediawiki/includes/content/Renderer/ContentRenderer.php(47): ContentHandler->getParserOutput()

#25 /var/www/test/mediawiki/includes/Revision/RenderedRevision.php(266): MediaWiki\Content\Renderer\ContentRenderer->getParserOutput()

#26 /var/www/test/mediawiki/includes/Revision/RenderedRevision.php(237): MediaWiki\Revision\RenderedRevision->getSlotParserOutputUncached()

#27 /var/www/test/mediawiki/includes/Revision/RevisionRenderer.php(221): MediaWiki\Revision\RenderedRevision->getSlotParserOutput()

#28 /var/www/test/mediawiki/includes/Revision/RevisionRenderer.php(158): MediaWiki\Revision\RevisionRenderer->combineSlotOutput()

#29 [internal function]: MediaWiki\Revision\RevisionRenderer->MediaWiki\Revision\{closure}()

#30 /var/www/test/mediawiki/includes/Revision/RenderedRevision.php(199): call_user_func()

#31 /var/www/test/mediawiki/includes/poolcounter/PoolWorkArticleView.php(91): MediaWiki\Revision\RenderedRevision->getRevisionParserOutput()

#32 /var/www/test/mediawiki/includes/poolcounter/PoolWorkArticleViewCurrent.php(97): PoolWorkArticleView->renderRevision()

#33 /var/www/test/mediawiki/includes/poolcounter/PoolCounterWork.php(162): PoolWorkArticleViewCurrent->doWork()

#34 /var/www/test/mediawiki/includes/page/ParserOutputAccess.php(299): PoolCounterWork->execute()

#35 /var/www/test/mediawiki/includes/page/Article.php(714): MediaWiki\Page\ParserOutputAccess->getParserOutput()

#36 /var/www/test/mediawiki/includes/page/Article.php(528): Article->generateContentOutput()

#37 /var/www/test/mediawiki/includes/actions/ViewAction.php(78): Article->view()

#38 /var/www/test/mediawiki/includes/MediaWiki.php(542): ViewAction->show()

#39 /var/www/test/mediawiki/includes/MediaWiki.php(322): MediaWiki->performAction()

#40 /var/www/test/mediawiki/includes/MediaWiki.php(904): MediaWiki->performRequest()

#41 /var/www/test/mediawiki/includes/MediaWiki.php(562): MediaWiki->main()

#42 /var/www/test/mediawiki/index.php(50): MediaWiki->run()

#43 /var/www/test/mediawiki/index.php(46): wfIndexMain()

#44 {main}

[exception] [ba7e546ea33fc2ecb983341e] /wiki/Hauptseite   PHP Fatal Error from line 202 of /var/www/test/mediawiki/includes/debug/DeprecationHelper.php: Cannot access non-public property Parser::$mOutput

#0 [internal function]: MWExceptionHandler::handleFatalError()

#1 {main}

[session] Saving all sessions on shutdown

Nice backtrace but it does not show what's the problem. How can i find out which component is wrong?

Do you have the correct version of Extension:ParserFunctions for your version of MediaWiki.

Huh ...! No it's been the wrong version. Sorry for that. I thought ParserFunctions is part of the Mediawiki installation bundle.

Solved, thank you very much!

It normally is, but there are different bundles you can get some of which don't include extensions.