Project:Support desk

Jump to: navigation, search

About this board

Edit description
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 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".
By clicking "Add topic", you agree to our Terms of Use and agree to irrevocably release your text under the CC BY-SA 3.0 License and GFDL
Siams PS (talkcontribs)

Is it preferred to add additional rights defined in an extension via extension.json or via $wgAvailableRights? The extension.json mentions the $wgAvailableRights variable, but doesn't explicitly state which method would be better.

In fact, a lot of the things defined in extension.json have $wg variable equivalents - is there a preferred method, or is it up to developer discretion as long as it's consistent?

Reply to "extension.json or $wgAvailableRights?"
Ciciban (talkcontribs)

Dear all,

Is there a way to share text content between wikis, similar to sharing files via wikimedia commons?

Thank you in advance for your answers.

Yours, Ciciban (talk) 13:37, 16 August 2017 (UTC)

AhmadF.Cheema (talkcontribs)

See Manual:$wgEnableScaryTranscluding.

As far as I know, this will transclude the entire page and therefore cannot be used to transclude particular sections of an article.

Reply to "Sharing content between wikis"

Logo and favicon not showing despite viewable using direct URL

Meatshell (talkcontribs)

I'm trying to setup our wiki here:

This is the direct URL to the logo:

I tried to setup the logo using:

$wgLogo = '';


$wgLogo = '/images/6/6c/Bklogo.png';

But both didn't work.

The same goes for favicon, here is its direct URL:

I tried setting $wgFavicon similarly to the logo, but both of them didn't work.

AhmadF.Cheema (talkcontribs)

I tested with the absolute URL for the logo, it appeared to be working on my end.

Can you confirm that you had cleared the cache? Additionally, see if your browser developer tools (F12) give any errors under its Console tab.

Meatshell (talkcontribs)

Sorry for the late reply.

I cleared the browsing cache but it didn't work. The logo and favicon are still not shown.

There is no error shown in the console tab too.

2003:72:6D1A:4E00:2D3C:AB0C:626:585 (talkcontribs)

When I view the wiki pages, I do not see logo and favicon.

Your wiki pages contain this URL:

The "/index.php" in them is wrong. It should not be there. This points to a problem with the different path variables. I think that somehow they are not set correctly.

2003:72:6D1A:4E00:2D3C:AB0C:626:585 (talkcontribs)

And you somehow have a link element on top of all your wiki pages, showing a path to the favicon. I don't know how on earth you got that there, but you should remove this. It is just invalid.

Meatshell (talkcontribs)

Thank you for your inputs.

I forgot to remove that favicon link.

Anyway, here are the relevant variables:

$wgScriptPath = '';

$wgStylePath = '{$wgScriptPath}/style';

$wgLogo = '';

$wgFavicon = './favicon.ico';

Document root is in /var/www/html/

Ciencia Al Poder (talkcontribs)

