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

## LocalSettings.php Issue

1

I was able to get our site up and running, but when I add the line below to my localsettings.php file, save it, then to to my wiki, I get an error. I have added it to the bottom of my localsettings.php file and followed the install procedures via the site. Has anyone run across this before?

PHP Warning: Parameter 1 to EmbedVideoHooks::onParserFirstCallInit() expected to be a reference, value given in C:\inetpub\wwwroot\kb\includes\Hooks.php on line 195

## Seach and Special Pages aren't using Theme

6

MonoBook theme is active and working perfectly except Search Results and Special:

Am I missing something or just ignorant of how to setup??

http://mediatech.wiki

Product Version
MediaWiki 1.28.2
PHP 5.6.30 (cgi-fcgi)
MySQL 5.6.35-cll-lve
ICU 50.1.2

Your load.php URL crashes when loading some modules, for example: mediawiki.helplink. You should enable the display of exception details in Manual:How to debug to see an error message and identify the issue

Interesting, I thought we had debug enabled

Thank you!

I don't want to come across unfriendly or anything but, couldn't you have used a different domain ?

The landscape is confusing enough when it comes to the terms of wiki, wikipedia, wikimedia, wikitech.wikimedia.org, wikileaks etc etc.. Further adding to that confusion for wiki users might not be the best idea...

We work in the media tech industry. It's an existing convention, like biotech or fintech. i.e. http://www.mediatechsummit.com I suppose we could go with something other than .wiki but its a wiki, no?

This comment was hidden by Plobrien (history)
Reply to "Seach and Special Pages aren't using Theme"

## Template spoiler does not work

3

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

You also need the CSS and JS that enables collapsible div system that this depends on. It is in their https://ru.wikipedia.org/wiki/MediaWiki:Common.js and https://ru.wikipedia.org/wiki/MediaWiki:Common.css files

Reply to "Template spoiler does not work"

## Newbie

3

Hi, i'm looking for wiki to use in small enterprises (15-25 people). I don't quite understand wiki in general and would like to ask: in running mediawiki, do php and database required for all users?

If you're asking if anyone who uses the wiki needs to have php and database installed on their own end, then no. The php and database is required for the wiki itself.

Users only need a web browser to connect to the server where the wiki is hosted. The server that hosts the wiki needs PHP and database access

17

Environment:

OS: Ubuntu 14.04.4 LTS

MediaWiki: 1.26.2

wiki url: http://intranet.hit.local/wiki-hitit/

parsoid listener port: 8142

After a good day of trying to set up VirtualEditor, the above error is still with us.

I think I followed the instructions in

- https://www.mediawiki.org/wiki/Extension:VisualEditor

- https://www.mediawiki.org/wiki/Parsoid/Setup

though, I'm still uncertain about the url/uri.

/var/www/html/wiki-hitit/LocalSettings.php has the following entries for VisualEditor:

### VisualEditor

require_once( "$IP/extensions/VisualEditor/VisualEditor.php" );$wgDefaultUserOptions['visualeditor-enable'] = 1;

$wgSessionsInObjectCache = true;$wgVirtualRestConfig['modules']['parsoid'] = array(

'url' => 'http://localhost:8142/wiki-hitit/',

'prefix' => 'wiki-hitit'

);

/etc/mediawiki/parsoid/localsettings.js has the following entries:

'use strict';

exports.setup = function(parsoidConfig) {

parsoidConfig.setMwApi({ prefix: 'wiki-hitit', uri: 'http://localhost/wiki-hitit/api.php' });

parsoidConfig.useSelser = true;

};

/var/www/html/wiki-hitit/extensions/parsoid/localsettings.js has these:

'use strict';

exports.setup = function(parsoidConfig) {

parsoidConfig.setMwApi({

prefix: 'wiki-hitit', // optional

uri: 'http://localhost/wiki-hitit/api.php' });

parsoidConfig.useSelser = true;

};

