Project:Support desk

Jump to: navigation, search

About this board

Edit description
vde   Welcome to MediaWiki.org'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

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.

CSchrieb (talkcontribs)

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
2A02:908:E852:9D60:3152:5D34:4682:BC72 (talkcontribs)

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)
   3 /mnt/web115/a2/12/57862812/htdocs/mediawiki/includes/cache/localisation/LocalisationCache.php(275): LocalisationCache->loadItem(string, 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}
This, that and the other (talkcontribs)

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!

152.26.211.39 (talkcontribs)
: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.

185.63.72.17 (talkcontribs)

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.

AhmadF.Cheema (talkcontribs)

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

185.63.72.17 (talkcontribs)

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

97.75.165.2 (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.

DikkieDick (talkcontribs)

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.

2601:144:C180:397:D250:99FF:FE7B:C750 (talkcontribs)

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!

Thomymaster (talkcontribs)

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?

Thomymaster (talkcontribs)

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.

AhmadF.Cheema (talkcontribs)

If you want, you can follow the related phabricator task here.

2601:646:8080:6E60:F84B:DF5E:61EA:9DBB (talkcontribs)

Is there a way to change CACHE_ACCEL?

Bassitone (talkcontribs)

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.

Adroit (talkcontribs)

Yup, still in 1.28.

Fixed with $wgSessionCacheType = CACHE_DB;

Which means you can leave $wgMainCacheType = CACHE_ACCEL; where it is.

Stewharr (talkcontribs)

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.

MacFan4000 (talkcontribs)

Bugreport that on Phabricator.

Reply to "Login error (session hijacking protection)"
星耀晨曦 (talkcontribs)

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
Maxime.bochon (talkcontribs)

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:

username@domain.ext

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

SomeName <username@domain.ext>

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"
EvangelionI (talkcontribs)

No ability to expand/hide, no button

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

EvangelionI (talkcontribs)

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"
NitaiDas (talkcontribs)

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
RewriteRule ^/*$ %{DOCUMENT_ROOT}/index.php [L]
#
Options -Indexes +SymLinksIfOwnerMatch
allow from all
AllowOverride All Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch
Require all granted
</Directory>

(In the DocumentRoot and Directory paths symlinks are used, but I have changed to reflect the actual location)

Permissions of the Images directory:

/home/DOMAIN/public_html/mediawiki/sites/images drwxr-xr-x www-data www-data images

All else is DOMAIN:DOMAIN

I have even ran chmod -R 777 images to test.

I have tried with other directories and files in the area where images dir is located, without any success, and that leads me to think that I cannot access ANYTHING outside of the DocumentRoot.

Ciencia Al Poder (talkcontribs)

Your <Directory> directive is for "/home/DOMAIN/public_html/mediawiki/mediawiki1.28", but "/home/DOMAIN/public_html/mediawiki/sites/images is outside of it, so you need to add another <Directory> directive where you can give access permissions

NitaiDas (talkcontribs)

Thanks, I thought so.

What sort of permissions directives would be needed? (site files owned by DOMAIN and images by www-data)

Ciencia Al Poder (talkcontribs)

you can try allow from all and Require all granted, like your example

Reply to "Images always showing 403 error"

Centered Wikitable doesn't center anymore

5
Blumenfuchs (talkcontribs)

Hey,

in my wiki, class="wikitable centered" doesn´t work anymore and I don´t know why. It doesn´t even show a broken code or something, the whole table is just aligned left. Classes like "sortable" or "center" work pretty well.

Does anybody know why this is happening and how I can solve this problem?

Star Warden (talkcontribs)

You want for the table itself to be centred or its contents?

MacFan4000 (talkcontribs)

Try wrapping the entire table in <center> tags.

Blumenfuchs (talkcontribs)

I want for the table itself to be centered.

Star Warden (talkcontribs)

Well, using "wikitable center" does what you want. It centers the whole table. Maybe you could be more specific about how exactly you'd want it centred?

Reply to "Centered Wikitable doesn't center anymore"

can't change user preferences on Special:Preferences

1
JaNeIEEE (talkcontribs)

MediaWiki 1.27.3

PHP 5.6.30 (apache2handler)

MySQL 5.6.36

Hello, I have a problem and no idea how to solve it, so I hope someone can help me here.

I have updated my MediaWiki from 1.24.0 to 1.27.3 and ran update.php script and after that all user preferences were set to default in MediaWiki, but in the database I can see custom preferences saved (in column up_property in user_properties table ).

If I go to Special:Preferences and change values, I get "Your preferences have been saved" message, but after the page loads, all values are set back to default.

In the database I can see new records, but in Mediawiki all values are set back to default.

Does anyone have an idea what is going wrong?

Thanks!

Reply to "can't change user preferences on Special:Preferences"
Blumenfuchs (talkcontribs)

Hi,

I´d like to know if it is possible to upload vsdx-data files in media wiki?

MacFan4000 (talkcontribs)

Yes if you add the relevant file extensions to $wgFileExtensions in LocalSettings.php

Reply to "Visio Data File"