# Project:Support desk

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

Archives

There are also other places where to ask: IRC, mailing lists, Q&A etc.

## Post a new question

• 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".

## Blocking Account Creation

1
Summary by CSchrieb

I used the following to block account creation.

$wgGroupPermissions['*']['createaccount'] = false; I had accidentally commented it out at some point, it would appear. Hello, My site got vandalized, apparently because I did not properly prevent creation of new accounts. Can someone tell me the proper way to prevent users from creating accounts? I have a handful of people I want to have the ability to add content. I thought I'd properly followed the instructions in the manual, but I may have misunderstood something. Thanks! ## Fatal exception of type MWException after new install of 1.28.0 3 I got this Error after I uploaded the new LocalSettings.php After I put$wgShowExceptionDetails in it I get:

[WHI@LcCoLCwAACQdQdkAAAMH] /index.php MWException from line 118 of /mnt/web115/a2/12/57862812/htdocs/mediawiki/includes/cache/localisation/LCStoreCDB.php: Unable to move the new CDB file into place.

Backtrace:

   0 /mnt/web115/a2/12/57862812/htdocs/mediawiki/includes/cache/localisation/LocalisationCache.php(1030): LCStoreCDB->finishWrite()
1 /mnt/web115/a2/12/57862812/htdocs/mediawiki/includes/cache/localisation/LocalisationCache.php(464): LocalisationCache->recache(string)
2 /mnt/web115/a2/12/57862812/htdocs/mediawiki/includes/cache/localisation/LocalisationCache.php(338): LocalisationCache->initLanguage(string)
4 /mnt/web115/a2/12/57862812/htdocs/mediawiki/languages/Language.php(4384): LocalisationCache->getItem(string, string)
5 /mnt/web115/a2/12/57862812/htdocs/mediawiki/languages/Language.php(228): Language::getFallbacksFor(string)
6 /mnt/web115/a2/12/57862812/htdocs/mediawiki/languages/Language.php(191): Language::newFromCode(string)
7 /mnt/web115/a2/12/57862812/htdocs/mediawiki/includes/Setup.php(714): Language::factory(string)
8 /mnt/web115/a2/12/57862812/htdocs/mediawiki/includes/WebStart.php(137): require_once(string)
9 /mnt/web115/a2/12/57862812/htdocs/mediawiki/index.php(40): require(string)
10 {main}

By default, MediaWiki 1.28 tries to create files called "l10_cache-XXX.cdb" (where XXX is a language code) in the cache/ directory inside the MediaWiki installation. You can either:

1. try to make sure your web server can write to this directory; or
2. set $wgLocalisationCacheConf['store'] = 'db'; in your LocalSettings.php file, to use the database to store localisation cache data instead of the cache/ folder in the filesystem. Hopefully that helps! :O this worked perfectly; thank you very much. ## Login error (session hijacking protection) 15 Summary by Ciencia Al Poder In MediaWiki 1.27 sessions are no longer stored using the default php session storage, but on the object cache. If you've changed$wgMainCacheType, you may need to tune $wgSessionCacheType, in case the caching you've chosen is not persisting data across requests. Setting $wgSessionCacheType = CACHE_DB; would be a sensible value.

Hello,

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.

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

Yep, changing $wgMainCacheType from CACHE_ACCEL to CACHE_ANYTHING seems to have solved it. Thanks a lot! 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.

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.

The wiki causing trouble was readonly through $wgReadOnly. After uncommenting this line it now seems to be working again. Another test wiki on 1.27 was still running fine. If I use$wgReadOnly there it complains about a database being locked.