The wiki uses this rule for the logo: .mw-wiki-logo { background-image: url(; }

which is very strange because api returns the correct URL

About the favicon, it should be defined with an absolute URL (talkcontribs)

You obviously had modified the MediaWiki source code, e.g. to get the link to the favicon displayed on top of very page. Do you maybe still have other modifications in the code, which you are using? Maybe it is best to override all the files, which are coming from the MediaWiki tarball with the original file again, to be sure there are no modifications left.

Also note that $wgScriptPath should be a path in the file system. A URL does not work there. Setting it to "/aclab" should help.

If you are not planning to use your own skin directory, you can just remove the line with $wgStylePath.

$wgLogo depend on $wgScriptPath. In you case it should be "{$wgScriptPath}/images/6/6c/Bklogo.png".

$wgFavicon finally should just be "/favicon.ico".

All this leads to this configuration:

$wgScriptPath = '/aclab';

# This line can be removed: $wgStylePath = '{$wgScriptPath}/style';

$wgLogo = "{$wgScriptPath}/images/6/6c/Bklogo.png";

$wgFavicon = '/favicon.ico';

Reply to "Logo and favicon not showing despite viewable using direct URL"

InvalidArgumentException displayed on fresh install.

2 (talkcontribs)


OS: Win 10 Pro

PHP: 5.6.16 (It is using a slightly custom php.ini however this same ini file has been used on a lot of different programs)

IIS 10

DB: MySQL 5.7

MediaWiki: 1.29.0

I have just 'finished' the installation of MediaWiki, to migrate my companies current wiki estate to MediaWiki. Having gone through the configuration page, and placed the LocalSettings.php file in the same location as the index.php file when i then try and browse to my newly created wiki I am presented with the following:

[144bddaaa47193689db6e474] 2017-08-16 11:21:27: Fatal exception of type "InvalidArgumentException"

The only non default step I took in the configuration was adding the cite extension.

I am not really sure how to trouble shoot this.

Things I have tried:

error_reporting( E_ALL );

ini_set( 'display_errors', 1 );

into the localsettings.php having read that in the FAQ under nothing displayed.

No error logs in my php.log.



星耀晨曦 (talkcontribs)

You can try to remove all extensions in LocalSettings.php, and then see if the software is running properly. For more information on debugging, see also Manual:How to debug.

Reply to "InvalidArgumentException displayed on fresh install."
星耀晨曦 (talkcontribs)

My wiki's short url is //domin/wiki/page.

When I visit Special:Notifications,that is //domin/wiki/Special:Notifications, the page prompts me "No such special page". After that, I visit it with another url(//domin/w/index.php?title=Special:Notifications), the page can be displayed properly.

Once, I thought it was web server url rewriting problem. However, most special pages are still accessible. So, I think the mediawiki have a bit of a problem.

Ciencia Al Poder (talkcontribs)

Usually, for the server, there should be no difference between both URLs, because the rewrite takes care to map first URL to second.

Try to find what exact URL is receiving PHP when accessing //domin/wiki/Special:Notifications. You can view it if you enable a debug log.

星耀晨曦 (talkcontribs)

I checked the web server log, I think //domin/wiki/Special:Notifications is rewritten to /w/index.php title=wiki/Special:++++++. This is not normal!

I think there is a problem with the rewrite rules of the web server. The pattern of rewriting rules is ^(wiki/[^/]+)/?$.

Ciencia Al Poder (talkcontribs)

Are you using apache, nginx or other server software? Can you post the complete rewrite rules you're using? The rewrites are inside an .htaccess?

星耀晨曦 (talkcontribs)

I am using IIS. I refer to this to set the rewrite rules.

Since I found the problem, I tried various rewrite rules, the short URL builder tool and import from .htaccess file(e.g the rules of the apache). But still can not access it normally.

Reply to "Some questions about short url"

Visualeditor open api help page instead of edit article

Francod85 (talkcontribs)

Hi, I have just set up VisualEditor with parsoid for my mediawiki, but when I want to edit an article open the mediawiki api help page instead of edit the article.

PokestarFan (talkcontribs)

I would recommend reporting this to the visualeditor feedback.

Ciencia Al Poder (talkcontribs)

Maybe your webserver is doing a redirect from non-www to www domain, or from http to https, and the request is losing the POST data sent to the server, resulting in the api help page (the default when you request api.php without parameters). Check in the access logs of the webserver if that's the case. You may need to adjust the api URL in parsoid configuration so it points to the correct URL.

Reply to "Visualeditor open api help page instead of edit article" (talkcontribs)

I have forgotten my username and have attempted to reset the password 3 times via email however, it is not showing up in my sent folder or inbox.

2003:72:6D1A:4E00:2D3C:AB0C:626:585 (talkcontribs)

You can find your username in the page history of any page, which you have edited. That way you should be able to at least find the username again.

Reception123 (talkcontribs)

Even easier, you can check the user creation log.

There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Go back to the previous page, reload that page and then try again.

2 (talkcontribs)

I have just set up MediaWiki (1.29.0) on an AS400 IBM i machine. Though I can navigate the site, as well as create/edit pages, I cannot log in or create a new account. Every attempt to do so gives me "There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Go back to the previous page, reload that page and then try again."

I have tried adding "session_save_path("tmp");" to LocalSettings.php, as well as play with values of $wgMainCacheType and $wgSessionCacheType with no luck. Currently, my shared memory settings in LocalSettings.php have only these two lines:

$wgMainCacheType = CACHE_ACCEL;

$wgMemCachedServers = [];

How can I fix this? I believe my CSRF token is not being correctly cached in my session, but I'm not sure how to correct it.

I am using MariaDB as a database, Apache for the server, and PHP 5.5.37.

Ciencia Al Poder (talkcontribs)

If you have $wgMainCacheType = CACHE_ACCEL; you should provide a persistent data storage in $wgSessionCacheType

Reply to "There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Go back to the previous page, reload that page and then try again."
Viruszany (talkcontribs)

Is there a way to set and read cookies using MediaWiki's built-in functions, or should I use PHP's setcookie() function?

This comment was hidden by AhmadF.Cheema (history)
Ciencia Al Poder (talkcontribs)

From the WebRequest class (usually accessible in $wgRequest and various hooks) you can call the response() method which returns a WebResponse object where you can call the setCookie method.

Reply to "Setting and reading cookies"

What's the difference between PageContentSave and EditPage::attemptSave?

Flashdash1 (talkcontribs)

These two hooks (Manual:Hooks/PageContentSave and Manual:Hooks/EditPage::attemptSave) seem to both run when an attempt is made to save a page. They provide different parameters to the event handlers, but they seem to trigger at the same time? What's the difference between the two and under what circumstances would one be more appropriate over the other? Thanks.

Ciencia Al Poder (talkcontribs)

EditPage::attemptSave is called at the beginning of internalAttemptSave, after a lot of processing including permissions checks, spam checks, null edits... it calls WikiPage:doEditContent which calls the PageContentSave hook.

Flashdash1 (talkcontribs)

So PageContentSave is for when the page is about to be saved and attemptSave is merely an attempt to save the page and it still has to pass through all those checks, right? If I was making an extension to check the contents of an edit for inappropriate content or spam, it seems it would be better to use attemptSave and abort there if it fails? Thanks.

Ciencia Al Poder (talkcontribs)

Yes, although for your use case it's better to use Manual:Hooks/EditFilter instead, which provides useful variables to give error messages.