The api.php is accessible:

$curl 'http://localhost/wiki-hitit/api.php' | head % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 <!DOCTYPE html> <html lang="en" dir="ltr" class="client-nojs"> <head> <meta charset="UTF-8" /> <title>MediaWiki API help - Hitit</title> The wiki pages now have both an 'edit' and an 'edit source' tab. But when you press the 'edit' tab, you get a pop-up with this error message: "Error loading data from server: 404: parsoidserver-http: HTTP 404. Would you like to retry?" I've found several articles about this issue, but none that helped. Is the url/uri definition correct? (All examples I found used simple urls.) Are there any log files I can check? I tried the parsoid and apache2 logs, but there's nothing there. Any other suggestions? Kind regards, Herta There's a 404 error somewhere, try to find in apache error logs the URL being requested, that should give you a hint what configuration is wrong. Maybe you need to omit the "prefix" configuration part Thanks for your reply. There's nothing in the apache error log. The access log has this entry: 10.32.14.57 - - [29/Feb/2016:09:59:13 +0100] "GET /wiki-hitit/api.php?action=visualeditor&format=json&paction=parse&page=Main_Page&uselang=en HTTP/1.1" 200 511 "http://intranet.hit.local/wiki-hitit/index.php/Main_Page?veaction=edit" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0" 10.32.14.57 - - [29/Feb/2016:09:59:13 +0100] "GET /wiki-hitit/load.php?debug=false&lang=en&modules=ext.visualEditor.base%2Ccore%2Cdata%2CdesktopArticleTarget%2Cicons%2Clanguage%2Cmediawiki%2Cmwalienextension%2Cmwcore%2Cmwformatting%2Cmwgallery%2Cmwimage%2Cmwlink%2Cmwmeta%2Cmwreference%2Cmwtransclusion%7Cext.visualEditor.core.desktop%7Cext.visualEditor.mwimage.core%7Cext.visualEditor.mwreference.core%7Cext.visualEditor.mwtransclusion.core%7Cjquery.autoEllipsis%2CbyteLimit%7Cjquery.uls.data%7Cmediawiki.ForeignApi%2Cwidgets%7Cmediawiki.ForeignApi.core%7Cmediawiki.action.history.diff%7Cmediawiki.api.options%7Cmediawiki.language.names%2CspecialCharacters%7Cmediawiki.page.gallery.styles%7Cmediawiki.skinning.content.parsoid%7Cmediawiki.widgets.CategorySelector%2Cstyles%7Cmoment%2Coojs%2Coojs-ui%2Cpapaparse%2Crangefix%2Cunicodejs%7Coojs-ui.styles%7Coojs-ui.styles.icons%2Cicons-editing-advanced%2Cicons-editing-core%2Cicons-editing-list%2Cicons-editing-styling%2Cindicators%2Ctextures&skin=monobook&version=10061a186059 HTTP/1.1" 200 2196466 "http://intranet.hit.local/wiki-hitit/index.php/Main_Page?veaction=edit" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0" P.S. I removed the prefix from the three config files and restarted parsoid and apache2, but the error remains. I think the URI in your LocalSettings.php file should be 'url' => 'http://localhost:8142' . So without the /wiki-hiti/ part. Let us know if that works :) After much trial and error, that is indeed what fixed it. Thanks, Swennet. @Hvdeynde, how you solve this issue? Pleace post your config files Hello all, After spending a LOT of time to let VisualEditor extension be able to work on my Wiki (I tried every possibilities for both parsoid setting file and LocalSettings file), I finally found a simple conf that actually works for me. So, that's what I am sharing below. For your information : -running on Debian, -mediawiki 1.26.2, -wiki's name si WikiName, -it's located in /var/www/WikiName, -IP adress of my wiki is IP_adress (like 123.123.123.123). In /etc/mediawiki/parsoid/setting.js, what has changed from the original file is following below: parsoidConfig.setMwApi({ prefix: 'IP_adress', uri: 'http://IP_adress/WikiName/api.php' ); In LocalSettings.php:$wgVirtualRestConfig[‘modules’][‘parsoid’] = array(

);