But as I have $wgGroupPermissions on this readonly wiki set to false for editing it's still a readonly-wiki. Hi All - recently upgraded to Ubuntu 4.4.0-34 which made me work a bit on getting Apache set up right as during the upgrade the php configuration didn't turn out. So on php7. Once I got that going, I went through the command line upgrade of mediawiki to 1.27 but there were several php modules missing from apache2 so got these installed. Once got this all sorted out I got stumped on this same issue. As you mentioned here setting to CACHE_ANYTHING also worked for me. Just documenting this so if others that do a major OS upgrade they may find this helpful. This article did the trick for me! Hi I have the same error: OS: Ubuntu 14.04.5 PHP: 5.5.9-1ubuntu4.20 Apache: 2.4.7-1ubuntu4.13 MediaWiki: 1.27.0 (not upgraded) I have tried setting wgMainCacheType from CACHE_ACCEL (the default) to CACHE_EVERYTHING, CACHE_NONE or CACHE_DB but it dowsn't work. I also tried setting wgSessionCacheType from CACHE_ANYTHING (the default) to CACHE_DB but still no success. Do you have any other ideas? I installed a fresh 1.26.4 and migrated the content (dumpBackup.php) now it works again (CACHE_ACCEL is the default in 1.26.4). Im still interested in why it failed in 1.27.x so if somebody gives me debug instructions i am willing to help. If you want, you can follow the related phabricator task here. Is there a way to change CACHE_ACCEL? Still exists in 1.28.0 with up to date Ubuntu Server (16.04), Updated php from the repos, and everything. Changing$wgMainCacheType from CACHE_ACCEL to CACHE_ANYTHING as suggested above in LocalSettings.php appears to be the fix.

Yup, still in 1.28.

Fixed with $wgSessionCacheType = CACHE_DB; Which means you can leave$wgMainCacheType = CACHE_ACCEL; where it is.

Same issue with 1.28.2 if $wgReadOnly is set. When I comment that out it works, but this is for a replicated site and MySQL Master-Slave replication is then broke when mediawiki writes to db. Also making MySQL DB read-only renders same results. Bugreport that on Phabricator. Reply to "Login error (session hijacking protection)" ## How to fix slash (/) problem of the url rewrite in IIS8？ 1 I know this problem..But I don't know how to fix this problem in IIS. Reply to "How to fix slash (/) problem of the url rewrite in IIS8？" ## Problem sending mails with full form recipient 1 I installed a fresh mediawiki-1.28.2 on an Online.net personnal offer hosting (PHP 5.6 + MySQL) which provides quite basic access (FTP for files and phpMyAdmin for database). I had no issue in particular, thanks for the great work! I configured MediaWiki as a private wiki with user passwords sent by mail. But when I create new user, no mail are sent, while it still looks like a success on the administration interface. So I configured a log file ($wgDebugLogFile) and it showed that the mail() function returns false, it is just not displayed in the user interface. I then checked with a minimal PHP code that sending a mail works on my server. It works. Then I added some code to 'UserMailer.php' to get more info about the parameters passed by MediaWiki to the mail() function.

Nothing was wrong actually but, it seems that my hosting platform does not support a recipient different from:

And in the case of MediaWiki, the recipient is like this:

Indeed, when I try my minimal PHP code with such a recipient, the mail() function returns false and no mail is sent.

Question: is there an option in the configuration to force MediaWiki to only use the "basic form" of the recipient instead of the "full form"?

I would prefer not to have to patch the code myself so I hope I missed something... any idea?

Thank you for you help!

PS: If you think about suggesting me to switch to PEAR, I read about it, but I would prefer not to use it, and I'm not event sure it is available on my server.

Reply to "Problem sending mails with full form recipient"

## Template spoiler does not work

2

No ability to expand/hide, no button

http://skrinshoter.ru/s/220517/sLJBX9eV

The template was taken here https://ru.wikipedia.org/wiki/Шаблон:Сокрытие

I installed myself here http://wiki-evan.zzz.com.ua/index.php?title=Шаблон:Сокрытие

Tell me, please, why it does not work ː((

Reply to "Template spoiler does not work"

## Images always showing 403 error

4

I have a feeling this is related to apache directives and URL rewrite.

I have set up MediaWiki on Ubuntu 16 following Wiki family drupal style sites and no matter what I do I get 403 forbidden on all images. That is, images do not show on the wiki, nor when directly navigated to in the URL.

The images directory is outside of the DocumentRoot.

Here is my Apache directives

DocumentRoot "/home/DOMAIN/public_html/mediawiki/mediawiki1.28"
ServerName en.DOMAIN.org
Alias /images "/home/DOMAIN/public_html/mediawiki/sites/images"
<Directory "/home/DOMAIN/public_html/mediawiki/mediawiki1.28">
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-d
RewriteRule ^(.*)$%{DOCUMENT_ROOT}//index.php [L] ## http://www.mediawiki.org/wiki/Manual:Short_URL/Apache # Enable the rewrite engine RewriteEngine On # Short url for wiki pages RewriteRule ^/?wiki(/.*)?$ %{DOCUMENT_ROOT}/index.php [L]
# Redirect / to Main Page