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 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

Login error (session hijacking protection)

5 (talkcontribs)


I installed MediaWiki 1.27.0 on Debian Jessie with PHP 5.6.22 last week and finally got around to start editing it. However, the account I've created gets a login failure, namely: "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."

The PHP session directory exists and should be writable by the PHP process and webserver from what I can see. (I found this discussion Topic:Pjby0sdeg3e60rfy which isn't very edifying, and also six years old, but it's still the least bad source of possible solutions I could find -- everything else is about as old and has less useful information).

Let me know if you need any more information, and I'll do my best to provide it.

AhmadF.Cheema (talkcontribs)

Apparently a problem with MediaWiki v1.27. Check this out: Topic:T75cloz7981b8i92. (talkcontribs)

Yep, changing $wgMainCacheType from CACHE_ACCEL to CACHE_ANYTHING seems to have solved it. Thanks a lot! (talkcontribs)

This worked for me, had to edit the LocalSettings.php with the change $wgMainCacheType from CACHE_ACCEL to CACHE_ANYTHING seems to have solved it for me as well.

DikkieDick (talkcontribs)

I had a 1.27-release running for over a month without problems and should upgrade the production-environment today from 1.23 to 1.27 and encountered the same error on our testenvironment now. Patched to 1.27.1 a few days ago and it was still running fine then. Weird. Can't figure it out. Restored a backup from production and did the upgrade again to 1.27.0 and still the same error. Suggested solutions don't work. How to solve this? Now again back to 1.23.14.

Reply to "Login error (session hijacking protection)" (talkcontribs)

Hey Guys,

So I run mediawiki by using XAMPP (I have all the files and stuff in my ht docs) of windows. I use Mediawiki 1.26 and I'm having a bit of trouble installing VisualEditor. So I didn't know about this until I tried to write a page on my wiki using VisualEditor and it gave me "parser error" or something like that so I looked it up and it said I need to install a Parsoid service. I found the tutorial to install it but I really dont get it (Im not great at any coding knowledge) it says Ubuntu and Debian and from my knowledge they are on Linux so is there anyway to set up a Parsoid service on mediawiki runnning on windows through XAMMP?

Reply to "VisualEditor Setup is Confusing" (talkcontribs)


I installed the newest mediawiki server software and the extensions LDAPAuthentication and Lockdown.

I , finally, managed to get the groups into mediawiki, but now lockdown doesn't work for any group at all. Even if i create them myself or if they are importet from the LDAP server.


$wgExtraNamespaces[NS_OK] = 'ok';

$wgNamespacePermissionLockdown[NS_OK]['read']= array('users'); # so it only works for logged in users.

i haven't changed any other permission settings, lockdown does show up in the Specials:Version page, but acces to :ok is not restricted in any way to anyone.

help is much apreachiated.

AhmadF.Cheema (talkcontribs)

What do you mean by "newest mediawiki server software"? Is it v1.27 or 1.28-alpha?

Are you using master version of Extension:Lockdown? If not, I recommend using it as older versions have issues with MediaWiki v1.27 and above. (talkcontribs)

Hi AhmadF.Cheema,

I am using:

Mediawiki : 1.27.0

Lockdown: -(0d8aa13) (for 1.27)

i downloaded a lockdown snapshot, do you mean i should try it with the download from git master ? (talkcontribs)

Ok, now something weird is happening:

Localsettings for Lockdown:


require_once "$IP/extensions/Lockdown/Lockdown.php";

#define custom namespaces

define ('NS_OK',550);

define ('NS_OK_TALK',551);

$wgExtraNamespaces[NS_OK] = 'ok';


#restrict "read" perm

$wgNamespacePermissionLockdown[NS_OK]['read'] = array('wikisecrets');

$wgNamespacePermissionLockdown[NS_OK_TALK]['read']= array('users');

$wgNonincludeableNamespaces[] = NS_OK;

$wgNonincludeableNamespaces[] = NS_OK_TALK;


The Page <IP>/mediawiki/index.php/Main_Page:ok -accessible for all users

Page <IP>/mediawiki/index.php/ok:ok --doesn't exsist, but is is only accessible for users in wikisecrets.

I have no idea why it doesn't work like it did before, did i switch something up ?

Reply to "Lockdown not working."
Ssiimi (talkcontribs)

Im trying to Move my wiki from the normal /var/www/html to a , /var/www/wiki.domain.tld

Before the change it was reachable under domain.tld/index.php and there was no other virtualhost running. Now it should be reachable under wiki.domain.tld. Additionally there is another virtualhost running. It did work at one point when the other virtualhost was disabled but when I enabled it it stopped working.

The wiki does Show up but all the content is missing. If I click on edit I see the content but not safe it.