Everything else is useless for me (like domain for instance). I think that 'Localhost' is not working on recent wiki (my visual editor was not working since I updated my wiki), that's why I think you should try to put some IP adress of yours to make it work insteasd of localhost.

I hope it will help a few of you!

@+

KrazyMax

Sorry for the bad layout, looked much better before it was actually posted!

KrazyMax

Hello,

it dosnt work to me.

MediaWiki 1.28.0

i become 404

LocalConfig.php:

// Enable by default for everybody $wgDefaultUserOptions['visualeditor-enable'] = 1; // Optional: Set VisualEditor as the default for anonymous users // otherwise they will have to switch to VE //$wgDefaultUserOptions['visualeditor-editor'] = "visualeditor";

// Don't allow users to disable it $wgHiddenPrefs[] = 'visualeditor-enable'; // OPTIONAL: Enable VisualEditor's experimental code features$wgDefaultUserOptions['visualeditor-enable-experimental'] = 1;

$wgVirtualRestConfig['modules']['parsoid'] = array(  // URL to the Parsoid instance // Use port 8142 if you use the Debian package 'url' => 'http://XXX.XXX.XXX.XXX:8142', // Parsoid "domain", see below (optional) //'domain' => 'XXX', // Parsoid "prefix", see below (optional) //'prefix' => 'XXX' ); localsettings.js: parsoidConfig.setInterwiki( { prefix: 'XXX.XXX.XXX.XXX', uri: 'http://XXX.XXX.XXX.XXX/mediawiki/api.php' } ); From previous messages I see the config is parsoidConfig.setMwApi, not parsoidConfig.setInterwiki. Can you check that's correct? Thanks. But ist the same 404 -.-  parsoidConfig.setMwApi({ prefix: 'XXX.XXX.XXX.XXX', uri: 'http://XXX.XXX.XXX.XXX/mediawiki/api.php'}); does opening http://XXX.XXX.XXX.XXX/mediawiki/api.php load the api help page when opening the URL from the server? yes Other ideas? You may try asking in the #mediawiki-visualeditorconnect IRC channel. Note: I got this exact error due to putting a forward slash at the end of the Parsoid URI. In other words, http://localhost:8142/ caused the error, and changing it to http://localhost:8142 fixed it. This is what it looks like in my MediaWiki 1.28 LocalSettings.php--this works! # Visual Editor require_once("$IP/extensions/VisualEditor/VisualEditor.php");

$wgDefaultUserOptions['visualeditor-enable'] = 1;$wgHiddenPrefs[] = 'visualeditor-enable';

$wgVisualEditorParsoidURL = 'http://localhost:8142';$wgVirtualRestConfig['modules']['parsoid'] = array(

'url' => 'http://localhost:8142',

'domain' => 'localhost'

);

## Trying to install PDFHandler and getting this error

2
Summary last edited by Olds98 23:48, 23 May 2017 12 hours ago

Sorry, I couldn't figure out how to reply, I see now there was a link to reopen it.. I am not sure why it was closed in the first place.. I am at a halt here with this PDFHandler, does anyone know what this error means? I don't know where to go next.. thank you very much

Hey guys, I don't know whats going on here.. I tried posting yesterday and it said someone hid it? I installed PDFHandler and the three other packages required and even before installing the three packages I got this error now on the top of every page of my Wiki.. can someone help me? I know nothing about these Wiki's.. thanks! I am stuck!

Parameter 1 to PdfHandler::registerWarningModule() expected to be a reference -

Hi please don't keep creating duplicate tasks. I merely hid a blank comment.

Reply to "Trying to install PDFHandler and getting this error"

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