Manual talk:LocalSettings.php

Latex Equations
I believe there are some missing steps in the Latex equations enabling instructions in this page.

I have miktex intalled and latex is in the path. I edited LocalSettings as explained but I still receive the message: Failed to parse (Missing texvc executable; please see math/README to configure.)

I have seen the file but still could not make it work. I think I should have texvc executable in the math directory, but I could not make "Make" works. Is there any texvc.exe already compiled for windows? --Fredguth 18:59, 7 July 2006 (UTC)


 * This page was never a good page to read all the details about how to set up Latex, as it's just a summary page of some config options.
 * This talk page was never good page to ask questions about Latex settings, hence it took 10 years for an answer :-)
 * The right place to look these days is Extension:Math. In fact it's not even a core feature any more so I've just removed all latex mentions here
 * -- Harry Wood (talk) 03:07, 7 April 2016 (UTC)

Logo
The Logo section says to use the relative URL, however I had to use the full canonical URL... What gives?

$wgLogo = "$wgStylePath/common/images/wiki.png"; Should be: $wgLogo = "{$wgStylePath}/common/images/wiki.png"; and you need to define $wgStylePath not as "/var/www/html/wiki/skins/" (or whatever, that's the path from / on my machine), but as the URL path (and thanks to YOUR clue, whoever you are, I found that): $wgStylePath = "/wiki/skins/" This works like a charm for me, so I'm going to edit the Manual:LocalSettings.php so others with no previous knowledge of mediawiki setup will not be lead astray the way I was. Cheers!
 *  did you have to use the full URL? Maybe you were having the same problem I was... I think:

-Tzf 02:02, 2 November 2007 (UTC)


 * Well, Tzf, I'm glad it works so well for you . Though I've been a wiki admin for quite a while, I never needed more than the old wikimedia interfaces before. Now my duties in developing a new wiki involve working with LocalSettings.php, and that setting sure screwed me up. I'm not touching the article because I know that I don't know enough to do it. Ever call in to tech support with a problem and hear "Well, it works all right on my machine"? -- Thnidu 19:02, 22 July 2009 (UTC)


 * Manual:$wgLogo is the more full and complete documentation of this. It says the value is absolute or relative. The current instructions on this page are non-specific on this, but correct. They describe the standard approach as...
 * ...which is sort of relative, but actually absolute :-)
 * If we see something incorrect on this page, it's worth discussing it here. But if you're interested in the details of a config setting, go read/discuss the detailed documentation page!
 * -- Harry Wood (talk) 03:28, 7 April 2016 (UTC)
 * -- Harry Wood (talk) 03:28, 7 April 2016 (UTC)

After a couple of hours of tinkering with the LocalSettings.php file, resizing my logo.png to below 135 x 135 px, and reloading several times, I finally found out that I had done everything done correctly the second attempt. I just hadn't cleared by browser cache so it looked like I continued to fail. LFMF, and clear that cache. Greggem 00:31, 30 July 2011 (UTC)

Renaming site:Changing $wgsitename
I need to change $wgSitename var in the LocalSettings.php since is started with "MyWiki", but i created documents such as "MyWikipedia". If I change $wgSitename to "MyWikipedia", then all the articles starting with "MyWikipedia" disappear. I want to move the "MyWikipedia" to it's own name space - essentially the sitename. Help... :-) I have a bunch of documents with the namespace of "MyWikipedia:" that want to use as the site/project name.  I'm using MediaWiki 1.5.5.  -Mitch 21:20, 12 January 2006 (UTC)
 * You can move pages into another namespace. Manual:NamespaceDupes.php might help, also see Manual:Using_custom_namespaces. --Jörgi123 (talk) 15:29, 30 April 2014 (UTC)


 * I have a similar problem but maybe a bit trickier. My site's in German, I'd like to change the site's name to something that contains an Umlaut. Doing this in LocalSettings.php I end up with funny characters on the screen, as described elsewhere. (If anybody has a solution to this I'd be very happy.) Additionally, part of the pages disappear as Mitch describes. My approach would be to create a database dump and then reinstall the wiki with a new name, then import the dump. I havent tried it yet because I'd like to find a more elegant way to do this. Any hints? --84.151.189.28 02:40, 21 January 2006 (UTC)
 * Or you just fix the encoding of LocalSettings.php - that would save you some needless work and would also be an option. ;-) --Jörgi123 (talk) 15:29, 30 April 2014 (UTC)

