Project:Support desk

Jump to: navigation, search

About this board

vde   Welcome to's Support desk, where you can ask MediaWiki questions!

There are also other places where to askCommunication: IRCCommunication#Chat, mailing listsMailing lists, Q&A, mwusers (unofficial forum) etc.

Before you post

Post a new question

  1. To help us answer your questions, please always indicate which versions you are using (reported by your wiki's Special:Version page):
    • MediaWiki
    • PHP
    • Database
  2. Please include the URL of your wiki unless you absolutely can't. It's often a lot easier for us to identify the source of the problem if we can look for ourselves.
  3. To start a new thread, click "Start a new topic". (talkcontribs)

Hi, an article was removed from Wikipedia and now it’s been put on and I’ve tried looking everywhere to contact them to remove it but I can’t find anything. Can someone please help?

Reply to "Remove an article from"
DZhukov (talkcontribs)

Top of the morning to you!

I ran into the following problem. When I try to install the MediaWiki version 1.29.2 and click set up the wiki link, I get the following error message:

PHP Fatal error: Uncaught Error: Call to a member function getIP() on null in C:\Websites\mediawiki\includes\user\User.php:2233 Stack trace: #0 C:\Websites\mediawiki\includes\session\SessionBackend.php(712): User->getName() #1 C:\Websites\mediawiki\includes\session\SessionBackend.php(596): MediaWiki\Session\SessionBackend->save() #2 [internal function]: MediaWiki\Session\SessionBackend->MediaWiki\Session\{closure}() #3 C:\Websites\mediawiki\vendor\wikimedia\scoped-callback\src\ScopedCallback.php(76): call_user_func_array(Object(Closure), Array) #4 C:\Websites\mediawiki\vendor\wikimedia\scoped-callback\src\ScopedCallback.php(56): Wikimedia\ScopedCallback->__destruct() #5 C:\Websites\mediawiki\includes\session\SessionManager.php(885): Wikimedia\ScopedCallback::consume(NULL) #6 C:\Websites\mediawiki\includes\session\SessionManager.php(195): MediaWiki\Session\SessionManager->getSessionFromInfo(Object(MediaWiki\Session\SessionInfo), Object(WebRequest)) #7 C:\Websites\mediawiki\includes\WebRequest.php(735): MediaWiki\Session\Sessio in C:\Websites\mediawiki\includes\user\User.php on line 2233 PHP Fatal error: Uncaught Error: Call to a member function getIP() on null in C:\Websites\mediawiki\includes\user\User.php:2233 Stack trace: #0 C:\Websites\mediawiki\includes\session\SessionBackend.php(712): User->getName() #1 C:\Websites\mediawiki\includes\session\SessionBackend.php(197): MediaWiki\Session\SessionBackend->save(true) #2 C:\Websites\mediawiki\includes\session\SessionManager.php(473): MediaWiki\Session\SessionBackend->shutdown() #3 [internal function]: MediaWiki\Session\SessionManager->shutdown() #4 {main} thrown in C:\Websites\mediawiki\includes\user\User.php on line 2233

I am new to the wiki and unfortunately not a PHP specialist.

The machine is of following means: Windows Server 2012. PHP 7.1.10. IIS 8.5.9600.16384. MySQL 5.7.20.

Please kindly help or point in the right direction of what is breaking and where to dig.

AKlapper (WMF) (talkcontribs)

Could be Topic:Tmt7736t4cc5yy7o ? Any further information in your web server's error log?

Reply to "Installation PHP Fatal error"

The "stub threshold" setting after using different skin.

C933103 (talkcontribs)

After I applied the Skin:Vector-DarkCSS skin, links to article with size less the stub threshold no longer change color. Is there any way to modify the css to alter the behavior?

MarkAHershberger (talkcontribs)

Could you point to a link like the one you are talking about?

C933103 (talkcontribs)
For example, at Chinese wikipedia, after setting the ULS to English, go to preference page at参数设置#mw-prefsection-rendering and then change the "Advanced options" "Threshold for stub link formatting" to 2000 bytes, and then go to which there are some example links. the stubs links should show different color. But after the aforementioned skin being applied, the link colors are no longer different.
Ciencia Al Poder (talkcontribs)

Stub links are marked with class="stub". I imagine Vector-DarkCSS hasn't defined it, or it has set the same color to a normal link

Current style is:

a.stub {
    color: #723;
C933103 (talkcontribs)


Ycsoft (talkcontribs)

Hello I currently have mediawiki v1.25.3. I tried to install v1.29.1, but I went back because the connection of an account does not work anymore I can not use the "MaintenanceShell" extension I installed it correctly It is displayed in the "special: version" page but nothing is displayed in the "special" page I configured localSettings.php like this: $ wgGroupPermissions ['administrators'] ['MaintenanceShell'] = true; require_once "$ IP / extensions / MaintenanceShell / MaintenanceShell.php"; an idea ? Greetings (My initial goal is to delete spammed pages (archived or revised))

星耀晨曦 (talkcontribs)

The config should be $ wgGroupPermissions ['administrators'] ['maintenanceshell'] = true, MaintenanceShell must be lowercase. See Extension:MaintenanceShell. (talkcontribs)

it does not work either I also tried with $ wgGroupPermissions ['sysop'] ['maintenanceshell'] = true; or $ wgGroupPermissions ['*'] ['maintenanceshell'] = true; nothing works

Reply to "MaintenanceShell"

problem sessions after migration 1.25.3 to 1.29.1

Ycsoft (talkcontribs)

the message "Your login session seems to be having problems, this action has been canceled to prevent session hijacking, please click on" Back ", reload the page from where you are coming, and try again. each connection attempt ... I still have access to FTP I still have access to the database via '' my ISP is '' my site is '' do you have a solution to offer me?

AhmadF.Cheema (talkcontribs)

See Topic:T7irqyk4rhfy3ohk. (talkcontribs)

Hello, I changed $ wgMainCacheType = CACHE_NONE; in $ wgMainCacheType = CACHE_ANYTHING; I erased the navigation data of the chromes that did not change anything: I still have the same problem ... Note the other variables of localsettings.php related to 'cache' $ wgMainCacheType = CACHE_ANYTHING; $ wgMemCachedServers = array (); $ wgCacheEpoch = max ($ wgCacheEpoch, gmdate ('YmdHis', @filemtime (__FILE__))); Greetings Appendix for info: result of 'wiki \ mw-config:' Environmental Checks Basic checks will now be made to see if this environment is suitable for installing MediaWiki. Remember to include this information if you are looking for help on how to complete the installation. PHP 5.6.8 is installed. Warning: Can not find APCu, XCache or WinCache. Object caching is not enabled. GNU diff3 not found The integrated GD graphics library has been found. Image miniaturization will be enabled if you enable file upload. Git version control software not found. Using the server name "". Using the server URL "". Warning: The PECL intl extension is not available for Unicode normalization, back to the slow version implemented in PHP. If your website will be very busy, you should read this: Unicode normalization (in English). The environment has been verified. You can install MediaWiki.

AhmadF.Cheema (talkcontribs)

Did you also try setting, $wgSessionCacheType = CACHE_DB; ? (talkcontribs)

yes, I tried with CACHE_DB: same result

Ycsoft (talkcontribs)

for information, I'm on a hosted server (

Ycsoft (talkcontribs)

hello, would my problem be related to the message "Can not find APCu, XCache or WinCache" posted by wiki / mw-config?

星耀晨曦 (talkcontribs)

Caching is not necessary, but it can make your wiki faster.

If you do not enable any caching, the caching-related config should be the default.

Ycsoft (talkcontribs)

Well, I ended up dropping: I came back in 1.25.3 and it works again ... I seem to have understood that connection problems had appeared in version 1.29.x (see So I'll wait a bit to see if a fix will be written

Reply to "problem sessions after migration 1.25.3 to 1.29.1"

Is it possible to find broken anchor links?

4 (talkcontribs)

Probably a stupid question answered million times, but I can't find an answer. MediaWiki can track missing pages and report those with Special:WantedPages. I'm not sure it's possible, but can MediaWiki report broken anchors? Say, I have the Foo page that refers the Bar page like this: <nowiki>[[Bar#Name]]</nowiki>. Let's assume the Bar page lacks this section, but Special:WantedPages won't report this link as broken because the Bar page exists. Is there any way to find all broken anchors? Thanks in advance!

Osnard (talkcontribs)

As far as I know there is no way to archive that. This could be a job for a bot. But I don't know if there is already one that does such things.

Ciencia Al Poder (talkcontribs)

It has been requested already at task T18561 but don't expect it to be implemented in the near future. (talkcontribs)

@Ciencia Al Poder Oh, sad news. :( Anyway, thank you for the clarification!

Reply to "Is it possible to find broken anchor links?"
Waanders (talkcontribs)

One of our templates seems corrupted. We can't edit the page, even not show (yes, it exists) and so on. All this results in a time-out. Now we try to import a back-up version but also Special:Import gives a time-out.

How do I fix this?

Malyacko (talkcontribs)

If your webserver software (not MediaWiki) shows a timeout, please check the logs of your webserver software for more information about the reasons. Also see How to debug.

Waanders (talkcontribs)

I think it's a MediaWiki problem.

I'v added this to LocalSettings.php:

error_reporting( -1 );

ini_set( 'display_errors', 1 );

$wgShowExceptionDetails = true;

$wgShowSQLErrors = true;

$wgShowDBErrorBacktrace = true;

$wgDebugComments = true;

$wgLogQueries = true;

$wgDebugDumpSql = true;

$wgDevelopmentWarnings  = true;

$wgDebugProfiling = true;

$wgDebugTimestamps = true;

$wgResourceLoaderDebug  = true;

Now MW gives this error: "Fatal error: Maximum execution time of 30 seconds exceeded in /home/hz01/mediawiki/core/includes/debug/MWDebug.php on line 369".

Malyacko (talkcontribs)

You could set the maximum execution time to a ridiculously high value to check if it ever finishes, or never. Which MediaWiki version is this about?

Reply to "How to fix a corrupted page?" (talkcontribs)

Warning: md5_file(C:\inetpub\wwwroot/../wiki.png): failed to open stream: No such file or directory in C:\inetpub\wwwroot\includes\OutputPage.php on line 3802

Warning: OutputPage::transformFilePath: Failed to hash C:\inetpub\wwwroot/../wiki.png [Called from OutputPage::transformFilePath in C:\inetpub\wwwroot\includes\OutputPage.php at line 3804] in C:\inetpub\wwwroot\includes\debug\MWDebug.php on line 309

Osnard (talkcontribs)

Can you please provide additional information about those warnings? Like used MediaWiki and PHP version?

Ciencia Al Poder (talkcontribs)

Have you checked if "C:\inetpub\wwwroot/../wiki.png" exists on your wiki? Looks like you've some wrongly configured path in LocalSettings.php

Reply to "Warning"
MarcoAurelio (talkcontribs)

When running the conversion script it required me to have a LocalSettings.php file. I solved the issue creating an empty LocalSettings.php file and that seemed to work just fine. Question is if the LocalSettings.php file should have really had anything or if its contents affect how the migration is done. Thanks.

Osnard (talkcontribs)

The convertExtensionToRegistration.php does not rely on any particular information in LocalSettings.php. But may need a functional MediaWiki installation. Therefore the absence of the main configuration file can be a problem.

Ciencia Al Poder (talkcontribs)

I think LocalSettings.php shouldn't be a requirement for this script and is probably caused by it inheriting the Maintenance class. This is solved in the install.php script, for example, that does not require it (and in fact will fail if present)

Reply to "convertExtensionToRegistration.php"

Webpage stopped working while in the updating Joomla! version

MarcelGuate (talkcontribs)

Dear Gentlemen:

I urgently need your help.   My webpage ( simply stopped working.   Description of facts is as follows:

▪ We obtained our dominions from GoDaddy

▪ I am currently using Joomla! 3.6.5

▪ We use Joomshaper's Helix 3 Template

▪ The site has been up and working for almost 3 years

▪ Yesterday evening I was trying to automatically update this Joomla! version

○ The backup stage had just finished

○ When the process started to update the Joomla! version, I was kicked out of the process

○ When I intended to go back into the updating process, I simply couldn't.   An http 500 error appeared instead:

This page isn’t working is currently unable to handle this request.


○ I contacted GoDaddy to try to fix the problem, after almost an hour of working and trying, they told me that they could not fix the problem, because it was NOT in their hands and they suggested I contact Joomla! or Joomshaper to help me fix this problem

○ When I tried to find what the problem was, this is what I found:

[22-Nov-2017 06:31:29 UTC] PHP Warning:  require_once(/home/nuevacuenta/public_html/libraries/joomla/document/html/renderer/head.php): failed to open stream: No such file or directory in /home/nuevacuenta/public_html/templates/shaper_helix3/error.php on line 28

[22-Nov-2017 06:31:29 UTC] PHP Fatal error:  require_once(): Failed opening required '/home/nuevacuenta/public_html/libraries/joomla/document/html/renderer/head.php' (include_path='.:/opt/alt/php56/usr/share/pear:/opt/alt/php56/usr/share/php') in /home/nuevacuenta/public_html/templates/shaper_helix3/error.php on line 28

Could you please help me get the website going again?   

Thank You very much!

Marcel Roehrs

+502 5819-8166

Osnard (talkcontribs)

You may be on the wrong HelpDesk. This one is about the MediaWiki Software, not Joomla. You may want to write to

Reply to "Webpage stopped working while in the updating Joomla! version"