I’m using mediawiki 1.26.3, apache2 and debian 8.5

I tried out some rewrite mod stuff but i just ended up with a 404 or failed apache2 restart

The following is my virtualhost conf:

<VirtualHost *:80>

ServerAdmin #######

ServerName wiki.domain.tld

DocumentRoot /var/www/wiki.domain.tld

DirectoryIndex index.php

ErrorLog ${APACHE_LOG_DIR}/error.log

CustomLog ${APACHE_LOG_DIR}/access.log combined


Ciencia Al Poder (talkcontribs)

Could you detail what do you mean by "content is missing"? do you mean content is there but no images/styles, only text, or no content at all? The latter shouldn't happen in recent versions. About styles, you may need to change some variables in LocalSettings.php that may still point to the old URL scheme ($wgServer, $wgScriptPath, etc).

After that, you'll probably need to purge some caches, since MediaWiki may have cached contents with the old URL scheme. You should run purgeParserCache.php to purge the parser cache and update.php to refresh other caches like the module_deps table.

Ssiimi (talkcontribs)

there is no content at all(The wiki itself loads but all the stuff I wrote myself is not there).

I did change these two variables to this:

$wgScriptPath = "";

$wgServer = "";

If i change it to

$wgServer = "wiki.domain.tld";

It seems to go into a circle and loads the following:


I did run theses php files but nothing changed, i also rebooted the server itself.

Reply to "Moving wiki" (talkcontribs)


In our old environment we implemented a second sidebar (usersidebar) for anonymous user - as described here:

is there a way to get this in newer Versions of MediaWiki to work? I have seen the suggest here:

but this is maybe a good solution for one or two links, but not for a hole Sidebar?

Thanks in Advance! (talkcontribs)

I have updated Manual:Interface/Sidebar/Hacks for MediaWiki 1.26.

It is currently untested. Improvements/fixes are welcome! (talkcontribs)


I have changed the code to:

$wgHooks['SkinBuildSidebar'][] = 'lfHideSidebar';


* Modify the sidebar for anonymous users.


* $skin Skin object

* $bar array Contains the array items, out of which the sidebar will be created.

* @return true