wgSpamRegex
This page of the manual ought to have a link to Manual:$wgSpamRegex, which is yet another setting in the LocalSettings.php file. (I would have already added it myself if the page wasn't locked). --DavidCary 23:08, 15 December 2007 (UTC)


 * It's not clear from your comment, whether you understood about this page "See the configuration settings index and the comments included in the settings files for help on what all the variables do. A short listing of the most important variables, as well as the most requested features, is listed below."
 * But if you want to make an argument that Manual:$wgSpamRegex is one of the most important variables... I think that's a fair point. Although there's quite a few other settings related to Manual:Combating spam, I think captchas are sadly more necessary and more important to set up.
 * But in general this page has some weird choices for "most important". Maybe the list requires some more careful curation.
 * -- Harry Wood (talk) 03:41, 7 April 2016 (UTC)

How do I get my domain name to work?
I have an add on domain set up in my cpanel to point to the wiki directory inside my root directory. What do I need to do for newusconstitutionwiki.org to open when the domain name is typed. When I type in newusconstitutionwiki.org I get the following error:

The requested URL /constitutionwiki/index.php5 was not found on this server.

That is the correct name (constitutionwiki) for the directory I have the mediawiki files in!

This is the path I see in the address bar: http://newusconstitutionwiki.org/constitutionwiki/index.php5?title=Main_Page

The index.php5 file is there so what gives?

I have done searches and can't find anything that addresses this situation.

I am totally new to mediawiki!!

How to use interwiki images?
I want to use images on commons in my site. Is this possible. If yes how I can do that? -Redgwan 08:16, 23 August 2009 (UTC)
 * You should use Manual:Image_Administration. --Arseny1992 03:24, 28 November 2009 (UTC)

The Comment #UPO
Can anybody tell my what thet Comment want's to point out? I found it in multiple locations in the LocalSettings.php for example: $wgEnableUserEmail = true; # UPO I couldn't make sense of it. (and it probably is not important, since it is a comment) --153.96.161.212 16:13, 4 November 2009 (UTC)


 * It actually says what it means in the file: “UPO means: this is also a user preference option” --ucc 11:17, 11 November 2009 (UTC)

$wgGroupPermission BEFORE OR AFTER extension calls?
Hope I'm i the right place to ask this. Would like to know what the correct order is between $wgGroupPermission and extension require/include_once calls? Should the permission be granted before the extension is loaded? Or vice cersa?
 * Which of these two is correct:
 * $wgGroupPermissions['group'        ]['function'  ] = true;
 * require_once("$IP/extensions/Folder/File.php");
 * OR
 * require_once("$IP/extensions/Folder/File.php");
 * $wgGroupPermissions['group'        ]['function'  ] = true;

OR does it matter? I have been testing both orders and either seems to work but some extension authors insist one order while another author wants it the opposite. 'Put mine first', 'Put this last'. I just want to know how the MW core system wants. And if every author wants their stuff last what then? Confused 06:16, 11 March 2011 (UTC)
 * Usually the extension installation guides advice to first include the extension and then to set group rights for them. --Jörgi123 (talk) 13:45, 30 April 2014 (UTC)

Terms of Use
I try to find out since months how to add the "; additional terms may apply. See Terms of Use for details." phrase. What I have to do to get this text too? --213.47.162.108 12:15, 2 November 2011 (UTC)
 * Edit MediaWiki:Copyright on your wiki and add it to the existing text. Reach Out to the Truth 19:37, 3 November 2011 (UTC)


 * Thanks for your advice, but it doesn't work for me. MediaWiki's MediaWiki:Copyright has a different text too. --213.47.162.108 22:36, 3 November 2011 (UTC)
 * Yes, it has different text on this wiki. That's because Wikimedia sites override that message with a completely different message. The message isn't used on this wiki, but by default it is. If your wiki is public, can you post a link so I can take a look? Reach Out to the Truth 20:26, 4 November 2011 (UTC)
 * Ok, my bad. The text is changed, but I can't define the reference to $2. I have to use two links (like MediaWiki)--213.47.162.108 15:32, 5 November 2011 (UTC)
 * $1 is replaced by a link to or  with the text of . $2 is not replaced by anything. So yes, you need to put the link in the message manually. Reach Out to the Truth 15:49, 5 November 2011 (UTC)

Problem with installer
After walking through the installation, I get the "Complete!" page, telling me that I have successfully installed mediawiki.

The installer has generated a localsettings.php file.

The download offered, and the link on the page throws this error, however:

"Internet Explorer cannot download index.php from localhost. Internet Explorer was not able to open this Internet site. The requested site is either unavailable or cannot be found. Please try again later."

Restarting the installation results in same answer. Without this file I can't get into my wiki because it believes it to be unconfigured.

Suggestions?
 * Most probably some kind of file download problem with IE. Try with another browser. --Jörgi123 (talk) 15:12, 30 April 2014 (UTC)

We also have this same problem. We have no other browsers we are allowed to use. Surely this should be fixed not "get another browser"? Dissapointed: May 2015.

Check user permissions before loading extension
Hello. I was wondering if there is a possibility to check the permissions of a wikiuser inside  and depending on the outcome load an extension? Now we are using the below code, this works fine when the wikiuser uses the same laptop or computer all the time but that is often not the case.

If possible, we would like to check if a wikiuser is member of a group like the sysop's and only then load extensionx. If the user is not part of the sysop group the extension is not loaded. Then it does not matter on which computer or laptop the user is working. Regards, --Jongfeli (talk) 07:32, 14 August 2013 (UTC)
 * I would say that is not possible: At the time when LocalSettings is first read (and so when the extensions are included), a user object does not yet necessarily exist. Consequently, at that point, you cannot check permissions of a MediaWiki user. --Jörgi123 (talk) 16:19, 30 April 2014 (UTC)

How to keep ones LocalSettings.php up to date
Mention How to keep ones LocalSettings.php up to date. I.e., one can update all the files except for LocalSettings.php, which still needs a way to keep it somewhat in step with what is generated for new installations. Jidanni (talk) 12:36, 23 June 2015 (UTC)


 * I don't think people really keep the file up to date with what would be generated, if it was a new install. I once did that and I ended up manually comparing the content and merging where it seemed appropriate. But it is not really much, what you would have to update; most things are actually custom to the according installation and will not be gernerated during setup.
 * If it however was vital to update that file, then I would expect MediaWiki to do that during upgrade. Other systems do have such upgrade wizards, which upgrade the central configuration file. However, MediaWiki does not have something like that. --88.130.88.162 22:22, 23 June 2015 (UTC)
 * Or maybe have some declaration somewhere that don't worry, ones LocalSettings.php is guaranteed to not need to be tweaked during upgrades as MediaWiki will not break it (without some notice somewhere), all one needs to remember is upgrade the files and run update.php... Jidanni (talk) 23:33, 23 June 2015 (UTC)
 * Actually, with the new Manual:Extension registration, at some point the contents of LocalSettings will need to be adapted, because the require_once way of including extension is going to be dropped at some point. --Ciencia Al Poder (talk) 09:16, 25 June 2015 (UTC)

Is it possible to test LocalSettings.php variables in wiki markup?
For instance, I would like to test whether $wgReadOnly is defined to add a site-wide notice using Mediawiki:Sitenotice. Something like:

Mediawiki:Sitenotice

Thanks in advance...

--Rbirmann (talk) 14:03, 7 December 2015 (UTC)


 * This particular use case is not needed, since your readers don't *need* to know if the site is in read-only mode until they attempt to edit anything, in which case they'll get the warning. But in general, those variables aren't available in wikitext --Ciencia Al Poder (talk) 10:43, 8 December 2015 (UTC)


 * Kind of hard to say the use case is not needed when a user is asking for a way to do it. We would like to add a maintenance banner to our home page. Anyhow, if it can't be done, it can't be done. Thanks. --Rbirmann (talk) 12:00, 8 December 2015 (UTC)
 * For $wgReadOnly I must say I agree with Ciencia: Immediately when you try editing a page, you will see that notice. There is no need to manually add it somewhere; people will see it anyway. For other variables however I do not know of a way of somehow getting hold of them on a page. If that was possible, I would fist check the MySQL database name and then the password. Afterwards I would try using this snesitive data and then I would start deleting the text table. I guess you see what I mean: Huge part of the variables in LocalSettings.php are security relevant and it is no good idea to make such information publicly accessible. --Jörgi123 (talk) 13:22, 13 June 2016 (UTC)


 * I don't know of a way to test it from inside wiki markup, but a number of these variables is exposed to the public already, e.g. for mediawiki.org see https://www.mediawiki.org/w/api.php?action=query&meta=siteinfo&siprop=general. --2003:72:6D1D:9900:7106:60AF:40F8:6278 21:09, 17 August 2017 (UTC)

Wikimedia content wikis
Does anyone here know whether any Wikimedia "content wikis" (English Wikipedia, German Wiktionary, etc.) actually use LocalSettings.php files? I know that [//noc.wikimedia.org/conf/CommonSettings.php.txt CommonSettings.php] "includes" the settings in [//noc.wikimedia.org/conf/InitialiseSettings.php.txt InitialiseSettings.php] (both publicly viewable), but CommonSettings also claims to be "includ ed " by LocalSettings.php (which would not be publicly viewable). Are there any settings listed in the LocalSettings.php for any Wikimedia content wiki that would override any of the publicly viewable settings? - dcljr (talk) 02:20, 13 September 2016 (UTC)

How to activate changes in the LocalSettings.php?
Given that one has done changes to the LocalSettings.php and uploaded the file to the proper place, replacing the old version. --Manorainjan (talk) 22:58, 31 January 2017 (UTC)
 * When would MediaWiki read the new settings?
 * How to make MediaWiki read it immediately (one time)?


 * This is done inmediately. --Ciencia Al Poder (talk) 10:45, 1 February 2017 (UTC)


 * Each page loaded after the change has been done will be generated using the new version of the file. If changes do not become visible immediatelly, ten a cache might be inbetween, which actually is showing you an old version of a page. --2001:16B8:1053:BB00:F0DF:55A:F250:E31F 17:01, 23 February 2019 (UTC)

Prevent Database Connection Errors
When you set mysql AND postgres parameters in LocalSettings.php, the mysql connection will fail. This happens e.g. with 1.35.10.

Commenting the postgres settings out helps. Sbrunthaler (talk) 11:50, 20 May 2023 (UTC)