function lfHideSidebar( $skin, &$bar ) {

global $wgUser;

// Hide sidebar for anonymous users

if ( !$wgUser->isLoggedIn() ) {

// Shows a login link and a special anonymous sidebar.

$bar = array(

'anon' => array(


'text' => wfMessage( 'anon_sidebar' )->inContentLanguage()->text(),

'id' => 'anon-info',




} else {

// No changes, just display the sidebar as usual.


return true;


That gives me one Sidebar as i wish, but it can only display text, no links - is there a chance, that the content of "anon_sidebar" can be displayed as links, just as the normal sidebar?

Thanks in advance! (talkcontribs)

The functions, which can be used on the text are plain(), text(), parse() and parseAsBlock(). In your code you have the line

'text' => wfMessage( 'anon_sidebar' )->inContentLanguage()->text(),

Try to use this one instead:

'text' => wfMessage( 'anon_sidebar' )->inContentLanguage()->parse(),

This should parse the wikitext to HTML. (talkcontribs)

Also I have updated the example HTML code, which you should add in your sidebar page, if you have your content parsed. Check out Manual:Interface/Sidebar/Hacks! (talkcontribs)


Unfortunately that wont work - with the code from you it only shows a Sidebar with the Heading (anon), when i add a

additionally "array" command it shows me the content of the sidebar, but only with text, not with links:


'anon' => array(

'text' => wfMessage( 'anon_sidebar' )->inContentLanguage()->text(),

'id' => 'anon-info',




change to:


'anon' => array(


'text' => wfMessage( 'anon_sidebar' )->inContentLanguage()->parse(),

'id' => 'anon-info',





The "parse" command shows additionally something like <code> <li> </li> </code> between the text, but its not a link... I think its only a small thing what is missing here...

Reply to "Sidebar for anonymus User"
2001:56A:F141:B500:5FD:234C:FEAC:5725 (talkcontribs)

Im trying to download steam with winetricks. But the problem is I cant access the list of apps because it wont expand when I click on it. Help?????

TheDJ (talkcontribs)

Hi, you posted to the helpdesk of the software project MediaWiki. Your question seems to pertain to something other than our project, so unfortunately, we won't be able to help you.

Reply to "Wintricks apps list not expanding"

Почему бессрочно заблокировали мою учётную запить Main Guns ?

Main Guns (talkcontribs)

Почему бессрочно заблокировали мою учётную запить Main Guns ? -

Создавал страницу с учётом всех требований википедии, за что получил блокировку , как я могу исправить / восстановить учётную запись?

Спасибо. С Уважением Иван Кичук. Разработчик игры Main Guns ( (talkcontribs)

Hi Ivan,

I understand that you are asking why your user account Main Guns got blocked on Commons.

The block was done by commons:User:INeverCry. The block reason, which he provided was "promotion-only account". Background for this block is the content of your (deleted) user page, which the admin considered promotional. Note that Wikipedia Commons is no place for promotional materials. Having posted this page is the reason why your account got blocked.

Reply to "Почему бессрочно заблокировали мою учётную запить Main Guns ?" (talkcontribs)

The IT people blocked action=submit,form-data:key=wpSection that I cannot submit the save page and preview page. Is that any way to debug the code to avoid such key name "wpSection"? (talkcontribs)

Trying to adjust the code only is tinkering about with the symptoms. The real solution is to have your IT guys fix their broken rules. These rules - at least in their current form - obviously are doing more harm than good.

Aroadant (talkcontribs)

I tried to change all "action" into "action1". Then I can save the page, but other BUGs show up. I will try to contact the IT people to stop such stupid Block Rules. (talkcontribs)

The submit action of MediaWiki is just a normal action. Maybe the IT guys don't even know what mess their rules are creating. If you should use/have to use MediaWiki, then these rules need to be fixed.

Reply to "getVal('wgSection') Problem"

Cannot save page or Preview page on mediawiki 1.2.0

Aroadant (talkcontribs)

I used mediawiki 1.2.0 on my Server and because of the php Version I cannot update it. The problem I have is that I can edit and save the page on the local machine. But, if I tried to edit and save pages using external computer, it will show up a connection reset error.

From external computer, I can view all the pages, create user account, even upload a large size of file.

Any suggestions about how can I DEBUG this problem? (talkcontribs)

How to debug might help you.

For clarification:

  • Your MediaWiki version really is 1.2? Not 1.20?
  • When you say "local machine", what do you mean? Is that the same machine, on which the server is running? Like: The localhost of your wiki?
  • Is the connection reset error in your browser shown when you open the edit view? Or only after you hit the save button? Or both?
Aroadant (talkcontribs)

Sorry about the unclear statement, the version is 1.20.

By "Local Machine", I mean the server which runs the apache2 and php along with the mediawiki. And I tested editing mediawiki pages using the browser in "Local Machine", it works well.

The "connection reset" error occurs after I hit the save button and waited for several minutes.

I tried to use the PHP Error Log, and nothing shows up there, also for apache2 and Mysql Error log.

For information, my php version is 5.2.0.

Ciencia Al Poder (talkcontribs)

This looks like MediaWiki hangs while editing a page, and some sort of max execution time for PHP is killing it before completion.

You can try editing a small page to see if the problem is a very complex page. For example, create a new page with just a dot in the content, and see if the page is saved. If small edits are saved but complex ones aren't, the problem may be a slow server, or some extension causing problems. You may try disabling extensions.

Aroadant (talkcontribs)

Thanks a lot. I find the reason now.


Seems that the Server Reject some spectial Post which is weird.

Briancolella (talkcontribs)


I have been having a problem with my pages not categorizing on the wiki we use at my office. Since it is corporate & private, unfortunately I can't share the actual wiki.

The problem:

When I create a new page, in order for it to categorize I have to save it with no content except the categories. The blocker seems to be any other links in the content of the page. If I created a page with content, categories, and all, it would not categorize. In this case, I have to go back in and cut all the content, saving the empty page with just categories, then pasting the content back in once I see it has categorized. (I also tried removing all link brackets, and that worked, but it's easiest just to remove everything.)

Additionally, sometimes one category will even block the other. I will have to save it first as one category, then add the next one and save again, then add the content and save when it's finally in all the correct categories.

This isn't the worst (although it is pretty annoying) when creating new pages from scratch. But once pages are created, if I want to change or add categories it becomes a major headache.

The other symptom of this problem is that pages won't show up as "uncategorized" if they are in one category but not some of the others, so I can't easily identify which pages aren't categorizing properly (we have a lot of pages).

Here is our version info:

MediaWiki 1.27.0

PHP 5.6.24 (cgi-fcgi)

MySQL 5.5.42-37.1-log

ICU 4.2.1 (talkcontribs)

Is a categorized page also disappearing from the category, when you are editing the page without removing the category?

I am asking, because there are known problems with the job queue. The issue people usually have is that pages do not (in fact: not immediately) appear inside their categories. Reasons may be different: It is possible that the job queue is not working at all or that for the way the wiki is being used the queue is not doing enough jobs.

Often setting $wgRunJobsAsync to false helps. Then monitor the contents of the Manual:job table to see, if jobs are getting executed...

Briancolella (talkcontribs)

Pages stick in the category once it's been categorized.

I installed the Maintenance extension and ran runJobs.php; I also ran showjobs and this is the output:

refreshLinksPrioritized: 0 queued; 82 claimed (3 active, 79 abandoned); 0 delayed showJobs ran successfully!

I can't tell if that means it's running those abandoned jobs or if those jobs are the issue. I created a test page that is still not categorized after running runJobs.php (talkcontribs)

Your output means that 82 jobs have been run, but have not been finished. 3 of them are still running or are at least in a state that MediaWiki will try running them again in the future. 79 jobs have exceeded the max job attempts threshold within the last seven days and therefor will not be run again in the near future.

I also cannot tell, if these jobs are the problem, but according to the job type, this at least is possible.

I would now try the following:

  • In the database, TRUNCATE the database table jobs. This will remove all the unrun jobs from the DB.
  • Afterwards, run the refreshLinks.php to get the link tables updated. After that point, category pages will show their member pages correctly again.
  • Set $wgRunJobsAsync to false, do a few edits, adding or removing categories from pages. Then wait a day or so to see, if categories are correctly updating now. You can also monitor the contents of the job table to see, if jobs are getting executed...
Briancolella (talkcontribs)

I've been trying to figure this out on my own but it's not going so well. I was able to truncate the jobs table, but I'm having issues when trying to run refreshLinks.php. I may be doing something wrong but I'm not sure what.

From PuTTY I'm getting this:

"[~public_html/maintenance]# php refreshlinks.php

Status: 404 Not Found

Content-type: text/html

No input file specified.

From the MaintenanceShell extension I get this (page names replaced with XYZ):

Refreshing links tables.

Starting from page_id 1 of 1024.

A database query error has occurred. Query: INSERT IGNORE INTO `wrx_pagelinks` (pl_from,pl_from_namespace,pl_namespace,pl_title) VALUES ('1','0','0','XYZ'),('1','0','0','XYZ'),('1','0','14','XYZ'),('1','0','14','XYZ'),('1','0','14','XYZ'),('1','0','14','XYZ'),('1','0','14','XYZ'),('1','0','14','XYZ'),('1','0','14','XYZ'),('1','0','14','XYZ'),('1','0','14','XYZ')

Function: LinksUpdate::incrTableUpdate

Error: 1054 Unknown column 'pl_from_namespace' in 'field list' (localhost) (talkcontribs)

Generally using Putty is the preferred way to run such scripts. Using the MaintenanceShell extensions runs them in a way they never were intended to be run.

Anyway, I currently don't know how you are getting the error 404 in Putty. I think I have never seen that. Compared to this, the output from MaintenaceShell in fact looks better...

For the error "Unknown column 'pl_from_namespace'": According to pagelinks table, the column pl_from_namespace has been added in MediaWiki 1.24. You are using MediaWiki 1.27. Can you doublecheck, if this column really is missing? I think you should have gotten errors way earlier already then...

Briancolella (talkcontribs)

So it would appear that the column really is missing. My describe/explain output for the pagelinks table shows just the three fields (talkcontribs)

Puhh, that is possibly quite some work you have ahead.

You could now try running the update.php script. Maybe this adds the missing columns. Make sure you have a backup, of your files but especially of your database, before you try it!

Another approach would be to check the SQL files, which come with MediaWiki to see, which one of them should have added the missing columns. I just did that for you and it is the file maintenance/archives/patch-pl_from_namespace.sql. Then you can run this file in your database to get the - empty - column and the index added. You will have to add your table prefix wrx_ to the according MySQL commands.

The really save way would be to create a MySQL dump of your database with the option --no-data. This will dump the scheme without any data - compare this scheme with the scheme of a newly set up MediaWiki 1.27 database to see, which columns and indeces are missing. And then add these columns and indeces...

Ciencia Al Poder (talkcontribs)

Adding a missing column manually wouldn't give me any confidence that this would resolve the problem. Note that the database update not only adds tables or columns, it may also populate or change contents of those tables, and just comparing two database schemas won't give you details about those.

Reading the original description of this thread, which notices that the page saves without errors, but if changes are made to links they won't be categorized, suggests that an upgrade was done but the update.php script hasn't been run. Please read Manual:Upgrading! (talkcontribs)

It is true that only adding missing columns and indeces will not populate them. That is why I proposed to try the update.php script first. If it has not marked the according updates as "done", maybe it helps. However, if it does not, then once you know, which columns/indeces are missing, it should be possible to at least tell, which part of a database upgrade did not go through completely.

It is possible that a DB update did add columns and stuff, but that populating them did not complete. But how to find out? Without any error message (sounds like for Briancolella the wiki worked without any errors), it will be hard to tell, what else to do...

Reply to "Problem with categorizing pages"