Project:Support desk/Flow/2011/12

This page is an archive.

Please ask questions on the current support desk.

Mutiplelink link to only one page

First, I'm sorry that my English is not good so it may not be easy to understand I want two (or more) link to link to one page, for instance:

 mywiki.org/index.php/Hassal_body
 mywiki.org/index.php/hassal_body
 mywiki.org/index.php/Hassal's_body

I want them to link to only one page: mywiki.org/index.php/Hassal_body Thanks for reading Nva1991 (talk) 09:31, 1 December 2011 (UTC)

See Help:Redirects. Max Semenik 10:22, 1 December 2011 (UTC)

Thanks very much Nva1991 11:29, 1 December 2011 (UTC)

Collapsible navigation menu (not Vector skin)

Hi!

I am using mediawiki for my site and would like to make the navigation menu collapsible. I have found an extension for Vector skin (Extension:Vector) but I am using a different one (roundedblue). Is it possible to somehow customize the Vector extension for my skin? Or perhaps there is an extension for this very skin (i.e. roundedblue) or smth like a unique extension for any skin?

Any advise would be greatly appreciated!! 79.143.33.66 (talk) 10:03, 1 December 2011 (UTC)

I don't see why it wouldn't be possible. The collapsible nav module is located in the Vector extension directory under modules. Try incorporating those into your custom skin.    Thorncrag   18:31, 9 December 2011 (UTC)

Thanks for a tip!

A little bit of explanation regarding 'Try incorporating those into your custom skin' will be GREATLY appreciated!:) 79.143.33.66 12:19, 15 December 2011 (UTC)

You should look at the files in the Vector skin to see what code is used to include the module in Vector. Using that code similarly in your skin might just do the trick.    Thorncrag   19:26, 16 December 2011 (UTC)

knowls - how to insert?

American Institute of Mathematics developed knowls - pieces of information which could be used on web

http://www.aimath.org/ http://www.aimath.org/knowlepedia/

to refer to knowl : <a knowl="/path-from-the-root-of-webserver">This is Knowl</a> (and load Javascript but this is not a problem - one can hacki the skin). However mediawiki will change < > by < and >

One can modify Sanitizer.php to "allow" knowl - but it is not enough. Some other changes are needed to make them available in the same way as <a href=" URL">TAG</a> is available via [ URL TAG]. How to do this? Proposed format

• [path-from-the-root-of-webserver TAG]

Victor Victor Ivrii (talk) 16:23, 1 December 2011 (UTC)

I found HTMLets mediawiki extensions. Victor Ivrii 09:04, 2 December 2011 (UTC)

Url for special pages pointing to previous host's path

Hello folks. I just got some advice from this forum to move my wiki from a free host to a paid one and that has gone well. However the path for special pages comes up as "http://www.queenstown.net.nz/mediawiki/index.php?title=Special:SpecialPages" when it should be "http://www.queenstown.net.nz/informationism.org/index.php?title=Special:SpecialPages"

This is only happening with Special pages and only when I use the monaco skin. The /mediawiki/ was the correct path on the previous wiki I was on but now the correct path is /informationism.org/.

This should be a simple fix so does anyone know why this is happening and how to change it?

BTW I have not made any changes to the Monaco skin files and the Localsettings file doesn't seem to be directing it there either.

Thanks Andrewrutherford (talk) 00:03, 2 December 2011 (UTC)

Monaco skin Y U No direct me to special pages? Andrewrutherford 09:26, 3 December 2011 (UTC)

I don't see your monaco skin linking to /mediawiki/ anywhere. All the links I can see seam to be correct.

Btw, I see // in some of your paths. It looks like you've got a trailing / on one of your $wg variables that doesn't belong there. Daniel Friesen (Dantman) 19:58, 3 December 2011 (UTC)

You're right the problem seems to have resolved itself. It must have been a cache issue of some kind. Thanks for taking a look Dantman. Andrewrutherford 09:47, 4 December 2011 (UTC)

How can my page be found on Google.com

I have installed sitemap.php. I have sent it to google webmaster tools. But after 2 days, i only found my main page. I couldn't find any pages. Anyone could help me? Thanks Nva1991 (talk) 05:07, 2 December 2011 (UTC)

Unless you can point to a specific flaw with the MediaWiki software, it sounds like your question should be directed at Google, not here. The only other thing I could suggest is reviewing Manual:Robots.txt.    Thorncrag   18:07, 2 December 2011 (UTC)

Has Google crawled the rest of your site yet? Check your server access logs for Googlebot. Reach Out to the Truth 18:21, 2 December 2011 (UTC)

No. Only mainpage. 123.16.104.220 19:12, 2 December 2011 (UTC)

The default main page has links that can be followed. You can put whatever you want in the wikitext for the main page, but there will still be links that can be followed in the generated HTML page. If Googlebot hasn't even attempted to follow those links, it's unlikely that it's a MediaWiki problem. Reach Out to the Truth 19:38, 2 December 2011 (UTC)

Maximize or Minimize the text

I have a large amount of data for each point. I want to use the functionality of maximize and minimize (Expand and collapse or + and -)at each point to show or hide my information in wiki. Can anyone please help me know how to use this functionality. Gouthami.chitti (talk) 08:29, 2 December 2011 (UTC)

Try code like:

<div class="mw-collapsible">Stuff to be able hide/show</div>

See Manual:Collapsible elements#jQuery.makeCollapsible .28in core as of MediaWiki 1.18 or higher.29 Bawolff 15:13, 2 December 2011 (UTC)

Sure, will defenitely try. Thank you. Gouthami.chitti 09:59, 5 December 2011 (UTC)

$wgServer Undefined index notices with 1.18

I have set $wgServer = ''; in order to run my wiki behind an Apache reverse proxy and in order to support port forwarding when accessing the wiki via SSH on another port than 80 (e.g. port 8000 forwarded to 80). So far that works since years even though the Location header sent to the browser is relative (might violate the standard, but works with major browsers).

But since 1.18 I get PHP notices:

PHP Notice:  Undefined index: scheme in /srv/www/htdocs/mediawiki-1.18.0/includes/GlobalFunctions.php on line 572, referer: http://xxx
PHP Notice:  Undefined index: scheme in /srv/www/htdocs/mediawiki-1.18.0/includes/GlobalFunctions.php on line 574, referer: http://xxx

This is due to new code for handling the URL. Therefore, I would like to ask adding isset() checks to GlobalFunctions.php before $bits['scheme'] is accessed. Ralfk (talk) 13:16, 2 December 2011 (UTC)

Created a bug report about this issue: https://bugzilla.wikimedia.org/show_bug.cgi?id=32823 Ralfk 08:54, 6 December 2011 (UTC)

How to use generateSitemap.php

I don'n know where to type those:

First (in $IP):

mkdir sitemap

Then:

php maintenance/generateSitemap.php \ --fspath sitemap \ --server http://mydomain.org \ --urlpath http://metadatabase.org/sitemap

When i go to url mysite/maintenance/generateSitemap.php, there is a bug report

Can anyone tell me what file i have to edit and what i have to do to make a sitemap by generateSitemap.php? Nva1991 (talk) 19:19, 2 December 2011 (UTC)

You need shell access to your server to run this command. If you don't have shell access, there are some extensions which might be able to accomplish the same thing for you.    Thorncrag   21:17, 8 December 2011 (UTC)

Webpages are not looking good at all in safari

I've been up and down Google for the last few hours and I'm completely stumped for this problem. I've been using PHP for years but I have no idea of MediaWiki's inner workings and this completely escapes me.

I have a Wiki running on MediaWiki 1.18 (just upgraded today to see if it would fix the problem; it did not). For a long time everything has been completely find (a glitch here, one there, nothing serious). Two days ago, a user came to me and told me that the website looked "odd". When I asked to see what he meant, he showed me a site with no formatting (except inline styles)--that is, Times New Roman, white background, etc. I thought it might be his computer only, but then a second user came forward, and I checked it on another computer of mine, and it had the same issue. Mystified as to why I did not have this error on my main computer, I cleared my cache. Lo and behold, the CSS became blank.

Using Chrome's inspect element, I found the URLs of all the loaded stylesheets (3, to be exact, all loaded from load.php), and opened them in a new tab. Everything worked--that is to say, all of the CSS printed out properly. However, when I view the same resource in Chrome's resources tab, it is blank.

Oddly, even though the JS is loaded from load.php, it is working fine.

When reloading the page with "Inspect Element" open, I get this warning: Resource interpreted as Other but transferred with MIME type undefined. However I'm not sure if this is related. (My guess is that it is not.)

• MediaWiki: 1.18.0
• PHP: 5.2.14 (cgi-fcgi)
• MySQL: 5.0.91-log

Attached are links to a few images. This issue happens in both Chrome and Firefox (other browsers untested) and on multiple computers as aforementioned.

• http://imageshack.us/photo/my-images/856/cssfail1.jpg/
• http://imageshack.us/photo/my-images/208/cssfail2.jpg/
• http://imageshack.us/photo/my-images/833/cssfail3.jpg/
• http://imageshack.us/photo/my-images/841/cssfail4.jpg/

Again, I must emphasize that this problem just started a few days ago. (The Wiki has been up since September 8th.) Except for a few additions to Vector.css, nothing has been changed. Any help or advice is appreciated. Been banging my head on my desk for hours now! 70.72.142.228 (talk) 01:01, 3 December 2011 (UTC)

I discovered that, indeed, MIME type is related here. When I opened the site in IE and checked the dev tools, I get these errors:

SEC7113: CSS was ignored due to mime type mismatch 
load.php?debug=false&lang=en&modules=mediawiki.legacy.commonPrint%2Cshared%7Cskins.vector&only=styles&skin=vector&*
SEC7113: CSS was ignored due to mime type mismatch 
load.php?debug=false&lang=en&modules=site&only=styles&skin=vector&*
SEC7112: Script from http://********/load.php?debug=false&lang=en&modules=startup&only=scripts&skin=vector&* was blocked due to mime type mismatch 
Special:Version
SEC7112: Script from http://********/load.php?debug=false&lang=en&modules=skins.vector&only=scripts&skin=vector&* was blocked due to mime type mismatch 
Special:Version
SEC7112: Script from http://********/load.php?debug=false&lang=en&modules=site&only=scripts&skin=vector&* was blocked due to mime type mismatch 
Special:Version

How can I ensure that load.php is serving the CSS MIME type properly? In mime.types, it lists "text/css css", so I'm not sure what else I can do. Eric 01:53, 3 December 2011 (UTC)

Resolved.

Appended the following to .htaccess, and the problem is resolved.

RewriteCond %{QUERY_STRING} only=styles
RewriteRule ^load.php - [QSA,E=content_type:text/css]
RewriteCond %{QUERY_STRING} only=scripts
RewriteRule ^load.php - [QSA,E=content_type:text/javascript]
<FilesMatch "load\.php">
	Header set Content-type %{content_type}e
</FilesMatch>

Eric 19:18, 3 December 2011 (UTC)

This does not fix the problem. Is this bug ever going to be fixed? 67.182.161.111 18:28, 5 April 2012 (UTC)

I have this extact same issue on an IIS install, every other page refresh results in no CSS. Can you translate this into an IIS URL Rewrite rule. I tried to save the above example in an htaccess file and import it but it doesn't like part of the E--- portion of the rule.

IIS7 on windows Server 2008 R2 and 2012 R2 results in same behavior. Been working on this for days trying to figure it out.....

Shane 206.54.145.254 16:19, 2 October 2014 (UTC)

Not resolved. Such work-around should not and is not required by MediaWiki.

Something else is causing this to go wrong, this may fix it for you, but I'd like for this to be further investigated. Krinkle 00:02, 6 December 2011 (UTC)

I belive i'm getting same issue, after some clicks load.php just stops sending css and images.

If i delete browser history and access the wiki if loads fine, if i reload the problems begin.

I am using 1.18.1 version. NunoSeita 03:39, 20 March 2012 (UTC)

Did you try alternate browsers? Jasper Deng (talk) 04:28, 22 March 2012 (UTC)

I am having the same problem after upgrading from 1.17 to 1.18.2. Everything else seems to be working fine. I don't see any errors. 97.75.74.10 S37H 19:03, 28 March 2012 (UTC)

I have this on my .htaccess and fix the problem: RewriteCond %{REQUEST_URI} !^/(redirect|load|texvc|index).php 186.214.51.75 02:48, 13 April 2012 (UTC)

I hit this problem too (1.20.3, Firefox).

Cause: conflicting document root settings seems to make load.php choke on finding its stylesheets.

1. in apache configuration file DocumentRoot "/path/to/mediawiki"
2. in LocalSettings.php wgScriptPath ="/mediawiki";

Solution:

wgScriptPath = "";

Hat-Tip to someone at StackOverflow Richardbourke (talk) 12:11, 29 April 2013 (UTC)

I had this problem too. I am using Apache rewrite rules to make very short URLs.

RewriteEngine On

RewriteRule ^(images/|skins/|(api|img_auth|index|redirect)\.php) - [L]

RewriteRule ^/*$ /index.php?title=Main_Page [L,QSA]

RewriteRule ^(.+)$ /index.php?title=$1 [L,QSA]

After upgrading, there are more top-level PHP scripts that are part of MediaWiki, including load.php, which is a new script used to obtain skin CSS and images.

I added all the new top-level PHP scripts to my rewrite rule and restarted Apache.

RewriteEngine On

RewriteRule ^(images/|skins/|(api|img_auth|index|load|opensearch_desc|redirect|thumb|trackback)\.php) - [L]

RewriteRule ^/*$ /index.php?title=Main_Page [L,QSA]

RewriteRule ^(.+)$ /index.php?title=$1 [L,QSA]

This fixed my problem. 193.9.13.138 14:16, 25 April 2012 (UTC)

193.9.13.138's comment saved my day! I encountered the same thing: after upgrading to short URL (using a sandbox installation worked fine), the css is not loading but I can still see the page content. However, I had to add a "/" in the beginning for it to work, like this:

RewriteRule ^/(images/|skins/|(api|img_auth|index|load|opensearch_desc|redirect|thumb|trackback)\.php) - [L]

Hopefully it will help some one. BTW, 193.9.13.138's last rule

RewriteRule ^(.+)$ /index.php?title=$1 [L,QSA]

is not recommended by Mediawiki and something like the following line should be used.

RewriteRule ^/?wiki(/.*)?$ %{DOCUMENT_ROOT}/index.php [L] Wikihy com (talk) 01:26, 18 November 2013 (UTC)

Where do you add the mentioned statements? 196.214.37.26 12:19, 4 December 2013 (UTC)

Your webserver config file. In my case, httpd.conf Wikihy com (talk) 12:28, 4 December 2013 (UTC)

- Wikihy com (talk) 01:26, 18 November 2013 (UTC)

I do not like the way how MediaWiki supplies the CSS file. A CSS file should be static. No PHP and no RedirectRules should be necessary. I made a dirty hack to create static files. Maybe some of the developers get inspired to implement a similar feature by default:

http://www.wiki-forum.de/metatag-veraendern-t354878.htm#4363428 Mgutt (talk) 10:09, 18 June 2015 (UTC)

There is also bug in PHP: https://bugs.php.net/bug.php?id=64836 that may cause this problem. Gnomeby (talk) 21:43, 8 February 2014 (UTC)

And here the Gentoo bug: https://bugs.gentoo.org/show_bug.cgi?id=467756 Ciencia Al Poder (talk) 11:18, 9 February 2014 (UTC)

If your variables.less is missing some variables, the less compiler will not compile the CSS output properly, and you'll get an error like this:

/*

exception 'Exception' with message 'variable @collapsible-nav-heading-color is undefined:

failed at `ight.woff") format("woff"),` /var/lib/mediawiki/skins/vectorcatalyst/catalyst.less

on line 17' in /var/lib/mediawik/includes /libs/lessc.inc.php:3581

Stack trace:

#0 /var/lib/mediawiki/includes/libs/lessc.inc.php(2125): lessc_parser->throwError('variable @colla...', 351)

#1 /var/lib/mediawiki/includes/libs/lessc.inc.php(1880): lessc->throwError('variable @colla...')

#2 /var/lib/mediawiki/includes/libs/lessc.inc.php(1503): lessc->get('@collapsible-na...')

#3 /var/lib/mediawiki/includes/libs/lessc.inc.php(714): lessc->reduce(Array)

#4 /var/lib/mediawiki/includes/libs/lessc.inc.php(311): lessc->compileProp(Array, Object(stdClass), Object(stdClass))

#5 /var/lib/mediawiki/includes/libs/lessc.inc.php(249): lessc->compileProps(Object(stdClass), Object(stdClass))

#6 /var/lib/mediawiki/includes/libs/lessc.inc.php(223): lessc->compileCSSBlock(Object(stdClass))

#7 /var/lib/mediawiki/includes/libs/lessc.inc.php(719): lessc->compileBlock(Object(stdClass))

#8 /var/lib/mediawiki/includes/libs/lessc.inc.php(311): lessc->compileProp(Array, Object(stdClass), Object(stdClass))

#9 /var/lib/mediawiki/includes/libs/lessc.inc.php(249): lessc->compileProps(Object(stdClass), Object(stdClass))

#10 /var/lib/mediawiki/includes/libs/lessc.inc.php(223): lessc->compileCSSBlock(Object(stdClass))

#11 /var/lib/mediawiki/includes/libs/lessc.inc.php(719): lessc->compileBlock(Object(stdClass))

#12 /var/lib/mediawiki/includes/libs/lessc.inc.php(311): lessc->compileProp(Array, Object(stdClass), Object(stdClass))

#13 /var/lib/mediawiki/includes/libs/lessc.inc.php(249): lessc->compileProps(Object(stdClass), Object(stdClass))

#14 /var/lib/mediawiki/includes/libs/lessc.inc.php(223): lessc->compileCSSBlock(Object(stdClass))

#15 /var/lib/mediawiki/includes/libs/lessc.inc.php(719): lessc->compileBlock(Object(stdClass))

#16 /var/lib/mediawiki/includes/libs/lessc.inc.php(189): lessc->compileProp(Array, Object(stdClass), Object(stdClass))

#17 /var/lib/mediawiki/includes/libs/lessc.inc.php(829): lessc->compileImportedProps(Array, Object(stdClass), Object(stdClass), Object(lessc_parser), '/var/lib/mediaw...')

#18 /var/lib/mediawiki/includes/libs/lessc.inc.php(189): lessc->compileProp(Array, Object(stdClass), Object(stdClass))

#19 /var/lib/mediawiki/includes/libs/lessc.inc.php(829): lessc->compileImportedProps(Array, Object(stdClass), Object(stdClass), Object(lessc_parser), '/var/lib/mediaw...')

#20 /var/lib/mediawiki/includes/libs/lessc.inc.php(311): lessc->compileProp(Array, Object(stdClass), Object(stdClass))

#21 /var/lib/mediawiki/includes/libs/lessc.inc.php(305): lessc->compileProps(Object(stdClass), Object(stdClass))

#22 /var/lib/mediawiki/includes/libs/lessc.inc.php(220): lessc->compileRoot(Object(stdClass))

#23 /var/lib/mediawiki/includes/libs/lessc.inc.php(1927): lessc->compileBlock(Object(stdClass))

#24 /var/lib/mediawiki/includes/libs/lessc.inc.php(1950): lessc->compile('/*?** Catalyst ...', '/var/lib/mediaw...')

#25 /var/lib/mediawiki/includes/libs/lessc.inc.php(2022): lessc->compileFile('/var/lib/mediaw...')

#26 /var/lib/mediawiki/includes/resourceloader/ResourceLoaderFileModule.php(809): lessc->cachedCompile(Array)

#27 /var/lib/mediawiki/includes/resourceloader/ResourceLoaderFileModule.php(719): ResourceLoaderFileModule->compileLESSFile('/var/lib/mediaw...')

#28 /var/lib/mediawiki/includes/resourceloader/ResourceLoaderFileModule.php(692): ResourceLoaderFileModule->readStyleFile('vectorcatalyst/...', false)

#29 /var/lib/mediawiki/includes/resourceloader/ResourceLoaderFileModule.php(321): ResourceLoaderFileModule->readStyleFiles(Array, false)

#30 /var/lib/mediawiki/includes/resourceloader/ResourceLoader.php(812): ResourceLoaderFileModule->getStyles(Object(ResourceLoaderContext))

#31 /var/lib/mediawiki/includes/resourceloader/ResourceLoader.php(546): ResourceLoader->makeModuleResponse(Object(ResourceLoaderContext), Array, Array)

#32 /var/lib/mediawiki/load.php(43): ResourceLoader->respond(Object(ResourceLoaderContext))

#33 {main}

*/

To fix this, make sure you have these defined in your skin's less variables file (usually variables.less) e.g.

@collapsible-nav-heading-color: #4d4d4d; Jonathanischoice (talk) 05:17, 11 September 2014 (UTC)

 05:17, 11 September 2014 (UTC)

Someone on stack exchanged fixed it by modifying $wgServer in LocalSettings.php. Changing the $wgServer from localhost to the static IP of the machine, eg:

## The protocol and server name to use in fully-qualified URLs
 ## $wgServer = "http://localhost";
 $wgServer = "http://123.123.12.12";

Seemed to do the trick for me! This was using version 1.23.5 (latest version as of 10/30/14). 63.241.40.127 19:46, 30 October 2014 (UTC)

Along with the $wgServer = "http://123.123.12.12"; fix, I had to set $wgUsePathInfo = false; also 130.76.32.51 16:03, 5 December 2014 (UTC)

great

replacing localhost with ip address worked for me 93.169.59.159 06:39, 25 January 2015 (UTC)

This worked for me as well!

Remember to copy the trailing semicolon. 131.156.136.195 15:24, 4 May 2015 (UTC)

It works only for short periods of time.

Each time I touch LocalSettings.php it starts working again. 91.209.145.20 11:30, 12 May 2015 (UTC)

That could be because you have a dynamic IP that changes every time you restart your router, or automatically every few hours. Register a dyndns name and use it instead of your IP. Ciencia Al Poder (talk) 20:46, 14 May 2015 (UTC)

Old question, I know, but all solutions as not equal. In my case, I was hosting a personal wiki at my home listening on port 8080 as my residential ISP blocks port 80. It worked fine within my local network, but served no styles when used from the WAN. I had to specify $wgServer = "http://my.domain.com:8080"; in /etc/mediawiki/LocalSettings.php for any external browser to find the style sheets.

(1) Use a dynamic IP service (zoneedit, e.g.) to keep your IP/domain up to date.

(2) Forward the port on which you listen (8080, e.g.) to your internal server (192.168.1.20, e.g.)

(3) Ensure the machines on your local network also resolve the domain name to the server IP internally. This can be as simple as an entry in /etc/hosts (192.168.20 my.domain.com, e.g.) Jnavratil (talk) 14:46, 25 September 2016 (UTC)

I have same problem, but none of early described silutions didnt work for me.

I upgrade my server from Fedora 24 to Fedora 25 and from this time, I cant get mediawiki to display correctly.

I check all recomended settings from https://www.mediawiki.org/wiki/Manual:Errors_and_symptoms#The_wiki_appears_without_styles_applied_and_images_are_missing, i modify .htaccess, change wgScriptPath, wgserver and still the same situation. CSS was ignored due to mime type mismatch

I deploy new virtual machine with clean install of Fedora 25 and install Mediawiki from Fedora repository, made basic settings for Mediawiki and I again get same results. CSS was ignored due to mime type mismatch.

Can anybody advice me, how can I identify problem ? I am totaly frustrated from this situation. 185.86.98.226 (talk) 23:20, 10 December 2016 (UTC)

So, if you open the CSS URL on your browser, can you see the CSS rules there? Is there any error message like a PHP warning? What content-type header is returned for that URL? Ciencia Al Poder (talk) 12:42, 11 December 2016 (UTC)

[RESOLVED] Profiler.php Fatal Error Cannot redeclare wfprofilein()

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I just upgraded the files from 1.17.0 to 1.18.0 and after doing so:

Fatal error: Cannot redeclare wfprofilein() (previously declared in /homepages/2/d276811108/htdocs/w/includes/profiler/Profiler.php:14) in /homepages/2/d276811108/htdocs/w/includes/Profiler.php on line 19

I tried the upgrade on my test install it worked fine. I have no idea what is wrong.

Also PHP is version 5.2.17 (cgi)and MySQL is version 5.0.91-log. Calebrw (talk) 04:53, 3 December 2011 (UTC)

Have you checked your extensions to see if they're updated? I believe Cite and a few others must be downloaded from the REL1_18 area as the trunk is now working on MW1.19. I seem to recall running into that error on an upgrade and it having to do with Cite or another common extension. Varnent 06:06, 3 December 2011 (UTC)

I've also just upgraded from 1.17.0 to 1.18.0 and have the same problem (on a diff line 24 not 19), I tried disabling all extensions but no luck

Fatal error: Cannot redeclare wfProfileIn() (previously declared in /includes/profiler/Profiler.php:14) in /includes/ProfilerStub.php on line 24 Unibond 13:33, 3 December 2011 (UTC)

I'm seeing wfProfileIn errors after upgrading.

Try creating a file at includes/ProfilerStub.php with the following line:

<?php require_once( "$IP/includes/profiler/ProfilerStub.php" );

(From: MediaWiki_roadmap/1.18/FAQ) wargo 13:44, 3 December 2011 (UTC)

I found a file in the mediawiki root folder called StartProfiler.php and deleted it, so far so good, all seems to be working :-) Unibond 13:49, 3 December 2011 (UTC)

I'd be careful deleting core files rather than tracking down the core problem. If for no other reason than whatever is causing the error probably isn't working now anyway and is likely to unnecessarily drain your resources. A good strategy is to disable your extensions one by one (or groups at a time if you have a lot) to locate the source of the problem. Then try downloading the release branch version of that extension, and if still no luck, the trunk release. While some developers only use the trunk release directory, others are already using it to test MW1.19, which is causing problems on MW1.18 installs using SVN to pull from the trunk. Varnent 19:36, 3 December 2011 (UTC)

StartProfiler.php isn't a core file, it is created by the sysadmin if it is needed. A StartProfiler.sample is included, which can be copied to StartProfiler.php. Due to changes in 1.18, a StartProfiler.php from a previous version will be incompatible. StartProfiler.sample was updated, but StartProfiler.php couldn't be updated because it doesn't exist in the distribution.

StartProfiler.php is the core problem. Deleting it gets rid of that problem. Reach Out to the Truth 22:50, 3 December 2011 (UTC)

Thanks for this fix. I completely forgot about that. I had it enabled while trying to fix another problem. Eitherway, it's time to update my extensions. Calebrw 07:37, 4 December 2011 (UTC)

ditto on thanks for the fix. Renamed my StartProfiler.php to .old and the upgrade went as planned afterwards.

-Kevin 67.210.162.194 17:37, 5 December 2011 (UTC)

This works. I renamed startProfiler.php to StartProfiler.php.broke.web.site because my wiki did not work after upgrading from version 18.0 to 18.2 via the Softaculous installer. Then the self-upgrade link worked. Good job. 96.240.15.138 01:21, 2 April 2012 (UTC)

Thanks. Had the same issue with an upgrade from 1.15 to 1.20. Renamed the StartProfiler.php file and everything works great. 67.78.138.82 20:49, 11 January 2013 (UTC)

I had the same problem upgrading from 1.17-1.20. Now works. 195.80.111.234 12:15, 10 May 2013 (UTC)

Fixed it for me! Thanks! 74.57.210.8 17:19, 15 September 2013 (UTC)

Cool thnx, it also worked for me to get rid of the StartProfiler.php by renaming it to something else :) Esenabre (talk) 21:48, 19 January 2014 (UTC)

It would be easier to throw in an empty "startprofiler.php" file in the release.

david 132.72.73.97 07:54, 30 March 2014 (UTC)

It would be easier for people to follow Manual:Upgrading instructions, and not unpack the new files over the old ones. Ciencia Al Poder (talk) 09:47, 31 March 2014 (UTC)

Holy shit this fixed it.

Upgraded from 1.16 to 1.27 via softaculus in cpanel. I can't believe it's that simple. Lord Muffins (talk) 17:45, 7 June 2023 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Adding tags to header in skin?

Hi,

I'm creating a new skin for our wiki since we just updated to the latest version (1.18) of MW.

But I'm having problem adding needed js files for the skin. I've tried using suggested tags @ Manual:Hooks/BeforePageDisplay without any luck. Using the same variant adding a favicon works just fine, but the js seems to be totally ignored.

Any suggestions? Da^MsT (talk) 04:09, 4 December 2011 (UTC)

Resize external image?

How can i resize external images? Anyone could help me??? Nva1991 (talk) 09:31, 4 December 2011 (UTC)

Depending on what you mean by external images - you might be able to use the usual resize settings associated with the image tag or the standard html reset for the HTML img tag. Do you have external images enabled on the wiki you'd like to do this for? Is it another website under your control? If not, you may want to consider downloading the image from their site and uploading it to your wiki to prevent an image error if they happen to delete or move it on their server. Varnent 10:52, 5 December 2011 (UTC)

for example, i want to display a picture in wikipedia.org as thumb, 250px. Could you tell me the code?

Thanks Nva1991 12:36, 5 December 2011 (UTC)

Here is the code you'd use for that: [[File:ImageName.jpg|thumb|250px]]

You may also find this page helpful: w:en:Wikipedia:Picture_tutorial Varnent 19:52, 5 December 2011 (UTC)

To use images from Wikipedia on your wiki, you'll first have to configure $wgForeignFileRepos . Then you can use wikitext to embed them in pages and change their size as Varnent points out. Reach Out to the Truth 20:32, 5 December 2011 (UTC)

If the file(s) you'd like to display from Wikipedia were uploaded to Wikimedia Commons, you can use this setting to do the file repo configuration for you: $wgUseInstantCommons Varnent 22:31, 5 December 2011 (UTC)

Has anyone actually pulled their head out of their ass and explained why <img> just can't be used normally like in HTML? 137.118.185.241 20:01, 11 January 2013 (UTC)

Some PHP servers have blocked use of HTML markup like <img> for security reason, and the main purpose of a wiki is to use wiki markup, not HTML's. LIMAFOX76 (talk) 20:54, 11 January 2013 (UTC)

It can be used, enabling $wgAllowImageTag.

Note that this would allow any arbitrary URL used as an image, so it can be used to load any remote URL to track your visitor's IP address or serve an exploit image. Ciencia Al Poder (talk) 19:27, 12 January 2013 (UTC)

Math formula in wikipedia

How to insert math formulae into wikipedia? I mean "wikipedia" rather that the mediawiki installation supporting MathJax (IMHO preferable) or "Math extension and build the texvc". Victor Ivrii (talk) 14:54, 4 December 2011 (UTC)

See Help:Displaying a formula on Wikipedia. Reach Out to the Truth 23:22, 4 December 2011 (UTC)

Not anymore: The standard $\alpha$ which used to work now is parsed as $\alpha$ (and the same for $\alpha$

Checked with Safari and Firefox Victor Ivrii 00:13, 5 December 2011 (UTC)

Sorry: false alarm: my preferences on Wikipedia were set on TeX output Victor Ivrii 13:07, 6 December 2011 (UTC)

How Can I Add The Languages box on my wiki?

At the end of most help pages here in Mediapedia there is a Languages box which holdings links to the same article in various languages. I have been googling and searching the web for the past few hours trying to find out how I can add that functionality to my own new wiki, without any luck.

I have the following wiki:

elpradowiki.xtreemhost.com

I want this wiki to contain articles in both Spanish and English. I want to do this as simply as possible so I don't mind that the menu and sidebar titles will stay in English. And I don't want to install the wiki twice.

A step-by-step guide on how to do this would be much appreciated! 83.32.187.184 (talk) 11:45, 5 December 2011 (UTC)

There's no simple way to do it. You'd need another wiki. Reach Out to the Truth 15:53, 5 December 2011 (UTC)

Is there any way of doing this? The Language box which is sometimes at the top and/or at the bottom of help pages on this site seems to be implemented without the need for 2 wikis. 83.32.187.184 14:45, 6 December 2011 (UTC)

That's just implemented as a normal template, with normal links (by hand). See Template:Languages for details on how that's implemented.

Technically you can have lang interwikis (aka lang links in sidebar like wikipedia) pointing to the same site, but it'd be a little weird (lang interwikis can point to any url, including the current website). See Manual:Interwiki#Interwiki_links_to_other_languages for details on how that feature works. Bawolff 15:46, 6 December 2011 (UTC)

category link at bottom of page has 'edit' url parameter. How to change?

I put this at the bottom of page: [[Category:My Category]]

And the link that appears on the page is:

.../index.php?title=Category:My_Category&action=edit

So, then if a user visits the category, they are always prompted to login to edit the page. How can I setup the page so that 'edit' url parameter is not present?

Thanks 66.198.167.9 (talk) 15:14, 5 December 2011 (UTC)

The syntax I used to add category to bottom of page got hosed above. I meant, using double square brackets. 66.198.167.9 15:15, 5 December 2011 (UTC)

Upgrade to a newer version of MediaWiki (1.18 being the latest and greatest). A redlink parameter is added to redlinks, which causes the edit form to not be shown if the user following the link does not have the necessary permissions. If you want it to go away for everyone, create the category. Reach Out to the Truth 15:51, 5 December 2011 (UTC)

Semi private Wiki with LDAP

Hello,

i have a question but excuse me for my so poor english... I have a NetWare server with edirectory for the connection in my wiki with LDAP, all is working. I want to know if it's possible to have a "semi-private" wiki, i want to say a wiki with an anonymous access for some articles but not all and restrict creation and edition on all articles. When we are connected with a LDAP user, we can create, edit and view all articles. Thank you. 153.109.6.103 (talk) 16:13, 5 December 2011 (UTC)

2 Locations listed for Wollaston Islands ?

Wollaston Islands - You have 2 different locations listed (Chile & Nunavut)??? Please fix this. 184.146.149.123 (talk) 19:23, 5 December 2011 (UTC)

I believe you're referring to something on Wikipedia rather than this wiki - which is specifically for the software running Wikipedia, MediaWiki. Here's a page that may be more helpful: w:en:Wikipedia:Contact_us/Article_problem Varnent 19:50, 5 December 2011 (UTC)

share templates in a wikifarm

I havea wikifarm and I'd like to default the template namespace on all of them to the main wiki. So using {{thisisatemplate}} would display on every wiki on the wikifarm as long as there is a template with that name on the main wiki. Is that possible? Manual:Shared_database implies it's a really bad idea. Is there a way around it? Modrobene 07:29, 6 December 2011 (UTC)

You can try Manual:$wgEnableScaryTranscluding, but it also has its own issues (but significantly better then trying to share the revision/page table, which will totally not work). There is some work towards a better way of doing this as part of gsoc, but I don't believe it's quite ready yet/included in mediawiki yet. Bawolff 15:49, 6 December 2011 (UTC)

Thanks, I'll try that! Modrobene 17:32, 6 December 2011 (UTC)

Rights only for friends and colleagues

Hello all,

I want to launch a Wiki for some friends and colleagues. I need to give them rights (create pages, edit articles...) after they create their account, but I can't. In fact, all users are allowed to edit and create contents. :(

Here is the end of my LocalSettings.php:

---

# The following permissions were set based on your choice in the installer
$wgGroupPermissions['user']['createaccount'] = true;
$wgGroupPermissions['user']['edit'] = false;
$wgGroupPermissions['user']['createpage'] = false;
$wgGroupPermissions['user']['createtalk'] = false;
$wgGroupPermissions['user']['writeapi'] = false;

# End of automatically generated settings.
# Add more configuration options below.

$wgGroupPermissions['bureaucrat']['createaccount'] = true;
$wgGroupPermissions['bureaucrat']['edit'] = true;

$wgGroupPermissions['emailconfirmed']['edit'] = false;
$wgGroupPermissions['emailconfirmed']['createpage'] = false;
$wgGroupPermissions['emailconfirmed']['createtalk'] = false;
$wgGroupPermissions['emailconfirmed']['writeapi'] = false;

---

Do you know what's wrong? Thanks in advance! Karnabal (talk) 14:59, 6 December 2011 (UTC)

Look at the page Special:UserGroupRights on your wiki. It will tell you which group has which rights, which will probably help you find why some group has rights that it shouldn't. (Also bear in mind, rights are cumulative. $wgGroupPermissions['emailconfirmed']['edit'] = false; means nothing if all users are allowed to edit for example) Bawolff 15:43, 6 December 2011 (UTC)

Take a look at Manual:User rights.

You probably want something like this.

The e-mail confirmed is a bit redundant as the lines in the above link require the user to both have you set their account to 'confirmed' and have confirmed their e-mail address. A confirmed e-mail address by itself will do very little for you, except help to hold back spam because bots will create accounts but rarely confirm them. It does ensure people have email enabled. An alternative is to make it to disable all account creation and create accounts for your friends (though you'd still have to disable anonymous editing and block any current accounts you don't want to allow). The manual will also explain what rights exist with what groups by default, which will avoid lots of unnecessary disabling of rights that groups don't have. Doug.^{(talk • contribs)} 17:11, 7 December 2011 (UTC)

Table instead of grafic surface

Hello, going to the URL of my wiki I get a table of content instead of a grafical surface. Thus nobody can unse his account. This is what it looks like: http://www.nyckelwiki.nyckelharpa.eu/ And this is how it should look like: http://www.cadencewiki.nyckelharpa.eu/ (its a different wiki!) Has anybody an idea? Karsten 217.227.104.113 (talk) 09:53, 7 December 2011 (UTC)

http://nyckelwiki.nyckelharpa.eu/wiki/index.php?title=Hauptseite

Looks like you need a newer version of PHP. Johnduhart 11:06, 7 December 2011 (UTC)

Thanks for the answer.

Should be the same version of PHP in both exambles as they are on the same server. And it worked until a few days before. so there should no downgrade be done. But I will ask anyway.

Karsten 217.227.104.113 12:39, 7 December 2011 (UTC)

Transclude Infobox data; cross-reference infobox data

Frequently, it is useful to reference Infobox data from one wikipedia article in another.

For example, in the table of Pac-12 Members in the Pac-12 conference article:

w:en:Pacific-12_Conference#Full_members

much, if not all, of the data exists in the infobox of the university's article.

What's needed is a way to reference each field of the Infobox data:

for exmaple if something like:

{{University_of_Arizona{{Infobox University|type}}}}

returned:

``Public research university''

then it would be simple to use this as a field in the Full Members table.

any thoughs or suggestions as to how this is, or might be, possible?

Note: though this referes to wikipedia, it is also useful in any mediawiki. CmdrDan (talk) 20:46, 7 December 2011 (UTC)

This functionality can be achieved by using extensions, such as the dynamic page list extension which provides the exact feature you describe, but it is not possible to accomplish this on any public Wikimedia Foundation sites--at least not that I am aware of.    Thorncrag   21:13, 8 December 2011 (UTC)

[RESOLVED] simple url

Since moving my wiki to simple urls, it has started going by default to an article entitled "index.php". i.e. if you go to http://www.theonosis.com, it takes you to index.php instead of the main page. Clicking on the site logo takes you to the main page correctly though. Did I mess up a setting somewhere? I scoured localsettings.php and I can't tell what is wrong. Thanks, Modrobene 22:55, 7 December 2011 (UTC)

It seems you have a rewrite rule problem. Check your .htaccess file with the information here Manual:Short URL/sub directory/wiki/Page Title -- .htaccess Hope this helps. Mlpearc powwow 17:04, 8 December 2011 (UTC)

Thanks, that appears to have fixed it! Modrobene Modrobene 05:43, 10 December 2011 (UTC)

You're welcome, glad to help :) Mlpearc powwow 06:14, 10 December 2011 (UTC)

Ah, I've discovered that that only fixed it for typing in http://theonosis.com. http://www.theonosis.com still redirects to "Index.php". Do you know what might be causing that? Modrobene 15:30, 10 December 2011 (UTC)

Apache cannot resolve Wiki-Url

Hello All,

I am trying to move my wiki-Installation (MediaWiki 1.16) from Suse Linux Enterprise Server (Apache 2.10, PHP 5.2.6, Postgresql 8.3.9) to Ubuntu 10.04 (Apache 2.17, PHP 5.3.5, Postgres 8.4).

Moving the Database and Webfiles proved no Problem.

Maintenance Script (Upgrade.php) showed no errors an the setup-Script running smoothly.

BUT When i´m tryin to access the wiki (the Wiki resides in the documentRoot ) e.g "http://myServer.com/" the Server responds with the URL "myServer.com/index.php5/Hauptseite" and Error 404 and "Not Found The requested URL /index.php5/Hauptseite was not found on his server."

Log files are showing no errors (appart from the Appache error_log).

My impression is that the Wiki resolves the URL correctly to index.php5 and adding the startpage (Hauptseite) but the webserver is treating them like a physical folder.

I checked all *.ini Files but couldnot find, where i am wrong. 195.200.70.50 (talk) 15:30, 8 December 2011 (UTC)

Is index.php5 located in your web root? Does http://myserver.com/index.php5?title=Hauptseite work? Reach Out to the Truth 15:53, 8 December 2011 (UTC)

Yes index.php5 is in my WebRoot.

http://myserver.com/index.php5?title=Hauptseite retuns the index.php5 as a textfile. 195.200.70.50 16:04, 8 December 2011 (UTC)

Apache probably isn't configured properly to use PHP for .php5 files. Does index.php work, or is that rendered as text as well? Reach Out to the Truth 22:59, 8 December 2011 (UTC)

Problem solved. A friend of mine noted a Bug in the Configfile /etc/apache2/mods-available/php5.conf

The Command:

<FilesMatch "\.ph(p3?|tml)$">

ignored php5-scriptfiles. a change to

<FilesMatch "\.ph(p5?|tml)$">

fixed the problem.

Thank you very much. 195.200.70.48 11:38, 9 December 2011 (UTC)

Can't create space after table

I've set up a one-row table which contains an image in the first cell and a bullet point in the 2nd cell next to it. My problem is that no matter how many <br>'s I place after the table, the next line of text appears directly underneath with no white space separating them. I tried inserting a horizontal line and that won't even appear. Can someone tell me what is wrong with my formatting here:

====Terrain Menu====
{| width="100%" align="left" valign="center"
 | width="275px" | [[Image:Terrain Menu.jpg]]
|
*'''Toggles the indicated terrain features on or off'''
|}
<br>
<br>
<hr/>
====Analysis Menu====

Jcseely (talk) 20:12, 8 December 2011 (UTC)

I cannot reproduce this problem. Are you able to post a link to your wiki?    Thorncrag   21:10, 8 December 2011 (UTC)

Unfortunately no, it's on a company intranet. If it helps, the image size is 252x426. Jcseely 21:34, 8 December 2011 (UTC)

Well I guess the best thing to do is find out what HTML or CSS code is causing the space. Firebug would definitely be helpful for that. :)    Thorncrag   16:23, 9 December 2011 (UTC)

HI, same problem here - workaround was to remove align="left"

I guess it messup the css

LC - luis.m.co@gmail.com 109.164.209.249 08:32, 12 September 2013 (UTC)

Turn off $wgCleanupPresentationalAttributes Ciencia Al Poder (talk) 10:46, 12 September 2013 (UTC)

User Page and My Talk Page will not load.

MediaWiki Version: 1.18 URL: http://www.gamerswiki.net Problem: Whenever I load my user page or try and load a My Talk page, I get an error saying that the page failed to load. I talk to my hoster and they told me it was a error in the encoding and that I should come speak you guys, so I'm here. Anyone else having this problem or know how to fix it? 76.200.192.127 (talk) 03:24, 9 December 2011 (UTC)

I did not see any errors. Is it still happening to you? Reach Out to the Truth 05:26, 9 December 2011 (UTC)

They got some help from Tim in the IRC - was a revision committed based on the exchange. Varnent 05:53, 9 December 2011 (UTC)

Upcase???

For example, i 've created "Cushing syndrome" page, but i can't find "CUSHING SYNDROME" page. I want all this page only link to "Cushing syndrome" page but i don't want to use redirect (like normal wikipedia) What should i do??? Thanks a lot Nva1991 (talk) 03:55, 9 December 2011 (UTC)

Sounds like you're looking for this wonderful extension - Extension:TitleKey - which allows the search to be case-insensitive, even though the titles themselves remain case sensitive. This extension is in use on many WMF wikis, including en.Wikipedia Varnent 04:18, 9 December 2011 (UTC)

Note however that the extension only affects the search and will not change case sensitivity of wikilinks; i.e. [[CUSHING SYNDROME]] will not link to to Cushing syndrome without using a redirect. Reach Out to the Truth 05:07, 9 December 2011 (UTC)

Can you instruct me more? I can't set up it. I'm a newbie

• 1, i uploaded titlekey to extension/
• 2, i added the text to localsetting.php
• 3, when i access phpmyadmin, there was a table "titlekey", i deleted it and import the titlekey.sql from the download
• 4, i typed "php maintenance/update.php" in the sql tab, they said :

#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'php maintenance/update.php' at line 1

• What is wrong with me??? Nva1991 05:37, 9 December 2011 (UTC)

Run update.php from a command line on your server, not from PHPMyAdmin. You shouldn't even need to run the SQL file; update.php does that automatically. Now that you've added the table manually, I don't think you need to run update.php. But maybe you still should, just to make sure everything works as expected. Reach Out to the Truth 05:46, 9 December 2011 (UTC)

I don't understand "Run update.php from a command line on your server". What page i have to access? I use a shared host. What should i do next? I use version 1.18

Help me. I'm super noob Nva1991 06:19, 9 December 2011 (UTC)

Anyone helps me please!!! Nva1991 14:17, 9 December 2011 (UTC)

You need to get a host that allows SSH access. Johnduhart 16:55, 9 December 2011 (UTC)

I don't know what SSH access is. I use web hosting of Stablehost.com (stable plan: 5gb disk space). Does it have SSH access? Nva1991 19:24, 9 December 2011 (UTC)

If you have question about your hosting plan or how to use hosting features, you should contact your hosting provider.    Thorncrag   19:38, 9 December 2011 (UTC)

Extensions don't work on Mediawiki 1.15.0 on serfers free.fr.

Hello,

I've installed many extensions, but I'm trying to see why juste one, "cite", doesn't work - others doesn't work too. The folder name is ok : extensions. I put ExtensionFunctions.php in it. All folders and files I put in extensions folder comes from the folder "extensions" of the 1.15 release (http://svn.wikimedia.org/svnroot/mediawiki/branches/REL1_15/extensions/). LocalSettings.php content at least "require_once("$IP/extensions/Cite/Cite.php");" When I go to "Spécial:Version" page I've this:

MediaWiki 1.15.0 - PHP 5.1.3RC4-dev (cgi-fcgi) - MySQL 5.0.83

But not extension.

CHMOD on extensions folder is 700 and owner is "web site" (like others folders and MediaWiki works fine except extensions). I've try to change the path in localsetting.php, but whatever I insert, extensions doesn't work. Any help? What can I test now? Thanks 195.68.89.73 (talk) 10:59, 9 December 2011 (UTC)

Resolved: I put all require_once("$IP/extensions/name/name.php") at the bottom of localsettings.php (it was at the top) and I put at the end of the file "$wgShowExceptionDetails = true;". PepeLePew 11:31, 9 December 2011 (UTC)

Does anyone know a good tutorial on how to install infoboxes?

I'm trying to install infoboxes to my MediaWiki, but I am having trouble installing it. I have found multiple guides all with different methods, different common.css, and different well, everything. I'm looking for one that works and easy to follow. 76.200.192.127 (talk) 00:22, 10 December 2011 (UTC)

I don't know of any tutorial but, if you get stuck I can try and help, I've done a couple. Mlpearc powwow 06:12, 10 December 2011 (UTC)

Played around with one of these at: Manual:Importing Wikipedia infoboxes tutorial Varnent 06:09, 5 January 2012 (UTC)

#ref_ in Wikipedia:Template:Note

I give up. What, where, how does this 'mechanism' work? Schalice (talk) 03:19, 10 December 2011 (UTC)

Are you trying this on Wikipedia or a third-party MediaWiki installation? If just on Wikipedia, you may want to try that template's talk page for assistance. Generally this is a place for supporting the MediaWiki software that Wikipedia runs on. Varnent 03:28, 10 December 2011 (UTC)

The mediawiki note template is different. I am somewhat new at this but am going to guess that wikipedia has some proprietary parser similar to Extension:Ref that handles #ref_ ? Schalice 05:53, 10 December 2011 (UTC)

Sorry - meant the talk page on Wikipedia - my bad.  :) Try this link instead. Wikipedia does not have any proprietary software of any kind. It's all available via this website. Looking at that template, it looks like a basic link format. What are you trying to do with it? Are you trying to use the <ref> tag? If so, that relate to citations, which you can find out more about here and here. Varnent 06:09, 10 December 2011 (UTC)

{{ref}} and {{note}} work together. {{ref}} is used in the body of your articles, and {{note}} is used in a references section.

Proper use of those templates requires you to understand how they work, and be willing to maintain them because. My advice: don't bother. I find the Cite extension to be slightly less infuriating. It is used more often on Wikipedia than the Ref and Note templates are, so that's probably what you're really looking for. Reach Out to the Truth 06:16, 10 December 2011 (UTC)

several wikis stopped working spontaneously

I've got several wikis that have worked fine for a few weeks now. They were working fine earlier today, and now all of a sudden they don't. All but one says this: MediaWiki internal error./Exception caught inside exception handler./Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information. so I did that and get this error: Parse error: syntax error, unexpected $end in /home/argument/public_html/w/LocalSettings.php on line 139. Except for one of the wikis, which has a completely different error message: [1] Something similar happened awhile ago but the sites started working again randomly. What's going on? (other wikis not working: one, which is basically a bare installation I've barely used, this one, this one, this one and this one. Modrobene 06:15, 10 December 2011 (UTC)

Now they all started working again, while I was asleep and didn't change anything. Can someone please help? This is the second time they have stopped working and then come back. I need to figure out what's going. Modrobene Modrobene 15:28, 10 December 2011 (UTC)

It's unusual for software to shift from working to not working to working again like that without some outside variable involved. Are you on a wikifarm? Is this a shared hosting environment? Was the wiki installed with third-party software like Softaculous? Also, what extension or variable are you mentioning on line 139 of your LocalSettings.php file? Varnent 22:46, 10 December 2011 (UTC)

No, not a wikifarm. Yes, it's a shared hosting environment. I installed it myself, not using Softacular. Line 139 is the one that says "End of automatically generated settings.", which I deleted and retyped myself, and when I removed it completely, it shifted the error message to indicate whatever the last line of localsettings.php was (which was blank). Modrobene 23:26, 10 December 2011 (UTC)

My initial guesses would be to check your .htaccess settings and possibly try enabling $wgUseTidy. Are you using profiling or have a StartProfiler.php file in your root folders? Varnent 00:16, 12 December 2011 (UTC)

htaccess settings seem to be fine, but then everything's working at the moment. I'll check next time it happens, and I'll look into the UseTidy (this latest problem did occur at the same time as some html using spambots, but the sites came back on their own with the same html still there). Unless profiling is something I might have done accidentally, I am not using it. Thanks! Modrobene 05:27, 12 December 2011 (UTC)

The second error (unexpected $end, yadda yadda) sounds like when you added that line to LocalSettings.php, you forgot a semi-colon (or removed the closing */ of a comment, or some other syntax error was made).

The first error (Mediawiki Internal Error) is really hard to debug without the $wgShowExceptionDetails = true; However, it is unlikely to be caused by lack of html tidy (Which fixes html errors) or stuff wrong in a .htaccess file (which gives a different type of error message - typically an apache generated 500) Bawolff 00:43, 14 December 2011 (UTC)

Okay, thanks a lot! Modrobene Modrobene 06:34, 16 December 2011 (UTC)

Page views randomly fell

I was on the main page of my wiki, which showed seven thousand something views. 5 minutes later, the views fell to 75! Please help. MEDIAWIKI 1.17.1, PHP 5.2.17, MYSQL 5.0.91 My site is fakeapedia.org. Parth.thepro (talk) 21:47, 10 December 2011 (UTC)

Why does that seem only fitting?    Thorncrag   17:17, 12 December 2011 (UTC)

Did you make any changes to your database or run any maintenance scripts? Varnent 17:30, 12 December 2011 (UTC)

I cannot connect to my Media Wiki

Hi support

I have a problem. All was fine since 2 weeks and now i can not connect to my Media Wiki. And i am its Admin.

When i try to log in, i got a message like "Your Wiki use cookies for connection but you disabled them. Please enable them and try again loging."

But i don't have disabled cookies. I have checked, they are activated... Can you help me please ? Thanks 92.161.15.46 (talk) 02:40, 11 December 2011 (UTC)

I cannot connect to my Media Wiki

Hi support

I have a problem. All was fine since 2 weeks and now i can not connect to my Media Wiki. And i am its Admin.

When i try to log in, i got a message like "Your Wiki use cookies for connection but you disabled them. Please enable them and try again loging."

But i don't have disabled cookies. I have checked, they are activated... Can you help me please ? Thanks 92.161.15.46 (talk) 02:40, 11 December 2011 (UTC)

The wiki is this one : http://atcac-wiki.free-h.net/index.php?title=Accueil Nethervoid 02:49, 11 December 2011 (UTC)

I tryed that solution : Project:Support desk/Flow/2010/09#c-66.201.56.150-2011-03-31T18:07:00.000Z-174.113.146.186-2011-03-25T01:21:00.000Z

It works, but i guess there is a hard security problem, isn't it ? 92.161.15.46 03:51, 11 December 2011 (UTC)

>but i guess there is a hard security problem, isn't it ?

Well just do the same thing, but put the directory somewhere that isn't browsable by randoms from the web. Or at the very least put a .htaccess in that directory to make anyone who tries to browse it get 403's. Bawolff 00:47, 14 December 2011 (UTC)

thank you 92.161.180.73 12:35, 15 December 2011 (UTC)

[RESOLVED] Add reply link to signature tildes template?

Resolved: Also added to FAQ

MediaWiki version: 1.16.5 PHP version: 5.3.2-1ubuntu4.10 (apache2handler) Database version: MySQL 5.1.54-rel12.5-log

Wiki URL: http://bloons.wikia.com/wiki/Bloons_Wiki

Is there any way to add a "Reply" link to the signature tildes template on individual talk page discussions? I would like it to link directly to a reply on that discussion's author's talk page. Is it possible? Juicestain09 (talk) 04:59, 11 December 2011 (UTC)

You can customize at mediawiki:Signature/mediawiki:signature-anon (for example, put it as [[{{ns:user}}:$1|$2]] ([[{{ns:user_talk}}:$1|talk]]) will put a link to people's talk pages. People can change it on a per user basis in their preferences) Bawolff 18:48, 11 December 2011 (UTC)

Or better yet something like [[{{ns:user}}:$1|$2]] ([{{fullurl:{{ns:user_talk}}:$1|action=edit&section=new}} Reply]) would give a more direct link. Bawolff 22:34, 13 December 2011 (UTC)

Almost Similar Page Titles Help / Question

Hello,

I have just started my first Wiki but I am a little confused by something, say for example I am writing an article - something like:

"Trees are found worldwide, without them the world would be a very different place.

Then my new page will be Trees yes.

The thing is, if someone searches for tree (singular) or even trees (small letters) it doesn't come up with anything. Does this mean a similar page should be created for each variation of a word or is there a word to catch all similarities?

Thanks in advance. 86.29.245.169 (talk) 20:14, 11 December 2011 (UTC)

If we're talking only about search, and not people entering a page name directly, then there is an extension for addressing case sensitivity in searches - Extension:TitleKey.

You may also want to enable $wgEnableMWSuggest to allow search suggestions - which can help with singular vs plural.

Keep in mind that the MWSuggest and Titleykey will not address variations in wikilinks - so TREES may go to Trees via the search, but [[TREES]] will be a redlink. Redirects can be used for common variations (singular vs plural as one example) where a page title may be used directly in things like the URL or wikilinks. Varnent 00:07, 12 December 2011 (UTC)

Category Sorting after update

After updating from MW16.5 to MW17 it seems that the sorting in category pages is broken. There is one article that sorts under A, because I have edited and saved that article. All other untouched articles are not sorted on that category page, but appear under "D". Any suggestions?

I already have run maintenance/populateCategory.php and /maintenance/RefreshLinks.php without success. Is there maybe any extension, that would touch or save each article that exists in the wiki?

Thanks a lot in advance Francishunger (talk) 22:51, 11 December 2011 (UTC)

Well, a rather unorthodox solution to a rather individual problem: I installed the Replace Text extension and replaced in each article a space with a space. That process touches all articles with a minor edit and thus sorts them under their categories alphabetically as needed. Francishunger 22:46, 12 December 2011 (UTC)

Clever solution to what I'll admit is an unusual problem. I had been scratching my head at this one. Glad you were able to sort it out!  :) Varnent 23:24, 12 December 2011 (UTC)

For reference, it sounds kind of like you needed to run updateCollation.php, possibly with the --force option. (This should have automatically been run during update.php though).

Although D is a kind of weird letter for it to all sort under... so maybe something else was going on. Bawolff 00:32, 14 December 2011 (UTC)

Thanks Bawolff for the reply. Next time ...  ;) Francishunger 17:50, 21 January 2012 (UTC)

Same problem here. [edited] Subfader (talk) 22:51, 25 October 2014 (UTC)

Ok, I thought I could fix this meanwhile, but luck.

I update dfrom 1.16 to 1.22.12 and the sorting is wrong as new pages sort before or inbetween the old ones.

The problem is I have 200k affected content pages. updateCollation.php and refreshLinks.php (forced) didn't help. I cannot let ReplaceText run over these at once since they are too many to preview. I could use offset inside the extension on each chunk but still... The extension breaks on ~ 750 preview items with "You must select at least one namespace".

Isn't there a proper solution? :( Subfader (talk) 01:11, 26 October 2014 (UTC)

Strange user accounts created

Hi, Lately, many new strange/akward accounts are created on my wiki (version 1.15.1). For example the users with account/user names:

Nealshcame Latashamrf Tommiecden Jermainesq Juliorqter Samanthaer Reynahbane Glennaazul Loboutinlobouti Cheapnhl Tiffanydiscount Northwomens

these users do not (yet) contribute. Is this a security risk? How to avoid this? Please reply! Gert 130.89.66.201 (talk) 11:04, 12 December 2011 (UTC)

Those accounts are most likely created by automated bots looking for sites to spam. You should take a look at Manual:Combating spam and specifically the CAPTCHA section for direction on preventing unwanted account creation.    Thorncrag   17:11, 12 December 2011 (UTC)

Sidebar invisible for not logged in users

How can I make the sidbar navigation invisible for users that aren´t logged in?

I searched on the net for a while now but I can´t find anything related...

Thanks for your help! 194.95.73.4 (talk) 09:16, 13 December 2011 (UTC)

You may want to check out Extension:HideSidebar - which also has a link to some non-extension solutions. Varnent 01:09, 3 January 2012 (UTC)

Outpage->parser

I have a problem. It is necessary to parse the wiki on the crown, but that the method can not attach parser, or is not correct. In general prolema

а ещё лчше по-русски 95.84.231.104 (talk) 21:09, 13 December 2011 (UTC)

collapsiblenav does not appear in new skin based on vector

MediaWiki 1.16.4 PHP 5.2.17 (cgi-fcgi) MySQL 5.1.53-log

UsabilityInitiative (Version 0.1.1) (Version 80586) Vector (Version 0.2.0) (Version 80586)

i am setting up a new skin, which is based on the Vector-Skin. It's named VectorModified, i followed: Manual:Skinning/Vector but did not change $IP/resources/Resources.php, as in the discussion is written, that this step is not necessary.

Now to the problem: In my new skin the left navigation is not collapsing, in the default skin (vector) it is. If i replace the orginal main-ltr.css by the new one and use as skin the original vector (and not thr modified one), the navigation is collapsing with the appereance of the modified main-ltr.css.

So the issue is not some wrong code in the css-file.

How can i tell the media-wiki to approve the collapsiblenav on the skin VectorModified?

Thanks a lot! 82.113.99.69 (talk) 10:57, 14 December 2011 (UTC)

I have this same problem. 99.225.109.54 22:33, 5 February 2012 (UTC)

Special:SpecialPages is blank

Versions: - Mediawiki 1.17 - PHP 5.2.17 - MySQL 5.1.58 URL: http://gridirondigest.info

---

Problem: Special:SpecialPages is blank.

I pasted: error_reporting( E_ALL ); ini_set( 'display_errors', 1 ); into LocalSettings.php

Upon reloading Special:SpecialPages, I get this error:

- "Fatal error: Cannot redeclare class UploadForm in /var/www/web3/web.old/includes/specials/SpecialUpload.php on line 750 "

SpecialUpload.php Line 750 is: class UploadForm extends HTMLForm { ... ... 96.31.202.27 (talk) 11:10, 14 December 2011 (UTC)

Is this issue still occurring? I visited http://gridirondigest.info/index.php/Special:SpecialPages and it appears to be alright. Varnent 01:10, 3 January 2012 (UTC)

How to solve this problem? my wiki special page is blank too. 116.197.5.118 11:48, 7 January 2012 (UTC)

Does the issue occour when you disable all extensions? Bawolff 16:23, 7 January 2012 (UTC)

The Website Activating Evolution

Hi! I have a problem with a website that is simply moving too slow! It takes over a minute for even one page to load, causing major traffic problems. Hardly anyone can even get in to look at different pages or edit!

http://theories.activatingevolution.org/swiki/wiki/index.php/Category:Anomalistic_Abilities (A website affiliated with the TV series Heroes; the name is Activating Evolution)

These are the versions the website has.

MediaWiki: 1.9.3

PHP: 5.2.6 (apache2handler)

MySQL: 5.0.28-enterprise-gpl-log

I personally am not the owner of the website, but it is nearly impossible to get into contact with them, and so I thought to ask the question myself.

Is there some solution, some plan of action that I personally can take to help improve the website's load time, so that I and others may rejoin the website?

Thanks in advanced. RandyS0725 (talk) 14:47, 14 December 2011 (UTC)

Are you saying that you are not the server administrator? If you aren't the administrator there is nothing you can do unfortunately.    Thorncrag   16:29, 14 December 2011 (UTC)

Well...do you know of a way I could get into contact with the administrators there? I'm not quite sure where I'd find the email address to contact them. RandyS0725 18:57, 14 December 2011 (UTC)

The Project:About page might give you some useful info. Otherwise perhaps look up the domain info for a tech contact.    Thorncrag   23:21, 14 December 2011 (UTC)

cannot upgrade to 1.18 from 1.17 - APC issue

Yesterday I tried to upgrade from 1.17 to 1.18. It wasn't 100% clear how to do this given that there was a warning not to install 1.18 over previous installs, so I downloaded 1.18, unpacked it to a new folder, deleted my old 1.17 (backing the folder up first) and copying all of 1.18 over to the wiki directory. Running the upgrade script got me this error:

CACHE_ACCEL requested but no suitable object cache is present. You may want to install APC.

Backtrace:

1. 0 [internal function]: ObjectCache::newAccelerator(Array)
2. 1 /home/liquidfr/public_html/lf_wiki/includes/objectcache/ObjectCache.php(62): call_user_func('ObjectCache::ne...', Array)
3. 2 /home/liquidfr/public_html/lf_wiki/includes/objectcache/ObjectCache.php(50): ObjectCache::newFromParams(Array)
4. 3 /home/liquidfr/public_html/lf_wiki/includes/objectcache/ObjectCache.php(23): ObjectCache::newFromId(3)
5. 4 /home/liquidfr/public_html/lf_wiki/includes/GlobalFunctions.php(3600): ObjectCache::getInstance(3)
6. 5 /home/liquidfr/public_html/lf_wiki/includes/Setup.php(402): wfGetMainCache()
7. 6 /home/liquidfr/public_html/lf_wiki/includes/WebStart.php(157): require_once('/home/liquidfr/...')
8. 7 /home/liquidfr/public_html/lf_wiki/index.php(53): require('/home/liquidfr/...')
9. 8 {main}

I tried installing APC but as it turns out my VPS runs on something called suPHP and I need to change the handler, which I don't know enough about to be comfortable with. Can someone help me out here? Thanks! Liquid.fractal (talk) 15:25, 14 December 2011 (UTC)

Also seen when upgrading from mediawiki 1.17 to 1.18

With settings :

$wgMainCacheType = CACHE_ACCEL;

$wgMemCachedServers = array(); 188.126.75.120 22:39, 14 December 2011 (UTC)

Actually, my thanks to whoever replied to my post; I switched $wgMainCacheType to CACHE_ANYTHING and the upgrade worked fine. Liquid.fractal 23:38, 14 December 2011 (UTC)

I had the same issue, and used the above fix and I was able to upgrade. However, once I restore the setting to $wgMainCacheType to CACHE_ACCEL, the problem comes back. Does setting $wgMainCacheType to CACHE_ANYTHING stop mediawiki from using the PHP accelerator? I have XCache 1.3.1 installed. Jedicraft 17:32, 15 December 2011 (UTC)

Yes, $wgMainCacheType = CACHE_ACCEL; means use either APC, XCache or WinCache. If you don't actually have such a program installed, MediaWiki will error if you try to force it to use such a program. CACHE_ANYTHING means mediawiki will auto-detect what type of cache you have. If all else fails, it will cache things in the db (which might actually be slower then not caching stuff at all. The default config is to have $wgMainCacheType set to CACHE_NONE, but the parser cache and message cache [which cache expensive things] to use CACHE_ANYTHING) Bawolff 21:35, 19 December 2011 (UTC)

CACHE_ACCEL is documented as working with eAccelerator. However, I am getting this same error with eAccelerator installed, when this setup worked perfectly in 1.17.1. Was eAccelerator support dropped in 1.18? Maiden taiwan 14:32, 19 January 2012 (UTC)

Its dropped in 1.19. However, certain versions of eAccelerator do not work with any version of MediaWiki. Bawolff 00:19, 25 January 2012 (UTC)

try installing php-apc and restarting Apache. In Fedora, the package name is php-pecl-apc. 173.77.16.94 15:04, 9 April 2012 (UTC)

I have the same problem but APC is running!

In apc_cache_info() i can see some files from other scripts.

Why does Mediawiki doesnt find APC? 89.14.214.59 13:04, 10 January 2013 (UTC)

Please, do not ask new questions in old threads. Create a new thread and:

• Provide the MediaWiki version you're using.
• Paste the stack trace of the error (with $wgShowExceptionDetails enabled). Ciencia Al Poder (talk) 13:54, 10 January 2013 (UTC)

Broken "next 200" link on category page?

I think this issue arose when upgrading from 1.16.1 upgrading to 1.18.0...

A user noticed than none of the "next 200" links work on my category pages

example: http://www.fraternityofshadows.com/wiki/Category:NPC

If you click on "next 200" it just goes back to the same page.

Tried to debug a bit myself, but I'm a novice in php. I did notice that the link leads to: http://fraternityofshadows.com/w/index.php?title=Category:Year&pagefrom=492+BC#mw-pages

yet the keyword "pagefrom" doesn't appear anywhere in my installation, according to a recursive grep.

Any way to fix this?

Ron admin@fraternityofshadows.com 135.245.10.2 (talk) 16:21, 14 December 2011 (UTC)

digging further... "pagefrom" doesn't appear because it's built up from "page" and "from" within includes/CategoryPage.php. It appears that my problem is due to something going wrong in the neighborhood of the doCategoryQuery function in that file. I see by comparing to my old 1.16 installation, that things have changed a bit there. This is apparently where the mySQL database is queried and sorted to find the next page to start from.

Is there perhaps some update needed to the mySQL database structure that the update script failed to do?

The old lines here had:

array( $pagecondition, 'cl_to' => $this->title->getDBkey() ),

while the new has this:

array_merge( array( 'cl_to' => $this->title->getDBkey() ), $extraConds),

could that be the reason for the issue I'm having? I don't know enough about php or MySQL to know exactly what's going on here, but it looks like this is the area of the code in question, and the only reason I could see it not work for me is if the code doesn't match the database somehow. Any experts have a better idea? Thanks.... 74.102.75.98 19:52, 20 December 2011 (UTC)

Upgrading from 1.16 took heavy database changes esp. to categories. I think you can run maintenance/update.php at any time tho. Subfader 10:07, 21 December 2011 (UTC)

Thanks, I just ran maintainence/update.php again as you said, and it didn't do much. It spit out a lot of "___ is already ___", "___ already exists" and "____ doesn't exist" messages, and the problem persists. Is there any other script I might need to run in maintainence that would fix up the category links or whatever is messed up here? Any way to verify my database is truly in the right format? If the database is in the right format, and the MW installation is up-to-date, what else could be wrong? 74.102.75.98 19:14, 21 December 2011 (UTC)

That's an odd issue.

I had a look at the api output for your site ([2]) and it outputted things the way they're supposed to look. If it was a db issue, the output would probably look wrong for the api (sortkeyprefix being "" is normal in that api output in case you're wondering).

What seems to be the problem is that the category page is just not responding to url parameters. However, it is responding to the older url parameters for categories [3].

Theory 1:

Wrong version of CategoryTree. Older versions of Category tree break categories in weird ways on newer mediawiki. Make sure you have the version of CategoryTree that goes with MediaWiki 1.18. If you're not sure, temporarily disable that extension, see if the categories fix themselves, that way you could rule it out if its being caused by that extension.

Theory 2

Maybe One of the files in your install was not updated properly (although, if that happened I'd imagine more things would be broken). Could you check that includes/CategoryPage.php in your install is exactly the same as the official version - http://svn.wikimedia.org/svnroot/mediawiki/tags/REL1_18_0/phase3/includes/CategoryPage.php (especially the closeCategory method ) [However, check the categorytree thing first]. Bawolff 23:04, 22 December 2011 (UTC)

Wahoo!!! Thanks, Bawolff. Updating CategoryTree did the trick. I had the 1.15 version, and since it was "working" (in that I could see the categoryTree ajax buttons and they expanded correctly), I didn't think I needed to upgrade it. I never thought that it could cause trouble elsewhere on the page.

Many, Many, Many thanks... 74.102.75.98 21:41, 26 December 2011 (UTC)

Hi, I have the same problem,but I can't find where to disable CategoryTree. Can you guide me where I can find it?

Am i required to backup before disabling CategoryTree? Noham100 (talk) 05:36, 12 March 2014 (UTC)

Comment or remove the line that includes the extension CategoryTree in your LocalSettings.php Ciencia Al Poder (talk) 10:51, 12 March 2014 (UTC)

Special Pages aren't accessible

I'm the Admin in [BilderWiki]. I've installed Media Wiki 1.18, the current version. My problems are the Special pages like [bilderwiki.kilu.org/index.php/Spezial:Spezialseiten this]. What's wrong?--Das Schäfchen Das Schäfchen (talk) 17:56, 14 December 2011 (UTC)

I checked out the page and it says you've exhausted your memory limit.

If your configuration allows it, you can put a line as follows in your .htaccess file to increase the memory:

php_value memory_limit 64M

Or if you want to change it globally, modify the line in your php.ini file:

memory_limit = 64M;

Lastly, if neither of those are options, in your LocalSettings.php, you can try adding this at the top:

ini_set('memory_limit', '64M');

Unifiedrepublic 20:28, 14 December 2011 (UTC)

Updating CSS

MediaWiki version 1.15.2 PHP 5.3.5 (apache2handler) MySQL 5.1.54 site is www.climatewiki.org

I am new to MediaWiki but have to make some changes to the CSS pretty quickly -- our logo is missing! The person who managed our site beforehand is no longer accessible to us and did no training. Don't really know where to begin. I know CSS well, but how do I find the right stylesheet/skin and get it uploaded to our server? Or is there a "special page" on which I can access and change the skin? Didn't see on thee ... 67.103.199.9 (talk) 23:16, 14 December 2011 (UTC)

Your question might be addressed in the FAQ if the default setting for the logo was not changed. If it has, you might want to use a tool such as Firebug to examine the output of the page to determine the setting for image location of the logo. That could also help you determine where the CSS is originating - whether a file or a page on your wiki. Although looking at your wiki, I can't tell if your logo has been found or not. It's set to http://www.assimil.com/img/front/globe.png    Thorncrag   19:21, 16 December 2011 (UTC)

Thanks for the response, sorry I didn't see it until today.

This is the WRONG logo image. Just don't understand how to correct it. 67.103.199.9 21:08, 21 December 2011 (UTC)

Registration emails not received consistently

Versions 1.17.0, 5.2.17 (cgi-fcgi), MySQL 5.1.57-log, CSS. http://www.westerly-owners.co.uk/westerlywiki

We are not receiving registration emails consistently although Wiki says it sent them and the address is correct. Some we have received but not always. If we register and go to preferences and change the email address we do receive a notification of the change at the changed address and when we change back to the original address that too generates correctly an email at the old address.

Any ideas? WesterlyWiki (talk) 09:21, 15 December 2011 (UTC)

This is a longshot, but is your Manual:$wgEnotifUseJobQ set to true?    Thorncrag   19:39, 16 December 2011 (UTC)

Thanks for suggestion Thorncrag will check. Assume if Manual:$wgEnotifUseJobQ set to false emails will be sent straight away with out going on the Q? WesterlyWiki 00:12, 17 December 2011 (UTC)

How can I teach an extension the function: includeonly?

Hello! I use Mediawiki 1.17 with the extension Improved Access Control.
Now I want to use this Code: <accesscontrol>Group</accesscontrol> with a template.
The problem is, the extension don´t understand <includeonly>, which is needed.
How can I teach an extension this function "includeonly" ?
Perhaps with putting a code in a file of the extension? The question is which code in which file?

I love you, if you can help me ;-) Speedtook (talk) 16:25, 15 December 2011 (UTC)

register new user

I have installed the wiki today. But I can't find a way to give visitors a link by wich they can register on the wiki. In the corner on the right side is a link to log in. But if you have no login-name no opertunity is given to register. How can I change this? O. Kamer O Kamer (talk) 18:33, 15 December 2011 (UTC)

Special:UserLogin/signup. There should be a link on the login form.

If you are using 1.18 (which you should be), set $wgUseCombinedLoginLink to to false. That will split "Log in / create account" into two separate links: one for logging in and one for creating an account. Reach Out to the Truth 18:50, 15 December 2011 (UTC)

Trying to understand all the helppages I see those instructions $wgUseCombinedLoginLink. But how can I do that? Where can I find how to work with such instructions? O Kamer 18:57, 15 December 2011 (UTC)

At the bottom of LocalSettings.php add:

$wgUseCombinedLoginLink = false;

Reach Out to the Truth 19:44, 15 December 2011 (UTC)

I have done that but it makes no change. See my page at http://www.stamboom-kamer.nl/TNG_genealogie/mediawiki.

Thanks for helping so far. O Kamer 19:54, 15 December 2011 (UTC)

Unregistered users do not not have the right to create accounts on your wiki. You likely have $wgGroupPermissions['*']['createaccount'] = false; somewhere in your configuration. Remove it. Reach Out to the Truth 20:13, 15 December 2011 (UTC)

Thank you very much, the problem is solved. O Kamer 20:19, 15 December 2011 (UTC)

I'm having the same problems. I want to implement the same advice but don't know where/how to get to LocalSettings.php nor am I sure what you mean by somewhere in your "configuration." Is "configuration" a general or specific term? Thanks. Johnpalfreyman (talk) 20:53, 7 May 2014 (UTC)

I'm having the same problem but don't know how to implement the solution. Where do I find LocalSettings.php and what do you mean by "configuration?" Is that a general or specific term? Thanks. Johnpalfreyman (talk) 20:55, 7 May 2014 (UTC)

Hi John!

I have just recently added this information to Manual:LocalSettings.php. The information there should help you find the file on your server! 88.130.76.179 21:38, 7 May 2014 (UTC)

Thank you I found it! johnpalfreyman 19:04, 9 May 2014 (UTC)

Various issues with customizing

I'm having a series of issues with my MediWiki customization. I'm using the gumax skin, and currently putting everything together offline using MAMP, so I'm not sure if this is causing any issues. I'm also transferring setting from old LocalSettings.php file (running on older mediawiki installation) to new LocalSettings.php file (runnung 1.17 installation).

Issue 1: I hard-coded a log-in link into a new navigation menu, and it points to /index.php?title=Special:UserLogin . When I login, the page redirects to /index.php?title=Special:UserLogin&action=submitlog in&type=login , but this page is blank. I have to manually go back to index.php/Main_Page to see the content of site. Any ideas on a fix for this?

Issue 2: /mediawiki/index.php link doesn't show default homepage. I have to navigate to index.php/Main_Page in order to see homepage.

Issue 3: The {{TOClimit|limit=2}} Table Of Contents limit template is not working for me. All the subheadings are appearing.

Issue 4: Once logged in and click on the My Preferences link, there are no tabs for customization on the following page. I've attached a file that shows what I'm talking about.

Screenshot of Preferences error

Thanks for the time and help in troubleshooting. I have done some initial research through Google, but haven't been bale to find any solutions. MediaWiki is beyond my area of expertise, but I would like to know how to fix these crucial errors. Optimus203 (talk) 21:24, 15 December 2011 (UTC)

1. When you say blank screen, do you mean the entire browser screen blanks out? If so, you should check your webserver logs to see if it spit out an error.
2. Sounds like an issue with .htaccess. See Manual:Short URL and Manual:FAQ.
3. I'm not familiar with this template. Is it possible it requires an extension like ParserFunctions?
4. Sounds like a skin issue... sorry, can't think of much else. Does it work with another skin?

Are you able to provide a link to the wiki? (P.S., withheld from any obscure John McLaughlin references)    Thorncrag   19:35, 16 December 2011 (UTC)

Load is going high (beyond 5)

Hi there, I am experiencing a problem on my wiki (tibiawiki.com.br). It receives 50k unique accesses per day: MediaWiki 1.16.1 PHP 5.2.16 (apache2handler) MySQL 5.0.92-community

It is currently "closed" with a password, and everytime I open the load goes to 5+.

What information do you need to help me?

In my localhost I have this line: $wgJobRunRate = 0.01;

I really appreciate any help, my wiki is closed until I find a solution. Wdfelippe (talk) 23:29, 15 December 2011 (UTC)

I have no idea what you mean by "load goes to 5+", but the following links that might help performance tuning:

• http://mituzas.lt/2007/01/26/mediawiki-performance-tuning/
• User:Aaron Schulz/How to make MediaWiki fast Bawolff 21:22, 19 December 2011 (UTC)

Thank you, Bawolff, I`ll see if it can help Wdfelippe 13:50, 20 December 2011 (UTC)

How-to change name of the "Talk" namespace?

Hi! I've own Wiki based on MediaWiki engine and thinking about globally change the "Talk" (NS_TALK) namespace to "Journal". It is possible to change the built-in "Talk" namespace to other name?

Thank you in advance for your help and any suggestions. Danny373 (talk) 07:28, 16 December 2011 (UTC)

I am not entirely sure about renaming the talk namespace, but what is your goal? If you just want a namespace for some kind of journal, it would be much more advisable to simply create the new namespace. If you want a tab for "Journal" to appear next to the talk tab, you can add that fairly simply, using something like jQuery.    Thorncrag   19:01, 16 December 2011 (UTC)

You can change how the talk namespace is displayed by creating mediawiki:nstab-talk (for just the main talk namespace) or editing MediaWiki:Talk (if you want to change _all_ talk namespaces). Bawolff 21:18, 19 December 2011 (UTC)

Thorncrag, thank you for your help. You wrote:

> what is your goal?

Originally, I wanted to create a new tab next to "Comments" tab. Just as it is done (or similar) on tne WikiNews site - see "Opinions" tab. It had previously been asked about this in my another thread, but unfortunately did not get answers and any solutions.

> If you want a tab for "Journal" to appear next to the talk tab,
> you can add that fairly simply, using something like jQuery.

I tried to do so as indicated, but the new tab is located (jQuery code puts it) in the <div id="p-views" class="vectorTabs"> section ("Read"|"Edit"|"History" tabs) not in the <div id="p-namespaces" class="vectorTabs"> section ("Article"|"Discussion" tabs).

Because it's so hard to make a new tab, the only solution is to change "Comments" tab to the "Journal" tab in my case. Danny373 20:35, 20 December 2011 (UTC)

btw, Wikinews js for the comments tab is at n:en:MediaWiki:Comments.js . Try just copying that to your mediawiki:Common.js (note, on wikinews named comments.js but on your wiki you have to put it on Common.js) Bawolff 22:05, 20 December 2011 (UTC)

@Bawolff, @Thorncrag: Many thanks to you!

I created a new namespace (by Thorncrag idea) and adapted the "Comments.js" script (by Bawolff idea) from the WikiNews page to my Wiki. And... it works very well! :-)

BTW, I found a small bug in their script.

Best Regards, Danny373 22:16, 21 December 2011 (UTC)

BTW, If you really wanted to change the name of the namespaces, as opposed to merely how they display on the tab, it could be done in local settings for any custom namespaces and I'm pretty sure you could change the standard namespaces the same way - or you could set aliases. Then you could use /wiki/Journal:Foo in the address bar and [[Journal:Foo]] in links (in place of [[Talk:Foo]] and similarly for the talkspaces that correspond to namespaces other than main, thus [[Bar journal:Foo]] for the talk page of for Foo in the Bar namespace). In this case you would have all odd numbered namespaces with "journal" in the name in place of "talk". An alias would be best for this as it would avoid changing something that is standard across all english langauge wikis. This doesn't sound like what you want to do but it is the question you originally asked. ;-) Doug.^{(talk • contribs)} 07:52, 22 December 2011 (UTC)

Could $wgExtraNamespaces[NS_TALK] = "Journal"; override this?  Hazard-SJ  ±  02:23, 24 December 2011 (UTC)

>Could $wgExtraNamespaces[NS_TALK] = "Journal"; override this?

yes, that would "rename" the talk namespace. Bawolff 05:50, 24 December 2011 (UTC)

Confirm Account extension does not seem to be working with MediaWiki 1.18

The extension seems to have stopped working after updating MediaWiki.

Fatal error: Call to undefined method Xml::hidden() in
/extensions/ConfirmAccount/RequestAccount_body.php on line 211

That is the error message that I get. MediaWiki Website User (talk) 15:13, 16 December 2011 (UTC)

Xml::hidden() was removed in version MediaWiki 1.18, so you are probably running an old version of ConfirmAccount. You can try installing the 1.18 version of ConfirmAccount. MrBlueSky 17:48, 16 December 2011 (UTC)

There doesn't seem to be a version of that extension for 1.18. I mentioned the problem on the developer's talk page, but I haven't got a reply yet. MediaWiki Website User 02:23, 18 December 2011 (UTC)

Yes it does. It can be downloaded here. Bawolff 06:38, 18 December 2011 (UTC)

can't share uploads

I'm trying to share uploads between two wikis (eventually more). I followed the instructions at Manual:Wiki family but it isn't working. I think it's because I don't understand what "$wgSharedUploadDirectory = '/(LOCALPATH)/POOL-FOLDER/images/';" means. What am I supposed to replace (LOCALPATH) with? Modrobene 20:29, 16 December 2011 (UTC)

This is what I have set in LocalSettings.php for en-Wikipedia and Commons and it works fine. Just change the 'apibase' to the site you want to share with.

/*   Files from en-Wikipedia and Commons        */
$wgUseInstantCommons  = true;
$wgForeignFileRepos[] = array(
   'class'                   => 'ForeignAPIRepo',
   'name'                    => 'shared',
   'apibase'                 => 'http://en.wikipedia.org/w/api.php',
   'fetchDescription'        => true, // Optional
   'descriptionCacheExpiry'  => 43200, // 12 hours, optional (values are seconds)
   'apiThumbCacheExpiry'     => 43200, // 12 hours, optional, but required for local thumb caching
);

Mlpearc powwow 17:00, 17 December 2011 (UTC)

Note, if you own both wikis, using foreignAPIRepo is a bit inefficient. See Manual:$wgForeignFileRepos#Using_files_from_a_database_that_you_can_access_:_ForeignDBRepo for how to set up sharing of uploads the more modern way. manual:$wgUseSharedUploads is the older method. $wgSharedUploadDirectory is the path where the images are actually stored on the server.

In regards to Mlpearc's post, it should be noted that it's technically unnessary to have both $wgUseInstantCommons on, and use a foreignAPIRepo for 'pedia, since foreignAPIRepo'ing wikipedia will also get you commons (otoh, it might still be a good idea, since there's a bug involving fetching descriptions from nested foreign repos) Bawolff 06:44, 18 December 2011 (UTC)

Thanks, that does work! Modrobene 06:47, 18 December 2011 (UTC)

Delete forever one post or file

When i've deleted a post or file, it is still avaible somewhere in my site. How can i delete it forever, and it can't appear in history? Nva1991 (talk) 10:48, 17 December 2011 (UTC)

Extension:DeletePagePermanently Mlpearc powwow 16:54, 17 December 2011 (UTC)

It says this extension can harm your wiki. It would be better to enable oversight, which can prevent deleted content from being availible even to Sysops. In general deleting things from the database is a bad idea. MediaWiki Website User 02:27, 18 December 2011 (UTC)

Changing the structure of page’s table of contents

I have encountered following problem – how can we make the Mediawiki to add a dot in TOC numeration after each digit? Explanation: now the standard numeration of headings looks like:

1 Text
2 Text
  2.1 Text
  2.2 Text

And we need

1. Text
2. Text
  2.1.    Text
  2.2.    Text

If you have any ideas about solving this problem, I would be very grateful to you for any help. The task is actual because all the contents in books have dots in numeration. ZelChief (talk) 15:26, 17 December 2011 (UTC)

I can't think of a good way to do this (like you could hack the source, the relavent code is in includes/Linker.php , the method tocLine of Linker class [or at least that's what it is in trunk].) Bawolff 07:04, 18 December 2011 (UTC)

Thank you very much! In file includes/Linker.php I change such function

 function tocLine( $anchor, $tocline, $tocnumber, $level, $sectionIndex = false ) {
                $classes = "toclevel-$level";
                if ( $sectionIndex !== false )
                        $classes .= " tocsection-$sectionIndex";
                return "\n<li class=\"$classes\"><a href=\"#" .
                        $anchor . '"><span class="tocnumber">' .
                        $tocnumber . '</span> <span class="toctext">' .
                        $tocline . '</span></a>';
        }

to

 function tocLine( $anchor, $tocline, $tocnumber, $level, $sectionIndex = false ) {
                $tocnumber = "$tocnumber. ";
                $classes = "toclevel-$level";
                if ( $sectionIndex !== false )
                        $classes .= " tocsection-$sectionIndex";
                return "\n<li class=\"$classes\"><a href=\"#" .
                        $anchor . '"><span class="tocnumber">' .
                        $tocnumber . '</span> <span class="toctext">' .
                        $tocline . '</span></a>';
        }

As a result it works and does not even conflict with Extension:PSINoTocNum. Now I'm trying to add a dot in the numbering of sections, which I do with Extension:MagicNumberedHeadings.

Where created the text of the header? Any ideas? ZelChief 12:10, 18 December 2011 (UTC)

I solve my problem =) So, in file /includes/parser/Parser.php I change such function

function formatHeadings( $text, $origText, $isMain=true )

Then, after such code

			# count number of headlines for each level
			@$sublevelCount[$toclevel]++;
			$dot = 0;
			for( $i = 1; $i <= $toclevel; $i++ ) {
				if ( !empty( $sublevelCount[$i] ) ) {
					if ( $dot ) {
						$numbering .= '.';
					}
					$numbering .= $wgContLang->formatNum( $sublevelCount[$i] );
					$dot = 1;
				}
			}

I add this

$numbering .= '.';

And ... it works. ZelChief 18:42, 18 December 2011 (UTC)

automatic resize of images

Hi everybody, i'd like to know how images could be automatically resized in order to be suitable with all kind of resolutions.

thank you

Matteo 87.25.79.44 (talk) 13:19, 18 December 2011 (UTC)

See $wgUseImageResize or $wgUseImageMagick. Generally this is enabled by default by the installer if you have the needed programs.

Note, in order for re-sizing images to work, you also need to have your webserver have write access to the apropriate parts of the image directory (if uploads work, you probably already do). See Manual:Image Administration Bawolff 21:12, 19 December 2011 (UTC)

I can't remove usergroups from users

I recently updated MediaWiki from 1.17 to 1.18, if that could have caused any issues.

The error I got was:

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:
(SQL query hidden)
from within function "User::removeGroup". Database returned error "1146: Table 'ske1145307562847.mw_user_former_groups' doesn't exist  
(ske1145307562847.db.7539804.hostedresource.com)". MediaWiki Website User (talk) 19:02, 18 December 2011 (UTC)

Do I need to add the table "mw_user_former_groups"?

Is this something that is used with 1.18, but not with 1.17?

I tried removing a usergroup that I set up recently with 1.18 and it worked fine. I'm guessing that this is something new that needs to be added to the database? MediaWiki Website User 18:24, 19 December 2011 (UTC)

Did you run update.php ? (or the web updater (point your browser to mywiki.com/w/mw-config )? user_former_groups is one of the schema changes in 1.18 Bawolff 21:06, 19 December 2011 (UTC)

I used an automatic update feature which is provided with the hosting service. Apperently the table wasn't added to the database automatically.

I have never been successful with running the update.php when adding extensions. Is there some place where I could find the text of the table to add it manually?

Thanks. MediaWiki Website User 08:45, 20 December 2011 (UTC)

>I used an automatic update feature which is provided with the hosting service. Apperently the table wasn't added >to the database automatically.

Then your host is doing things wrong. :)

-----

>I have never been successful with running the update.php when adding extensions. Is there some place where I could
>find the text of the table to add it manually?

We also have a web accessible updater which might be easier to run. But anyways all the database updates are in the maintenance/archives directory. The patches added in 1.18 are:

• patch-user-newtalk-timestamp-null.sql
• patch-user_email_index.sql
• patch-up_property.sql
• patch-uploadstash.sql
• patch-user_former_groups.sql

However, it should be noted that update.php doesn't straight apply those patches, it also adds replaces stuff between /* and */ in those files based on your settings (most importantly it adds the table prefix if in use) Bawolff 09:49, 20 December 2011 (UTC)

Thanks.

I just reverted back to 1.17, at least for now. I'll make sure the changes you mention take place when I update next time. MediaWiki Website User 20:49, 20 December 2011 (UTC)

Could not determine the numeric version from !

I tried to migrate my wiki site over to a new server and when I got to the wiki page I get the following error:

Could not determine the numeric version from !

I can't find anything that talks towards what this means? Any ideas?

MediaWiki 1.13.4 PHP 5.3.2 Database Postgresql 8.3 174.79.97.166 (talk) 20:02, 19 December 2011 (UTC)

Project:Support_desk/Archives/Installation/001#.28OUTDATED.29_MediaWiki_does_not_install_with_PostgreSQL_8.3.0 Suggests this could be a problem with Postgress support on older versions of MediaWiki. Try using the latest version of MediaWiki maybe Bawolff 21:04, 19 December 2011 (UTC)

I can't get it to upgrade to the latest version of the wiki. :( 174.79.97.166 21:20, 19 December 2011 (UTC)

Damn, I messed up, it's on Postgresql 8.4. The old server was 8.3 and it worked. 174.79.97.166 21:24, 19 December 2011 (UTC)

Loss of sortable table functionality after MediaWiki 1.15 to 1.18 upgrade.

Upgraded our internal MediaWiki installation from 1.15 to 1.18 this weekend. After the upgrade sortable tables no longer work. Read online about adding java script code to MediaWiki:Common.js. This made no difference so reverted the change. Receive SQL database error (from within function "MessageBlobStore::getUpdatesForMessage, msg_resource table) when I save that page, although the change seems to be retained. All the pertinent info is below. Any help would be greatly appreciated!

MediaWiki 1.18.0 PHP 5.3.8 (apache2handler) MySQL 5.5.18

Installed Extensions:

• SphinxSearch (Version 0.7.2)
• ParserFunctions (Version 1.1.1)
• Include
• LDAP Authentication Plugin (Version 1.2e)

MediaWiki:Common.js

/* Any JavaScript here will be loaded for all users on every page load. */

// If the page name (wgPageName) contains "MediaWiki" and we're in normal view
// mode, add "mainpage" class to the body element
if ( /^MediaWiki(\/.+)?$/.test( wgPageName ) && wgAction == 'view' ) {
	$(function() {
		document.body.className += ' mainpage';
	});
}

// switches for scripts
// TODO: migrate to JSConfig
// var load_extratabs = true;
var load_edittools = true;

// extra drop down menu on editing for adding special characters
importScript( 'MediaWiki:Edittools.js' );

// Editpage scripts
if( wgAction == 'edit' || wgAction == 'submit' ) {
	importScript( 'MediaWiki:Editpage.js' );
}


mw.loader.load( 'http://www.mediawiki.org/w/index.php?title=MediaWiki:JQuery-makeCollapsible.js&action=raw&ctype=text/javascript&smaxage=21600&maxage=86400' );

/** Collapsible tables *********************************************************
 *
 * From English Wikipedia, 2008-09-15
 * @deprecated: Do not use this in new constructions, use class="mw-collapsible" instead
 *
 *  Description: Allows tables to be collapsed, showing only the header.
 *               See [[Wikipedia:NavFrame]].
 *  Maintainers: [[User:R. Koot]]
 */
var autoCollapse = 2;
var collapseCaption = 'hide';
var expandCaption = 'show';

function collapseTable( tableIndex ) {
	var Button = document.getElementById( 'collapseButton' + tableIndex );
	var Table = document.getElementById( 'collapsibleTable' + tableIndex );

	if ( !Table || !Button ) {
		return false;
	}

	var Rows = Table.rows;

	if ( Button.firstChild.data == collapseCaption ) {
		for ( var i = 1; i < Rows.length; i++ ) {
			Rows[i].style.display = 'none';
		}
		Button.firstChild.data = expandCaption;
	} else {
		for ( var i = 1; i < Rows.length; i++ ) {
			Rows[i].style.display = Rows[0].style.display;
		}
		Button.firstChild.data = collapseCaption;
	}
}

function createCollapseButtons(){
	var tableIndex = 0;
	var NavigationBoxes = new Object();
	var Tables = document.getElementsByTagName( 'table' );

	for ( var i = 0; i < Tables.length; i++ ) {
		if ( hasClass( Tables[i], 'collapsible' ) ) {
			/* only add button and increment count if there is a header row to work with */
			var HeaderRow = Tables[i].getElementsByTagName( 'tr' )[0];
			if( !HeaderRow ) {
				continue;
			}
			var Header = HeaderRow.getElementsByTagName( 'th' )[0];
			if( !Header ) {
				continue;
			}

			NavigationBoxes[tableIndex] = Tables[i];
			Tables[i].setAttribute( 'id', 'collapsibleTable' + tableIndex );

			var Button     = document.createElement( 'span' );
			var ButtonLink = document.createElement( 'a' );
			var ButtonText = document.createTextNode( collapseCaption );

			Button.style.styleFloat = 'right';
			Button.style.cssFloat = 'right';
			Button.style.fontWeight = 'normal';
			Button.style.textAlign = 'right';
			Button.style.width = '6em';

			ButtonLink.style.color = Header.style.color;
			ButtonLink.setAttribute( 'id', 'collapseButton' + tableIndex );
			ButtonLink.setAttribute( 'href', "javascript:collapseTable(" + tableIndex + ");" );
			ButtonLink.appendChild( ButtonText );

			Button.appendChild( document.createTextNode( '[' ) );
			Button.appendChild( ButtonLink );
			Button.appendChild( document.createTextNode( ']' ) );

			Header.insertBefore( Button, Header.childNodes[0] );
			tableIndex++;
		}
    }

	for ( var i = 0;  i < tableIndex; i++ ) {
		if ( hasClass( NavigationBoxes[i], 'collapsed' ) || ( tableIndex >= autoCollapse && hasClass( NavigationBoxes[i], 'autocollapse' ) ) ) {
			collapseTable( i );
		}
	}
}

addOnloadHook( createCollapseButtons );

/** Dynamic Navigation Bars (experimental) *************************************
 *
 * From English Wikipedia, 2008-09-15
 *
 *  Description: See [[Wikipedia:NavFrame]].
 *  Maintainers: UNMAINTAINED
 */

// set up the words in your language
var NavigationBarHide = '[' + collapseCaption + ']';
var NavigationBarShow = '[' + expandCaption + ']';

// shows and hides content and picture (if available) of navigation bars
// Parameters:
//     indexNavigationBar: the index of navigation bar to be toggled
function toggleNavigationBar( indexNavigationBar ) {
	var NavToggle = document.getElementById( 'NavToggle' + indexNavigationBar );
	var NavFrame = document.getElementById( 'NavFrame' + indexNavigationBar );

	if( !NavFrame || !NavToggle ) {
		return false;
	}

	// if shown now
	if( NavToggle.firstChild.data == NavigationBarHide ) {
		for( var NavChild = NavFrame.firstChild; NavChild != null; NavChild = NavChild.nextSibling ) {
			if ( hasClass( NavChild, 'NavPic' ) ) {
				NavChild.style.display = 'none';
			}
			if ( hasClass( NavChild, 'NavContent' ) ) {
				NavChild.style.display = 'none';
			}
		}
		NavToggle.firstChild.data = NavigationBarShow;

	// if hidden now
	} else if( NavToggle.firstChild.data == NavigationBarShow ) {
		for( var NavChild = NavFrame.firstChild; NavChild != null; NavChild = NavChild.nextSibling ) {
			if( hasClass( NavChild, 'NavPic' ) ) {
				NavChild.style.display = 'block';
			}
			if( hasClass( NavChild, 'NavContent' ) ) {
				NavChild.style.display = 'block';
			}
		}
		NavToggle.firstChild.data = NavigationBarHide;
	}
}

// adds show/hide-button to navigation bars
function createNavigationBarToggleButton() {
	var indexNavigationBar = 0;
	// iterate over all < div >-elements
	var divs = document.getElementsByTagName( 'div' );
	for( var i = 0; NavFrame = divs[i]; i++ ) {
		// if found a navigation bar
		if( hasClass( NavFrame, 'NavFrame' ) ) {
			indexNavigationBar++;
			var NavToggle = document.createElement( 'a' );
			NavToggle.className = 'NavToggle';
			NavToggle.setAttribute( 'id', 'NavToggle' + indexNavigationBar );
			NavToggle.setAttribute( 'href', 'javascript:toggleNavigationBar(' + indexNavigationBar + ');' );

			var NavToggleText = document.createTextNode( NavigationBarHide );
			for( var NavChild = NavFrame.firstChild; NavChild != null; NavChild = NavChild.nextSibling ) {
				if ( hasClass( NavChild, 'NavPic' ) || hasClass( NavChild, 'NavContent' ) ) {
					if( NavChild.style.display == 'none' ) {
						NavToggleText = document.createTextNode( NavigationBarShow );
						break;
					}
				}
			}

			NavToggle.appendChild(NavToggleText);
			// Find the NavHead and attach the toggle link (Must be this complicated because Moz's firstChild handling is borked)
			for( var j = 0; j < NavFrame.childNodes.length; j++) {
				if( hasClass( NavFrame.childNodes[j], 'NavHead' ) ) {
					NavFrame.childNodes[j].appendChild( NavToggle );
				}
			}
			NavFrame.setAttribute( 'id', 'NavFrame' + indexNavigationBar );
		}
	}
}
addOnloadHook( createNavigationBarToggleButton );

/* End of extra pages */

50.58.79.170 (talk) 21:10, 19 December 2011 (UTC)

Possibly some sort of js error in your MediaWiki:Common.js is breaking sortable tables. Try totally removing it and then doing hard refresh. (Also check your web browsers js console to look for errors)

For the db error. You should run manual:Update.php any time you upgrade, or you'll get db errors. Bawolff 23:27, 22 December 2011 (UTC)

How to display page content with an extension?

Hi, I'm trying to write a tag extension that will, among other things, embed the content of articles from a category (similar to what you can do with the Dynamic Page List or Symantic Wiki extensions). But I can't figure out how even get it to display page content.

For starters, should I access the MySQL database, the API, the XML, or something else to call and embed the content of articles? User:Octify
MediaWiki: 1.17.0
PHP: 5.3.5
MySQL: 5.5.8
Apache ver 2.2.17
Windows XP 05:45, 20 December 2011 (UTC)

You can use the api internally to get the parsed article content (possibly not the most efficient way of doing things). See extension:GoogleNewsSitemap for an example of how that's done (specifically the getDescription method of FeedSMItem. Otherwise you'd want to probably look at the Article class or the Revision class Bawolff 23:24, 22 December 2011 (UTC)

Thanks Bawolff, I appreciate the feedback! Though to be honest, I'm still teaching myself how to use public/private functions and classes (I'm totally a novice lol), but I'll do some more research on it and see if I can put the code for the GoogleNewsSitemap extension to use :) Octify27 19:03, 28 December 2011 (UTC)

This is kind of a long topic for the support desk, but I'll do my best.

The docs on tag extensions are pretty well documented, so I'll leave that to you. Needless to say, to make it as flexible as possible, it should probably take at least one parameter, category, and possibly some optional ones, "limit" to limit the number of articles shown, "format" to show either the whole article or a summary, etc.

Most of the information you want can be found via the API. It's a huge and flexible query system you can use to fetch information.

The best way to query it from an extension is to use the FauxRequest object. This allows you to query the API without making network calls. So it's fast. Or faster depending upon how many you make.

To get all the members of a category (up to the set limit), you can query as follows:

$req = new FauxRequest( array(
              'action' => 'query',
              'list' => 'categorymembers',
              'cmtitle' => $categoryName,
              'cmlimit' => 'max'
           ));
$main = new ApiMain($req);
$main->execute();
$data = $main->getResultData();

This queries the category API and returns the data in a PHP multi-dimensional array where $categoryName is the variable holding a category name like "Category: Foo".

Once you have the list of category members, you can then loop through them to get each page for which you query to get their content using a similar method. Once you have the content, you can then format and output it however you like. Personally, I prefer the "parse" method of the API since it turns all the wiki code into HTML and little formatting has to be done. That can be accomplished like so:

$req = new FauxRequest( array(
               'action' => 'parse',
               'page' => $page
            ));

Where $page is the name of the article you want to fetch content for.

Using this method, you should be able to access any page you want on your wiki and display the content based on the parameters passed via the tag extension.

Sounds like a pretty cool project. Unifiedrepublic 16:06, 23 December 2011 (UTC)

Thanks Unifiedrepublic, this seems very promising! But I think I might be missing something, as when I put the following code into my wiki, I only got a blank page (the title of the page I'm on, but no article content):

<?php
$wgExtensionCredits['parserhook'][] = array(
	'path'           => __FILE__,
	'name'           => 'Sample',
	'author'         => '[[User:Admin|Admin]]',
	'url'            => '',
	'description' 	 => ''
);
$wgHooks['ParserFirstCallInit'][] = 'efSampleParserInit';
$wgAPIModules['sample'] = 'ApiSample';
 
// Hook our callback function into the parser
function efSampleParserInit( Parser &$parser ) {
        // When the parser sees the <sample> tag, it executes 
        // the efSampleRender function (see below)
        $parser->setHook( 'sample', 'efSampleRender' );
        return true;
}
 
// Execute 
function efSampleRender() {
	$categoryName = 'Category:Yes';
	$page = 'Page 1';
	
        $req = new FauxRequest( array(
              'action' => 'query',
              'list' => 'categorymembers',
              'cmtitle' => $categoryName,
              'cmlimit' => 'max'
           ));
$main = new ApiMain($req);
$main->execute();
$data = $main->getResultData();
$req = new FauxRequest( array(
               'action' => 'parse',
               'page' => $page
            ));
}

Maybe it's a problem with what I'm putting between the tags on the actual page?

<code>
<sample> category=yes </sample>

(And yeah, I'm really looking forward to this extension, once I finally get everything worked out. Eventually I want to make it so that it'll be able to randomly display an article daily (or monthly, depending on how I set it), so that I could use it to generate a random featured article every day. The way Wikipedia does featured articles doesn't make sense for my small private wiki, so I figured I'd see if I could make an extension to do the work for me.) Octify27 19:27, 28 December 2011 (UTC)

It looks like your main issue is that you don't have a return statement in your efSampleRender function. Without a return statement, the function will generate data, but not put any of it in the page. The other thing I notice is $wgAPIModules['sample'] = 'ApiSample'; . That's only needed if you want to make a new api module. If you just plan to use an existing API moudle, you don't need a line like that.

Additionally, it was probably really bad advice on my part to suggest the parse api module. It didn't click in my head at the time, but that would call the parser recursively, which is a bad thing. (Basically, mediawiki can only parse one thing at a time, when your extension is running, its already parsing the current page, so it can't parse anything else, and calling api parse module would cause it to parse something else, which is bad (GoogleNewsSitemap extension didn't have that problem since it runs not while parsing another page). Generally what happens when the parser is called recursively is that mysterious markers like UNIQ3858f81c6798e00f-sample-00000009-QINU appear in the page. You can still use other api modules in your extension safely, just not the parse one (or any other module that involves parsing things)

Sine you just want to include a page, and are not interested in the actual html of the page, you might consider the $parser->recursiveTagParse method (Which does not count as calling the parser recursively). It takes wikitext and returns html (ish anyways). So you could just use normal template inclusion syntax. (Alternatively if you want to process the wikitext first, you could get the text from either the API, or something like Article::fetchContent(), process the text, and stick it in recursiveTagParse)

For example, if you wanted to include a random page from some category (for example, if you wanted <sample>Foo</sample> return a random entry from category:Foo, your efSampleRender would look something like:

//Assume the boilerplate you had in your post is here.
function efSampleRender( $input, $args, $parser, $frame ) {
  // $input is the input to the tag, $args is its "attributes"
  // So if you had <sample baz="bar">foo</sample>
  // $input == "foo"; $args == array( 'baz' => 'bar' );
  // $parser is an instance of the MediaWiki parser, $frame is related to what template
  // args are the page was called with, and generally isn't too useful
  // This turns the input in to a title object, which does some normalization (like first letter capitalized, etc)
  // Second argument says that if no other namespace specified, assume category.
  $category = Title::newFromText( $input, NS_CATEGORY );
  if ( !$category ) return '<span class="error">Invalid category given</span>';
 // This gets a reference to the database. DB_SLAVE means get a read-only connection
 $dbr = wfGetDB( DB_SLAVE );
 $page = $dbr->selectField(  // selectField means get just a single item (instead of a whole bunch of stuff)
   'categorylinks',  // This means get it from the categorylinks table, which stores what page is in what category
   'cl_from',        // this means get the value of cl_from, which stores the page id of a page in some category
   array( 'cl_to' => $category->getDBKey() ),  // get the name of the category for purposes of the db
   __METHOD__, // This isn't important, just for profiling purposes
   array( 'ORDER BY' => 'rand()')  // This means to pick a random entry in the category instead of the "first" one.
  );
 // $page is now a number, which is the article id of the article we want. Now to convert it into a name
 $title = Title::newFromID( $page );
 // If $page not valid id. For example, if no pages in given category (or if there is stray entry in db, which would be kind of odd)
 if (!$title) return '<span class="error">Could not retrieve any pages</span>';
 // getFullText means get entire page name, including namespace.
 $page = $title->getFullText();
 // Include this page standard template way. Leading colon is needed to denote not template namespace by defualt.
 // The return part actually puts this new page into the page.
 return $parser->recursiveTagParse( '{{:' . $page . '}}', $frame );
}

The database stuff can be a little complicated, especially when you are new to it, and in some ways it might be easier to use the API for that step. If your curious about the db stuff though, there's docs at Manual:Database access [4] [5] and Manual:Categorylinks table ). If you're familiar with sql, the example query I gave above is equivalent to SELECT /* */ cl_from FROM `categorylinks` WHERE cl_to = 'Foo' ORDER BY rand() LIMIT 1 Bawolff 08:01, 29 December 2011 (UTC)

OH MY GOD I LOVE YOU!!!!!!!!!!! :D :D :D :D

I've been trying to figure this out on and off since SUMMER!! And you... AAAAAAAAAAAA :D :D

You're freaking amazing!!

I had tried calling the database before but I only got the category titles, so I figured maybe I should try the API instead. But this works beautifully! Now the only thing I'll need to do is make it so that the random page will change daily or monthly (depending on how it's set) instead of every time the page is refreshed :)

Thankyouthankyouthankyouthankyouthankyou!!!!!!!!!! Octify27 15:05, 29 December 2011 (UTC)

How can I disable talk namespaces

How can I disable the talk namespaces? In intranet wikis with small teams it makes no sense and would be less confusing wihtout them.

For custom namespaces it's easy tho, I just don't define the talk namespaces. Subfader (talk) 10:02, 20 December 2011 (UTC)

I'm really not sure about disabling the talk namespace altogether, but if it would suffice, you could hide the talk tab by using something like this in your Common.css

li#ca-talk { display: none; }

   Thorncrag   16:27, 20 December 2011 (UTC)

Completely disabling all talk namespaces would mean that they disappear from all namepsace lists like Search, the own talk page in the user links section, in auto user links (talk | contribs) etc. Subfader 16:35, 20 December 2011 (UTC)

I opened a request on bugzilla Subfader 09:42, 21 December 2011 (UTC)

Many things rely on the fact that every subject namespace has a corresponding talk namespace. Thus the best approach is to hide it with css as Thorncrag suggests. Bawolff 23:07, 22 December 2011 (UTC)

Epic fail. Most mentioned links don't have an own CSS class or id! Subfader 13:27, 28 December 2011 (UTC)

Lots of them can be changes via system messages if you're really dedicated (try out ?uselang=qqx). (As an aside, someone did implement a semi-related feature - $wgDisableAnonTalk) Bawolff 08:34, 29 December 2011 (UTC)

Tags filtering does not work

Hello, I'm sorry for the bad English, this text is translated, I only speak French. Since I moved from version 1.17 to version 1.18, when I put a tag <ref> in a template, I do not obtain, example, text[1], but something more like, text[UNIQ3e899f9b5c8f874-nowiki-00000002-QINU?1?UNIQ3e899f9b5c8f874-nowiki-00000003-QINU]. You can see an example on this page. Where the source of that error? This does not derive from templates or extensions. Thank you

P.S.: I forgot in the message: the same page with the same models on a mediawiki 1.17 on this page 217.77.80.29 (talk) 14:43, 20 December 2011 (UTC)

Make sure you also update the Cite extension.    Thorncrag   16:36, 20 December 2011 (UTC)

I updated the Cite extension but the problem still exists.

Moreover, I have some pages for dedicated usages that are structured in this way:

------------------------

my text my text my text my text

[Category:mycategory]

<mytag>mytagcontent</mytag>

------------------------

and, also in this case that strange message appears instead of bypassing the tag (that is what happens with mediawiki 1.17)

Thank you very much. 217.77.80.29 12:39, 21 December 2011 (UTC)

This sort of error is caused by calling the parser recursively (for example doing $wgParser->parse from inside a parser hook, or $wgOut->addWikiText from a parser hook, which would break things in many other ways too). It can often be triggered by one extension, and then break output in another. Thus its quite possible this is not Cite's fault, but a different extension installed.

Could you try and find a minimal test case (if you can come up with an example of this bug on a page that only uses the cite extension, and no other extensions, that would be great) Bawolff 23:19, 22 December 2011 (UTC)

Bugzilla offline

You might have trouble with Wikimedia's Etherpad or Bugzilla or CiviCRM sites/services Wednesday night. This is why. If interruption continues after 1820 PT -- convert to your localtime -- please tell us in #wikimedia-tech (webchat link). ☠MarkAHershberger☢(talk)☣ 19:33, 20 December 2011 (UTC)

The maintenance for db9 was successfully completed but some follow up maintenance is needed. As a result, you might have trouble with Wikimedia's Etherpad or Bugzilla or CiviCRM sites/services tonight. If interruption continues after 1820 PST please tell us in #wikimedia-tech (webchat link). ☠MarkAHershberger☢(talk)<span style="color:#d30000; text-decoration:inheri 15:37, 22 December 2011 (UTC)

Problem with deleting spam pages

Hi. So spammers have loved our wiki lately (illinoiscommunityjustice.org), and I've ended up with a ton of pages listed in http://illinoiscommunityjustice.org/Special:AllPages that have punctuation in the URLs. Trying to delete the pages with the built in delete function isn't working for me, because these pages generate a 404 error (the ones that have periods in the URL seem to be the main culprits). Anyone got advice for how to delete a page that returns a 404?

MediaWiki 1.15.1 PHP 5.2.17 (cgi) MySQL 5.0.92-50-log

Thanks in advance,

Frank 140.192.168.196 (talk) 22:40, 20 December 2011 (UTC)

Protect your wiki from Spam! See Manual:Combating spam. Subfader 09:59, 21 December 2011 (UTC)

Thanks, already started working on that, but in the meantime, I've still got these pages I need to delete that return a 404. Any suggestions for that?

Thanks!

Frank 140.192.168.196 14:59, 21 December 2011 (UTC)

Seems like a problem with your server config. Punctuation in URLs is no problem, e.g. see MediaWiki:Common.css Subfader 20:47, 21 December 2011 (UTC)

I note that there are other pages with similar names that you have deleted and that the relevant pages don't seem to appear in recent changes. I'm not immediately sure why. Doug.^{(talk • contribs)} 09:25, 22 December 2011 (UTC)

OK, I've run into this before with page names that start with a special character. The pages exist but cannot be accessed by clicking on the wikilink as it results in an invalid name for some reason. Try the following:

1. click on the link to one of the bad pages
2. between .org/ and the name of the page, type: index.php?title=
3. if you click enter at this point you will see the page and should be able to click the delete tab. Or you can simply append &action=delete to the end of the page name above
4. thus: http://illinoiscommunityjustice.org/index.php?title=Generic_cialis_10mg,_100mg,_5mg,_40mg,_50mg,_60mg,_20mg,_2.5mg,_200mg_online_-_liaison_sp_cialis_e_-_cialis_form_indian_pharmacies&action=delete (try it: http://illinoiscommunityjustice.org/index.php?title=Generic_cialis_10mg,_100mg,_5mg,_40mg,_50mg,_60mg,_20mg,_2.5mg,_200mg_online_-_liaison_sp_cialis_e_-_cialis_form_indian_pharmacies&action=delete)
5. proceed with the deletion action Doug.^{(talk • contribs)} 09:41, 22 December 2011 (UTC)

For reference, this sort of issue (Can't get to page with periods in it) happens when short urls are set up incorrectly... Bawolff 23:31, 22 December 2011 (UTC)

thanks for this workaround! Will look into the configuration of short urls

Frank 68.102.178.220 14:54, 23 December 2011 (UTC)

$wgConf and CentralAuth

I am using the following $wgConf for my 3 wikis:

<?PHP
$wgLocalDatabases = array(
    'mainwiki',
	'networkwiki',
	'projectwiki',
);

$wgConf->wikis = $wgLocalDatabases;
$wgConf->suffixes = array( 'wiki' );
$wgConf->localVHosts = array( 'localhost' );
 
/*require_once "$IP/InitialiseSettings.php";*/
 
function efGetSiteParams( $conf, $wiki ) {
    $site = null;
    $lang = null;
    foreach( $conf->suffixes as $suffix ) {
        if ( substr( $wiki, -strlen( $suffix ) ) == $suffix ) {
            $site = $suffix;
            $lang = substr( $wiki, 0, -strlen( $suffix ) );
            break;
        }
    }
    return array(
        'suffix' => $site,
        'lang' => $lang,
        'params' => array(
            'lang' => $lang,
            'site' => $site,
            'wiki' => $wiki,
        ),
        'tags' => array(),
    );
}
$wgBlockAllowsUTEdit=true;
$wgBlockCIDRLimit=array('IPv4'=>0, 'IPv6'=>0); 
require_once("$IP/extensions/CentralAuth/CentralAuth.php");
$wgConf->suffixes = $wgLocalDatabases;
$wgConf->siteParamsCallback = 'efGetSiteParams';
$wgConf->extractAllGlobals( $wgDBname );
$wgConf->settings=array(
#Required for CentralAuth
'+wgGroupPermissions'=>array(
	'default'=>array(
		'*'=>array(
			'edit'=>false,
			),
		),
	),
'wgServer'           => array(
	'default'=>'http://192.168.2.100',
	),
'wgCanonicalServer'=>array(
	'default'=>'http://192.168.2.100',
	),
'wgArticlePath'=>array(
	'default'=>"{$wgScript}?title=$1",
	),
'wgLocalInterwiki'=>array(
	'default'=>'$lang',
	),
'wgSitename'=>array(
	'mainwiki'=>"Jasper's Wiki",
	'networkwiki'=>"Jasper's Network",
	'projectwiki'=>"Jasper's Projects",
	),
#Other configuration settings
'+wgBlockCIDRLimit'=>array(
	'mainwiki'=>array(
		'IPv4'=>0,
		'IPv6'=>0,
		),
	
	'default'=>array(
		'IPv4'=>0,
		'IPv6'=>0,
		),
	),
'+wgBlockAllowsUTEdit'=>array(
	'mainwiki'=>true,
	'default'=>true,
	),
);

$wgCentralAuthDatabase='centralauth';
require_once("$IP/extensions/CheckUser/CheckUser.php");
$wgShowExceptionDetails=true;
# (Not installed yet) require_once("$IP/extensions/GlobalUserrrights/GlobalUserrights.php");
 
require_once($IP.'/extensions/GlobalBlocking/GlobalBlocking.php');
$wgShowExceptionDetails=true;
?>

First of all, my $wgConf settings do not seem to apply. My wikis all just use their local $wgGroupPermissions and other settings and don't read what I put into $wgConf. CentralAuth's user unification worked properly, but I get a 500 Internal Server Error whenever I try to view my own global user info. Note that I am using Windows IIS, and my version of PHP somehow is unable to run anything in CLI. I am on a private network so this is not accessible to the public. Mainwiki (my "meta") is located at the /wiki subdirectory, Projectwiki at /projectwiki, and networkwiki at /networkwiki. The above is a Commonsettings.php included on the first line of the Localsettings.php file of every wiki. Databases have been set up correctly, and I have not done the migration scripts because I have only one user. What is wrong with my setup?Jasper Deng 00:37, 21 December 2011 (UTC)

For your first problem, you need to set $wgConf->settings before calling $wgConf->extractAllGlobals(), because the latter uses the former. For the HTTP error, you'll need to get the error message, Manual:How to debug can help you. iAlex 07:17, 21 December 2011 (UTC)

The error is:

Fatal error: Call to undefined method WikiReference::getFullUrl() in C:\inetpub\wwwroot\networkwiki\extensions\CentralAuth\specials\SpecialCentralAuth.php on line 467

I have edited my $wgConf to the following now:

<?PHP
error_reporting(E_ALL);
ini_set('display_errors',1);
#$wgSharedDB='mainwiki';
#$wgSharedPrefix='mainwiki';
$wgLocalDatabases = array(
    'mainwiki',
	'networkwiki',
	'projectwiki',
);
$wgConf->wikis = $wgLocalDatabases;
$wgConf->suffixes = array( 'wiki' );
$wgConf->localVHosts = array( 'localhost' );
 
/*require_once "$IP/InitialiseSettings.php";*/
 
function efGetSiteParams( $conf, $wiki ) {
    $site = null;
    $lang = null;
    foreach( $conf->suffixes as $suffix ) {
        if ( substr( $wiki, -strlen( $suffix ) ) == $suffix ) {
            $site = $suffix;
            $lang = substr( $wiki, 0, -strlen( $suffix ) );
            break;
        }
    }
    return array(
        'suffix' => $site,
        'lang' => $lang,
        'params' => array(
            'lang' => $lang,
            'site' => $site,
            'wiki' => $wiki,
        ),
        'tags' => array(),
    );
}
$wgBlockAllowsUTEdit=true;
$wgBlockCIDRLimit=array('IPv4'=>0, 'IPv6'=>0); 
require_once("$IP/extensions/CentralAuth/CentralAuth.php");
$wgConf->suffixes = $wgLocalDatabases;
$wgConf->siteParamsCallback = 'efGetSiteParams';
$wgConf->settings=array(
'+wgScriptPath'=>array(
	'mainwiki'=>'/wiki',
	'projectwiki'=>'/projectwiki',
	'networkwiki'=>'/networkwiki',
	),
'+wgScript'=>array(
	'mainwiki'=>'/wiki/index.php',
	'projectwiki'=>'/projectwiki/index.php',
	'networkwiki'=>'/networkwiki/index.php',
	),
#Required for CentralAuth
'+wgGroupPermissions'=>array(
	'default'=>array(
		'*'=>array(
			'edit'=>false,
			),
		),
	),
'wgServer'           => array(
	'default'=>'http://192.168.2.100/',
	),
'wgCanonicalServer'=>array(
	'default'=>'http://192.168.2.100',
	),
'wgArticlePath'=>array(
	'mainwiki'=>'/wiki/index.php?title=$1',
	'networkwiki'=>'/networkwiki/index.php?title=$1',
	'projectwiki'=>'/projectwiki/index.php?title=$1',
	),
'wgLocalInterwiki'=>array(
	'default'=>'$lang',
	),
'wgSitename'=>array(
	'mainwiki'=>"Jasper's Wiki",
	'networkwiki'=>"Jasper's Network",
	'projectwiki'=>"Jasper's Projects",
	),
#Other configuration settings
'+wgBlockCIDRLimit'=>array(
	'mainwiki'=>array(
		'IPv4'=>0,
		'IPv6'=>0,
		),
	
	'default'=>array(
		'IPv4'=>0,
		'IPv6'=>0,
		),
	),
'+wgBlockAllowsUTEdit'=>array(
	'networkwiki'=>true,
	'projectwiki'=>true,
	'mainwiki'=>true,
	'default'=>true,
	),
);
$wgConf->extractAllGlobals( $wgDBname );
$wgCentralAuthDatabase='centralauth';
require_once("$IP/extensions/CheckUser/CheckUser.php");
$wgShowExceptionDetails=true;
# (Not installed yet) require_once("$IP/extensions/GlobalUserrrights/GlobalUserrights.php");
 
require_once($IP.'/extensions/GlobalBlocking/GlobalBlocking.php');
$wgShowExceptionDetails=true;
?>

(Each of my LocalSettings.php includes this Commonsettings.php as their first line)

I got $wgConf to control $wgArticlePath and other things, but still cannot get it to control $wgBlockCIDRLimit and $wgBlockAllowsUTEdit.Jasper Deng 18:56, 21 December 2011 (UTC)

WikiReference::getFullUrl() only exists in trunk version, you will need to download an older version of the extension.

For you problems with configuration settings, I would remove the "+" in front of setting's names except for wgGroupPermissions. iAlex 21:13, 22 December 2011 (UTC)

I'm using MW 1.18; which version of CentralAuth do you suggest?Jasper Deng 05:06, 25 December 2011 (UTC)

Anyone? Jasper Deng 20:36, 1 January 2012 (UTC)

How do I get the trunk verison? Jasper Deng 03:37, 6 January 2012 (UTC)

Search on Russian do not work.

I use MediaWiki 1.18.0 on local home server - Appache, MySQL, Linux Ubuntu 11.10.

I use standart fulltext search.

• When I try to search something in English - all works fine, I see titles of articles and text below.
• But when I try to search articles in Ukrainian or Russian - In search results I see only Titles of articles, and no text below. SERIOUSARON (talk) 09:23, 21 December 2011 (UTC)

Best way to export an article as PDF?

What's the best way to export a single article directly as PDF file?

I know on WP is that wiki books feature (which extension is it?), but it seems too much for easy one-click exports of a single article.

The PDF extensions on here seem to be non-stable or not even mainitained anymore. Subfader (talk) 10:01, 21 December 2011 (UTC)

Extension:Collection Subfader 20:55, 21 December 2011 (UTC)

There is no good way. Extension:Collection may work on wikipedia type pages, I'm not sure, and seems to work 'OK' on some mw.org pages, but it is a complete mess on wikisource type pages whether you try to assemble a book or simply 'download as a pdf'. The export as a Printable Version function, which is built-in, works OK but retains web page address headers and footers, it also requires the ability to save as a PDF. Doug.^{(talk • contribs)} 09:11, 22 December 2011 (UTC)

Yeah, couldn't get Extension:Collection working :/

Printing as PDF also misses the nice feature of Extension:Collection to break chapters smartly on new pages. Subfader 10:09, 22 December 2011 (UTC)

Images

Is it possible to show images in an article? If so, what is the code. Because the [[file:image.ong]] just shows a link and not an image. And where would i place the image? 99.240.49.171 (talk) 01:52, 22 December 2011 (UTC)

See Help:Images. ong is no image file extension... Subfader 07:14, 22 December 2011 (UTC)

Sorry, i ment png. 99.240.49.171 15:59, 23 December 2011 (UTC)

See also Manual:Configuring_file_uploads. Any image you want to use on your wiki has to be uploaded to your wiki via Special:Upload (or if using $wgUseInstantCommons you can use any image from commons: without any need to upload it to your wiki) Bawolff 10:57, 24 December 2011 (UTC)

Wildcardsearch with a *Suffix does not work

Hello,

I have an Installtion (MediaWiki 1.18.0, PHP 5.3.8 (apache2handler), MySQL 5.5.16) with some Extensions and the Wildcardsearch with a Suffik does not work. As Exampe: I search *animal and i a page the word wildanimal exists. But the search result find nothing.

Can anyone hel me?

Adrian 194.41.152.158 (talk) 11:46, 22 December 2011 (UTC)

For what it's worth, I've noticed hit-or-miss behavior when searching for wild cards. This includes Wikipedia, Mediawiki, and the wiki I administer. So, I'm not sure it's anything that might be mis-configured on your end.    Thorncrag   14:48, 2 January 2012 (UTC)

In Wikipedia at least i can find [Norwegen] with [orwegen]. Wikipedia offers similar Words an makes a Suggestion [Norwegen]. As it is mentioned in http://en.wikipedia.org/wiki/Help:Searching Chapter [Search engine features] -> Wildcardsearch, Wikipedia should support the Wildcardsearch with a suffix.

For me it's worth to find words, wich im not sure, if they are written together or not. Example: Oscar-winning / Oscarwinning / Oscar winning . If i would search for [winning] only the last example would match.

Do you know other solutions for me? Should i install the lucene seraching machine?

Thanks Adrian 194.41.216.154 12:14, 3 January 2012 (UTC)

File upload not possible: MIME Type or wrong ZIP detection

Hi! I am new here and this is my first install: http://www.mediawiki.attac.at

I have the following problem: File upload is not working correctly. I get the error that the file ending is not corresponding to MIME() but I only try to upload a jpg... If I if I use $wgVerifyMimeType = false; It say that there is a problem with the zip file. So what I thing is that the fil ending or MIME type can not be recognized correctly. Does someone knows about this issue?

mediawiki 1.18. PHP Version 5.3.3-7+squeeze3

Thanks in advance, Thomas Thomaaaaaas (talk) 19:07, 22 December 2011 (UTC)

You might want to try playing around with Manual:$wgCheckFileExtensions Manual:$wgStrictFileExtensions Manual:$wgVerifyMimeType. In the past I've had similar problems with the automatic MIME detection and checker, and I've been able to resolve them with these. However, if you are concerned about actually scanning them for security reasons, it may be worth reporting this as a bug. I would recommend testing it with other completely different files to verify it's a problem first.    Thorncrag   14:52, 2 January 2012 (UTC)

Upgrade from 1.5 to 1.14 fails.. nothing on screen

I get nothing on my screen after I ran an update from 1.5 to 1.14

I did a test install of 1.14 to see if it would run on my php and mysql and it did just fine...

When I ran the maintenance update this is what I got the second time..

I also tried to modify the LocalSettings.php from the 1.5 to use the 1.14 set up..

I have a backup but what am I missing here.

MediaWiki 1.14.1 Updater

Going to run database updates for wikidb-mw_
Depending on the size of your database this may take a while!
Abort with control-c in the next five seconds...0
...have ipb_id field in ipblocks table.
...have ipb_expiry field in ipblocks table.
...already have interwiki table
...indexes seem up to 20031107 standards
...hitcounter table already exists.
...have rc_type field in recentchanges table.
...have user_real_name field in user table.
...querycache table already exists.
...objectcache table already exists.
...categorylinks table already exists.
Already have pagelinks; skipping old links table updates.
...have rc_ip field in recentchanges table.
...image primary key already set.
...have rc_id field in recentchanges table.
...have rc_patrolled field in recentchanges table.
...logging table already exists.
...have user_token field in user table.
The watchlist table is already set up for email notification.
...watchlist talk page rows already present
...user table does not contain old email authentication field.
...page table already exists.
...have log_params field in logging table.
logging table has correct log_title encoding.
...have ar_rev_id field in archive table.
...have page_len field in page table.
revision timestamp indexes already up to 2005-03-13
...rev_text_id already in place.
...have rev_deleted field in revision table.
...have img_width field in image table.
...have img_metadata field in image table.
...have user_email_token field in user table.
...have ar_text_id field in archive table.
...page_namespace is already a full int (int(11)).
...ar_namespace is already a full int (int(11)).
...rc_namespace is already a full int (int(11)).
...wl_namespace is already a full int (int(11)).
...qc_namespace is already a full int (int(11)).
...log_namespace is already a full int (int(11)).
...have img_media_type field in image table.
...already have pagelinks table.
No img_type field in image table; Good.
Already have unique user_name index.
...user_groups table already exists.
...user_groups is in current format.
...have ss_total_pages field in site_stats table.
...user_newtalk table already exists.
...transcache table already exists.
...have iw_trans field in interwiki table.
...trackbacks table already exists.
...wl_notificationtimestamp is already nullable.
...timestamp key on logging already exists.
...have ipb_range_start field in ipblocks table.
Setting page_random to a random value on rows where it equals 0...changed 0 rows
...have user_registration field in user table.
...templatelinks table already exists
...externallinks table already exists.
...job table already exists.
...have ss_images field in site_stats table.
...langlinks table already exists.
...querycache_info table already exists.
...filearchive table already exists.
...have ipb_anon_only field in ipblocks table.
Checking for additional recent changes indices...
...index `rc_ns_usertext` seems ok.
...index `rc_user_text` seems ok.
...have user_newpass_time field in user table.
...redirect table already exists.
...querycachetwo table already exists.
...have ipb_enable_autoblock field in ipblocks table.
Checking for backlinking indices...
Checking if pagelinks index pl_namespace includes field pl_from...
...index pl_namespace on table pagelinks seems to be ok
Checking if templatelinks index tl_namespace includes field tl_from...
...index tl_namespace on table templatelinks seems to be ok
Checking if imagelinks index il_to includes field il_from...
...index il_to on table imagelinks seems to be ok
...have rc_old_len field in recentchanges table.
...have user_editcount field in user table.
...page_restrictions table already exists.
...have log_id field in logging table.
...have rev_parent_id field in revision table.
...have pr_id field in page_restrictions table.
...have rev_len field in revision table.
...have rc_deleted field in recentchanges table.
...have log_deleted field in logging table.
...have ar_deleted field in archive table.
...have ipb_deleted field in ipblocks table.
...have fa_deleted field in filearchive table.
...have ar_len field in archive table.
...have ipb_block_email field in ipblocks table.
Checking for categorylinks indices...
Checking if categorylinks index cl_sortkey includes field cl_from...
...index cl_sortkey on table categorylinks seems to be ok
...have oi_metadata field in oldimage table.
...usertext,timestamp key on archive already exists.
...usertext,timestamp key on image already exists.
...usertext,timestamp key on oldimage already exists.
...have ar_page_id field in archive table.
...have img_sha1 field in image table.
...protected_titles table already exists.
...have ipb_by_text field in ipblocks table.
...page_props table already exists.
...updatelog table already exists.
...category table already exists.
...category table already populated.
...have ar_parent_id field in archive table.
...have user_last_timestamp field in user_newtalk table.
...rev_parent_id column already populated.
protected_titles table has correct pt_title encoding.
Checking filearchive indices...
...password hash format already changed
...have ss_active_users field in site_stats table.
...ss_active_users user count set...
...have ipb_allow_usertalk field in ipblocks table.
Deleting old default messages (this may take a long time!)...Done
Checking site_stats row...ok.
Purging caches...done.
Done.

144.92.131.235 (talk) 20:19, 22 December 2011 (UTC)

Upgraded from MediaWiki 1.5.5 to 1.14.1

PHP 5.1.6

MySQL 5.0.22 144.92.131.235 21:44, 22 December 2011 (UTC)

I suggest using a newer version of MediaWiki.  Hazard-SJ  ±  02:27, 24 December 2011 (UTC)

Having absolutely nothing on screen usually indicates a php fatal error. This could be caused by an extension not compatible with MW 1.14, or potentially some config setting that doesn't work with newer mediawiki but did with 1.5 (Generally we try to be careful to make sure we retain backwards compatibility in regards to config settings, or at least fail nicely, but its always possible for something to be incompatible)

It would be helpful if you could put the following at the very top of your LocalSettings.php file (right after the <?php and before anything else):

error_reporting( E_ALL );
ini_set( 'display_errors', 1 );

This would hopefully cause your install to give an error instead of just a blank page. From there we should be able to further track down what the actual cause of the error is (See manual:How to debug for more details on debugging)

p.s. As Hazard-SJ said, MediaWiki 1.14 is still what we'd call an "ancient" version of MediaWiki. Since you're upgrading you may want to consider using 1.18. Bawolff 10:54, 24 December 2011 (UTC)

Installation Extension ConfirmAccount

Hello,

I have troubles installing the "confirm account" extension. I use MediaWiki 1.18., PHP 5.2.17 and MySQL 5.1.49.

I started as described at the page: Loading the current snapshot, install it to the extension directory, writing the require_once line to the localsettings.php. Since I do not have shell access and the maintance script does not work via webbrowser, I used to start the install script in the mw-config folder again.

Unfortunatly, the script stopped during the database update giving the following error messages:

(...)
...user_former_groups table already exists.
Creating account_requests table...
An error occured:
Es gab einen Syntaxfehler in der Datenbankabfrage.
Die letzte Datenbankabfrage lautete: „CREATE TABLE IF NOT EXISTS `account_requests` (
acr_id int unsigned NOT NULL auto_increment PRIMARY KEY,
acr_name varchar(255) binary NOT NULL default ,
acr_real_name varchar(255) binary NOT NULL default ,
acr_email tinytext NOT NULL,
acr_email_authenticated binary(14) default NULL,
acr_email_token binary(32),
acr_email_token_expires binary(14),
acr_bio mediumblob NOT NULL,
acr_notes mediumblob NOT NULL,
acr_urls mediumblob NOT NULL,
acr_ip VARCHAR(255) NULL default ,
acr_filename VARCHAR(255) NULL,
acr_storage_key VARCHAR(64) NULL,
acr_type tinyint(255) unsigned NOT NULL default 0,
acr_areas mediumblob NOT NULL,
acr_registration char(14) NOT NULL,
acr_deleted bool NOT NULL,
acr_rejected binary(14),
acr_held binary(14),
acr_user int unsigned NOT NULL default 0,
acr_comment varchar(255) NOT NULL default 
) ENGINE=MyISAM, DEFAULT CHARSET=mysql4
“ aus der Funktion „DatabaseBase::sourceFile( ixxx/xxx/extensions/ConfirmAccount/ConfirmAccount.sql )“.
Die Datenbank meldete den Fehler: „1115: Unknown character set: 'mysql4' (localhost)“.

Since the database is now corrupted, I need to do a db dump in order to install a previous version.

I used the script without problems before updating my older version to 1.18. When I choose to install confirmaccount, I get error messages, when I uncheck the extension (only installing all the other extensions), it works fine.

Any help is appreciated! 85.181.95.201 (talk) 01:25, 23 December 2011 (UTC)

This is essentially bugzilla:29102. To fix, you need to look for $wgDBTableOptions in LocalSettings.php, and replace CHARSET=mysql4 with CHARSET=binary.

Thus if you had the line

$wgDBTableOptions = 'ENGINE=MyISAM, DEFAULT CHARSET=mysql4';

You'd want to replace it with

$wgDBTableOptions = 'ENGINE=MyISAM, DEFAULT CHARSET=binary';

Bawolff 23:49, 26 December 2011 (UTC)

Thanks for the hint!

I looked into my localsettings, but it already says:

# MySQL table options to use during installation or update

$wgDBTableOptions = "ENGINE=MyISAM, DEFAULT CHARSET=binary";

The strange thing is that updating without using this specific extension works. But as soon as I run the update again with the extension, it fails. 85.181.67.235 00:04, 27 December 2011 (UTC)

I recently tried it again. First, I added

require_once( "$IP/extensions/ConfirmAccount/ConfirmAccount.php" );

to my localsettings (the charset is binary, as said). Then I updated and the same error message as above was shown.

Second, I uncommented ConfirmedAccount

# require_once( "$IP/extensions/ConfirmAccount/ConfirmAccount.php" );

and re-run the update process. The result was that everything worked fine with the update (except that I have the extension not installed):

...have ipb_id field in ipblocks table.

...have ipb_expiry field in ipblocks table.

...already have interwiki table

(...)

...user_former_groups table already exists.

Purging caches...done.

Checking site_stats row...done. 85.181.67.235 00:39, 27 December 2011 (UTC)

Looks like the installer tries to use mysql4 if there are tables with the collation latin1 in the db.

Maybe try updating without the extension like you just did, verify mysql4 is no where in your LocalSettings.php, then re-add the ConfirmAccount extension, and run the command line update.php upgrade script, and see if that works. Bawolff 08:11, 29 December 2011 (UTC)

It works fine if I update without this extension. But if I try to re-add the extension, it fails. Since I have no shell access, I can only use the install script using my browser (but I guess it does the same as update.php?).

My localsettings.php includes no mysql4 entry. It says:

<?php

# This file was automatically generated by the MediaWiki 1.18.0

# installer. If you make manual changes, please keep track in case you

# need to recreate them later.

#

# See includes/DefaultSettings.php for all configurable settings

# and their default values, but don't forget to make changes in _this_

# file, not there.

#

# Further documentation for configuration settings may be found at:

# Manual:Configuration settings

# Protect against web entry

if ( !defined( 'MEDIAWIKI' ) ) {

exit;

}

## Uncomment this to disable output compression

# $wgDisableOutputCompression = true;

$wgSitename = "xxx";

$wgMetaNamespace = "xxx";

## The URL base path to the directory containing the wiki;

## defaults for all runtime URL paths are based off of this.

## For more information on customizing the URLs please see:

## Manual:Short URL

$wgScriptPath = "";

$wgScriptExtension = ".php";

## The protocol and server name to use in fully-qualified URLs

$wgServer = "http://xxx.xxx";

## The relative URL path to the skins directory

$wgStylePath = "$wgScriptPath/skins";

## The relative URL path to the logo. Make sure you change this from the default,

## or else you'll overwrite your logo when you upgrade!

$wgLogo = "$wgStylePath/common/images/xxx.gif";

## UPO means: this is also a user preference option

$wgEnableEmail = true;

$wgEnableUserEmail = true; # UPO

$wgEmergencyContact = "xxx";

$wgPasswordSender = "xxx";

$wgEnotifUserTalk = true; # UPO

$wgEnotifWatchlist = true; # UPO

$wgEmailAuthentication = true;

## Database settings

$wgDBtype = "mysql";

$wgDBserver = "localhost";

$wgDBname = "xxx";

$wgDBuser = "xxx";

$wgDBpassword = "xxx";

# MySQL specific settings

$wgDBprefix = "";

# MySQL table options to use during installation or update

$wgDBTableOptions = "ENGINE=MyISAM, DEFAULT CHARSET=binary";

# Experimental charset support for MySQL 4.1/5.0.

$wgDBmysql5 = false;

## Shared memory settings

$wgMainCacheType = CACHE_NONE;

$wgMemCachedServers = array();

## To enable image uploads, make sure the 'images' directory

## is writable, then set this to true:

$wgEnableUploads = true;

#$wgUseImageMagick = true;

#$wgImageMagickConvertCommand = "/usr/bin/convert";

# InstantCommons allows wiki to use images from http://commons.wikimedia.org

$wgUseInstantCommons = true;

## If you use ImageMagick (or any other shell command) on a

## Linux server, this will need to be set to the name of an

## available UTF-8 locale

$wgShellLocale = "en_US.utf8";

## If you want to use image uploads under safe mode,

## create the directories images/archive, images/thumb and

## images/temp, and make them all writable. Then uncomment

## this, if it's not already uncommented:

#$wgHashedUploadDirectory = false;

## Set $wgCacheDirectory to a writable directory on the web server

## to make your wiki go slightly faster. The directory should not

## be publically accessible from the web.

#$wgCacheDirectory = "$IP/cache";

# Site language code, should be one of the list in ./languages/Names.php

$wgLanguageCode = "de";

$wgSecretKey = "xxx";

# Site upgrade key. Must be set to a string (default provided) to turn on the

# web installer while LocalSettings.php is in place

$wgUpgradeKey = "xxx";

## Default skin: you can change the default skin. Use the internal symbolic

## names, ie 'standard', 'nostalgia', 'cologneblue', 'monobook', 'vector':

$wgDefaultSkin = "vector";

## For attaching licensing metadata to pages, and displaying an

## appropriate copyright notice / icon. GNU Free Documentation

## License and Creative Commons licenses are supported so far.

$wgRightsPage = ""; # Set to the title of a wiki page that describes your license/copyright

$wgRightsUrl = "";

$wgRightsText = "";

$wgRightsIcon = "";

# $wgRightsCode = ""; # Not yet used

# Path to the GNU diff3 utility. Used for conflict resolution.

$wgDiff3 = "/usr/bin/diff3";

# Query string length limit for ResourceLoader. You should only set this if

# your web server has a query string length limit (then set it to that limit),

# or if you have suhosin.get.max_value_length set in php.ini (then set it to

# that value)

$wgResourceLoaderMaxQueryLength = 1024;

# Enabled Extensions. Most extensions are enabled by including the base extension file here

# but check specific extension documentation for more details

# The following extensions were automatically enabled:

require_once( "$IP/extensions/ConfirmEdit/ConfirmEdit.php" );

require_once( "$IP/extensions/Gadgets/Gadgets.php" );

require_once( "$IP/extensions/Nuke/Nuke.php" );

require_once( "$IP/extensions/Renameuser/Renameuser.php" );

require_once( "$IP/extensions/Vector/Vector.php" );

require_once( "$IP/extensions/WikiEditor/WikiEditor.php" );

require_once( "$IP/extensions/Description/Description.php" );

# require_once( "$IP/extensions/ConfirmAccount/ConfirmAccount.php" );

# End of automatically generated settings.

# Add more configuration options below. 85.181.74.78 21:59, 30 December 2011 (UTC)

File icon disappears after new installation

Hi there,

after a new installation of mediawiki the icons in front of the files (e.g. XLS) dissapear. I figured out, the path to the definitions is wrong. Can anyone tell me the place, where I can define the path to the icons?

atm it looks like this: http://(servername)/wiki/images/fileicons/DOC.png without the brackets.

I have to add the port behind the servername...

Thanks in advance... 82.135.122.142 (talk) 11:12, 23 December 2011 (UTC)

try setting $wgServer explicitly in your LocalSettings.php

If all else fails you can try setting $wgStylePath also in LocalSettings.php, but generally that variable is automatically set based on $wgServer and $wgScriptPath, and if $wgServer is wrong, several other variables will be wrong (often causing symptoms like http redirects (like when saving a page or doing ?action=purge ) not working) Bawolff 23:38, 26 December 2011 (UTC)

I can`t find $wgServer in LocalSettings....

there`s just $wgDBserver...

Now it causes more problems then that...

Please have a look at Project:Support desk#server name 10737

Thanks

Can be closed!!! It2010bg 10:46, 11 January 2012 (UTC)

You can add $wgServer = 'http://www.mediawiki.org'; as needed and even if it's not yet present. See Manual:$wgServer for more info. Varnent 16:31, 11 January 2012 (UTC)

Wrong classification in Category pages (classified as "<")

Hi,

i'am with a problem in a category page. Two pages aren't classified with the right character.

This is my case:

I have two article pages (ClienteWebService and ContasWebService) with the category BVP in them. When I load the BVP category page, it listed this article:

<

• ClienteWebService
• ContasWebService

B

• BVP - GuideLine

E

• EnumSituacao

and so on.

Why must I do to correct it?

Thanks Crismagnabosco (talk) 13:53, 23 December 2011 (UTC)

If you have a link to your wiki, that would be helpful. On the page ClienteWebService do you have something like [[category:BVP|<....]] or other formatting characters in the part after the pipe (|) of the category link?

The output of http://<PUT-WHATEVER-MY-WEBSITE-IS-HERE>/w/api.php?action=query&list=categorymembers&cmtitle=Category:BVP&cmprop=ids|title|sortkey|sortkeyprefix would be helpful Bawolff 23:33, 26 December 2011 (UTC)

thanks, it was this :) 201.55.240.5 18:54, 2 January 2012 (UTC)

Edit Toolbar Missing

I have installed a Wiki, 1st everything was ok, but suddenly the edit toolbar when editing pages is gone.

I have reinstalled everything again from the start and its not working.

You can see it here, now wiki is open, so you can check, then once fixed I'll reinstall it.

http://wiki.travianer.com.ar/

I also had some problem with the style sheet not loading properly.

I have not much experience with MediaWiki and I have not clue, why this is happening. Any help?

Thanks a lot... 201.252.38.64 (talk) 14:47, 23 December 2011 (UTC)

Your web host is adding the following to the bottom of MediaWiki's javascript files:

<!-- www.000webhost.com Analytics Code -->
<script type="text/javascript" src="http://analytics.hosting24.com/count.php"></script>
<noscript><a href="http://www.hosting24.com/"><img src="http://analytics.hosting24.com/count.php" alt="web hosting" /></a></noscript>
<!-- End Of Analytics Code -->

Since this is html and not javascript, this breaks MediaWiki's js, which breaks the edit toolbar.

You should probably contact your hosting provider and complain. Bawolff 23:28, 26 December 2011 (UTC)

Thx, I will try to find how to avoid that code for been added to the .js files 186.108.196.18 20:55, 28 December 2011 (UTC)

Images red link use size instead of filename

I searched about it before starting this, but i can't find any explanation why when an image doesn't exist on the wiki yet and the code specifiy a size for it, the text of the red link to upload it become something like "100px" or "32px". I wasn't doing this in previous version of the software...

Exemple, i have a template that construct the filename based on the pagename like this :

[[File:{{PAGENAME}} - logo.png|32px]]

It result in a 32px red link instead of the name of the file. I think that users will be confused and don't understand what file to upload. Maybe there isn't many wikis that like having red links to files before they gets uploaded, but i have an history on gamming wikis where it's the way we do things. On thoses, most pages have an infobox with an image (or two) that the creator of the page dont necessarly have at had with creating the page. And i have an history with french wikis where the contributors number is really low and where passing by users dont know wikis much, and a 180px red link wont tell them they can upload a picture of... the thing wich the page is talking about.

Why im telling all this is because i went to several others wikis to test this an it produce the same result so for me it's the software that one day becamed a tad silly about this. I think most people didn't see this as been bad in any way because they might be uploading their images by the name they want and filling in that information into the infobox instead of having the template auto generating link and uploading later or letter other upload later. I'm also aware that on some wikis the infoboxes show a temporary image instead, but i dont like it much. I think it's harder on the wiki to use "#ifexist:" on the constructed filename. Ok, that is because i insist on having the name of the file autoconstructed, for me it's just logical. I can explain why more lenghtly if needed.

Thanks. TulipVorlax (talk) 14:28, 24 December 2011 (UTC)

It becomes 32px becuase if the image isn't there its treated as a normal link - you can use variables like {{PAGENAME}} in #ifexists.

What do you think the ideal behaviour should be instead? Bawolff 01:59, 25 December 2011 (UTC)

I agree with TulipVorlax.

There is two ways of linking to files. For files the default [[bracket]] notation will attempt to embed the file, and the [[:colon bracket]] is for linking to the file description page.

I would expect that the embedding syntax will fallback to something that makes sense for the embedding syntax, not something that makes sense in the description-page-link syntax.

Right now attempting to embed a file (or embedding a file that would be deleted tomorrow) would result in the second pipe-parameter being used as linktext, which doesn't make any sense for the embed-syntax.

Examples:

• Embed syntax, image exists: [[File:Example.jpg|20px]]
  
• Link syntax, image exists: [[:File:Example.jpg|more info about image]]
  more info about image
• Embed syntax, image doesn't exists: [[File:Something else random.jpg|20px]]
  File:Something else random.jpg
• Link syntax, image doesn't exists: [[:File:Something else random.jpg|more info about image]]
  more info about image

As of writing this generates:

• Thumnail embed
• Link to page "File:Example.jpg" with link text "more info about image"
• Link to url "//www.mediawiki.org/w/index.php?title=Special:Upload&wpDestFile=Something_else_random.jpg" with link text "20px"
• Link to url "//www.mediawiki.org/w/index.php?title=File:Something_else_random.jpg&action=edit&redlink=1" with link text "more info about image"

The third one is wrong Krinkle 17:40, 25 December 2011 (UTC)

It's sure that i can live with it, for now. My new project is something i'm starting up and if Google already know about it, almost nobody know about it. It's like the resurrection of a project that i had when i was on Wikia but with a small twist. It's not exactly the same.

What i think about the red 20px links is that it sould be something else. Anything whould be better. But if i must choose, i would make it go back the way it was before, putting the name of the destination file as a red link. I would gracefully accomodate myself with an extension that would do this instead of a global change to the software. Sadly, i'm not a good enough PHP coder.

Thanks. TulipVorlax 17:33, 30 December 2011 (UTC)

I talked to the devs on IRC about it and I doubt this will be changed. Subfader 19:19, 30 December 2011 (UTC)

Thanks for trying. Maybe someday someone would come up with an extension for this but it seems unlikely. TulipVorlax 23:24, 30 December 2011 (UTC)

Well as a quick hack, add the following to the bottom of your LocalSettings.php:

$wgHooks['ParserMakeImageParams'][] = 'wfFixMissingImageLink';
function wfFixMissingImageLink( $title, $file, &$params ) {
        if ( !$file && $title ) {
                # File doesn't exist. (Page could potentially though)
                $newTextForImgLink = $title->getFullText(); # Full name of page.
                # Alternatively could be something like 
                # $newTextForImgLink = 'Upload ' . $title->getText();
                $params['frame']['title'] = $newTextForImgLink;
        }
        return true;
}

(That won't change things for situations like the image is on bad image list, the page name is prefixed with a colon, or image doesn't have a media handler.)

-----

I do agree that we should handle this situation better in core. Bawolff 12:47, 31 December 2011 (UTC)

Oh wow ! Thanks a real lot ! It work !

Sorry for not having returned here sooner. I got a warning about a new mediawiki version and was trying to get the full release notes (the link on main page point to a page with a broken link) when i saw that i had a new message.

Looking at that code it seems so easy but i would have never been able to do it myself. TulipVorlax 15:34, 13 January 2012 (UTC)

Preventing account creation from certain IP ranges

I want to prevent account creation from certain IP ranges. How one can do this without compromising the ability of the existing users to edit from these IP ranges?

Victor Victor Ivrii (talk) 11:32, 27 December 2011 (UTC)

Note, you can block a range of ips well still allowing logged in users to edit from that range but not allowing people to create new accounts from inside that range(but anons can't edit from that range)

If you can't find support in mediawiki for doing what you need to do, you can look into using/creating an extension that hooks into AbortNewAccount Bawolff 02:27, 28 December 2011 (UTC)

If it's index an extension you'd like created and aren't sure how or don't want to create it - you may want to request the extension. Good chance someone will take it on.  :) Varnent 00:12, 3 January 2012 (UTC)

How do I remove the option for Pedia Press to print books in Collection?

This is a very important legal issue, as I cannot enable the extension until I figure out how to remove the ability to send books created from wiki content to Pedia Press for printing for sale.

Link to the extension on MediaWiki.org Extension:Collection

Does anyone know how to do this? I really want users to be able to use this extension and create books from the content which will be easier to read, but it would not be legal for Pedia Press to be making money off of them. I need to figure out how to disable this feature. MediaWiki Website User (talk) 20:11, 27 December 2011 (UTC)

Seems kind of hard coded in that extension... In Collection.body.php the lines:

        var $mPODPartners = array(
                'pediapress' => array(
                        'name' => 'PediaPress',
                        'url' => 'http://pediapress.com/',
                        'posturl' => 'http://pediapress.com/api/collections/',
                ),
        );

is probably what you want to change. You'd probably still want to keep a 'pediapress' key to the array, since it seems hardcoded to expect that. However, if you change the name, url and posturl it would use a different service. If you don't want any printing service whatsoever, you may have to make more significant changes to the extension (In Collection.template.php mostly). Bawolff 02:13, 28 December 2011 (UTC)

Is this a common enough problem that an option to disable it within the extension should be considered? Varnent 21:26, 28 December 2011 (UTC)

meh, personally I don't like how the collection extension is so closely tied to pediapress, but I suppose that's a reflection of who wrote the extension Bawolff 06:04, 29 December 2011 (UTC)

Well, it's a serious problem for any wiki which has content or is about something which it does not own itself, such as a video game wiki encyclopedia or something like that. MediaWiki Website User 05:49, 30 December 2011 (UTC)

I've started a discussion about adding this as an option. If there are no objections, I think we can add it in a few weeks time. The original developer may add it sooner if they're interested and don't object. Feel free to chime in there.  :) Varnent 00:09, 3 January 2012 (UTC)

That would be great. MediaWiki Website User 14:37, 4 January 2012 (UTC)

I have proposed a patch, see the linked discussion. CristianCantoro (talk) 11:48, 13 March 2012 (UTC)

I have commited a hopefully right fix in r113740.  « Saper // talk »  18:42, 13 March 2012 (UTC)

I have commited a hopefully right fix in r113740.  « Saper // talk »  18:42, 13 March 2012 (UTC)

The fix is now part of Collection extension version 1.6 and has even been deployed on the Wikimedia sites (although they don't change POD configuration).  « Saper // talk »  21:56, 3 May 2012 (UTC)

Saper, that is great!

Thank you! :-) 88.130.71.112 12:57, 4 May 2012 (UTC)

Unified Login changed in past week: no longer possible to login to single account?

I unified my logins last year, but have almost always checked the box to login into a single account any time I logged in since then. In fact, I regretted unifying my accounts. Last week, I was still able to check the 'single login' box at login. Today upon login, I see that option has disappeared.

--Is this an error/bug, or was this planned?

--I see that this results in multiple account login being the default, is there any way to bypass this? I'm really unhappy with being forced to login to multiple accounts. Tallard (talk) 06:15, 28 December 2011 (UTC)

Yeah it was removed as of about december 20. See discussion on bugzilla:20852. Bawolff 07:11, 28 December 2011 (UTC)

You seem to be using very few accounts, so you could just disable cookies on wikis where you don't want to log in, couldn't you? Nemo 08:58, 28 December 2011 (UTC)

Piece of a crap, I'm old and have 4 different logins, now I need to log out every time, and I'm creating a lot of login that I will never go use... ¬¬ I just had a login unified, now I have four, for what? Rodrigo Tetsuo Argenton 00:22, 6 January 2012 (UTC)

Flagged Reviews on als.wikipedia.org

Ever since flagged revisions were introduced, there has been a small nuisance on http://als.wikipedia.org. When editors who are not admins edit outside of the article mainspace, their edits are not automatically marked as reviewed. But when admins edit there, there is no problem. Does anyone have an idea on how to fix this? Terfili (talk) 07:40, 28 December 2011 (UTC)

Dynamic header image

Although it seems to be poorly documented on this site, most MW skins allow you to specify a banner image as the background for the header. However, what if you (like me) want to be able to choose different header images on a per-page/per-template basis? If, for instance, you have a website about bicycles, cars and helicopters, it would make good sense to have a number of thematic variations on the default header image. The change of image would then be triggered by a template used on the page.

Would it be somehow possible to do this? Or does anyone have alternative ideas? The only alternative I can think of is to change the logo (rather then the header) on a per-page basis using Extension:Logotipo. Cavila 15:32, 28 December 2011 (UTC) You can use css perhaps.

For example on vector (in mediawiki:Vector.css)

body.ns-1 #mw-head {background-image: url( http://somewhere/someimage.png );}

Would change the background at the very top of the page to someimage.png for any talk page (talk is namespace 1. All namespaces have there own number. The main (article) namespace is namespace 0).

You can also do per-page changes: </pre> body.page-Extension_Logotipo #mw-head {background-image: url( http://somewhere/someimage.png ); } </pre> would change it on extension:Logotipo only.

If you want to do something in a template, you'd probably need to create a custom extension. Bawolff 08:29, 29 December 2011 (UTC)

Thanks. Although I'm not using separate namespaces myself, your first suggestion does look like it could be a workable solution for many users. As for myself, a custom extension would certainly be the way to go. Extension:Logotipo looks childishly simple, but I don’t have any experience with writing code. There at least three extensions which claim to provide custom headers on a per-page basis but just what is meant by 'headers' in those cases is not clear to me and none appears to be fully functional:

• Extension:HeadersFooters, recent but not yet 'production ready' according to the author - I'll notify him of this discussion FWIW.
• Extension:Header Footer, old, unmaintained, dependent on PEAR and probably broken
• Extension:DynamicSkin, last updated in 2007 and most likely broken Cavila ^{MW 1.17, MySQL 5.5.16, Php 5.3.8} 15:16, 29 December 2011 (UTC)

Cavila, My extension HeadersFooters inserts a header/footer into the text of an article before it is parsed. The idea is that you can also insert wikitext and most importantly things like the references tag for cite and it will work. Unfortunately MW is not made to insert text only for the display (and not for edit) at that point, so things are very buggy as I find new cases when editing or saving the text adds the header/footer into the actual article. Once I work them all out, I'll consider it in the beta stage. An extension that doesn't depend on the content of the article would be much simpler, and could be done post-article processing. I'm not sure if the old HeaderFooter extension did this or not, it's certainly more error proof but means that your header/footer has to be free standing (you can't use a cite tag, there are no known citations to list!) I don't see progress being made quickly on my extension but I'm committed to continuing the work as I learn more about MW. Olivier Beaton 15:41, 29 December 2011 (UTC)

Oh, I see, thanks for the explanation.

If you happen to know of a working example, it would be worthwhile adding one to the documentation, but maybe it's too early for that now. Cavila ^{MW 1.17, MySQL 5.5.16, Php 5.3.8} 14:14, 2 January 2012 (UTC)

In the meantime, I found an extension that should do the trick: see Extension:CSS. Cavila ^{MW 1.17, MySQL 5.5.23, Php 5.3.10, SMW 1.7.1} 20:31, 17 September 2012 (UTC)

On second thought, wikEd no longers works after Extension:CSS is activated, so it may not be a good idea after all. Cavila ^{MW 1.17, MySQL 5.5.23, Php 5.3.10, SMW 1.7.1} 11:35, 18 September 2012 (UTC)

moving pages

Why cant i move pages, has this been disabled?

I want to move Manual:Pywikipediabot/Use_on_non-WMF_wikis to Manual:Pywikipediabot/Use_on_non-Wikimedia_foundation_wikis Igottheconch (talk) 07:44, 29 December 2011 (UTC)

For reference, Project:Current_issues would probably be a better place to ask that type of question.

Probably its because Manual:Pywikipediabot/Use_on_non-WMF_wikis uses flagged revs, and only people who have the ability to sight stuff can move pages that use flagged revisions ( the movestable right is needed). [personally I'm not really sure having that right restricted is a good thing for this wiki].

correction: It appears this post is incorrect. Sorry about that. Bawolff 08:45, 29 December 2011 (UTC)

thank you bawolff, you are always consistently so helpful! happy new year. Igottheconch 09:28, 29 December 2011 (UTC)

Please don't copy-paste to overcome a problem with moving. Copy-paste violates the site copyright as there is no trail to the page history and thus no credit to authors and even if you add a link in the edit summary, it really can make a mess as any edits to the new page would have to be history merged (see also Manual:Administrators). Fortunately, nobody edited the page before I noticed this thread. I deleted the copy-paste and undid the redirect and then moved the page, as well as the talk page and subpage, the right way. Let me know if you see any issues with where things are. Doug.^{(talk • contribs)} 13:37, 29 December 2011 (UTC)

thank you. Igottheconch 19:05, 29 December 2011 (UTC)

I am, however, confused about why you couldn't move the page unless you tried after you had created the paste version (in which case you would have been unable to make the move due to the existing page). You should have the correct user rights as they appear to belong to all autoconfirmed users. I've asked Bawolff if they understand the issue (see User_talk:Bawolff#Moving_pages) Doug.^{(talk • contribs)} 19:55, 29 December 2011 (UTC)

i did not see a "move" tab.

Using Vector skin.

Internet explorer 9.0

Screen shot: Igottheconch 23:20, 29 December 2011 (UTC)

Click the arrow next the Watch star and "Move" should appear Peachey88 01:12, 30 December 2011 (UTC)

I must of misread the special:usergrouprights. Whoops (maybe I was going through that page too fast. I saw the original page was sighted, which made me think it was some sort of flagged revs issue, and noticed the movestable right).

Re: Igottheconch: normally the move tab is in the drop down box beside the star icon for watching, is there anything in that drop down? Bawolff 00:36, 30 December 2011 (UTC)

I must of misread the special:usergrouprights. Whoops (maybe I was going through that page too fast. I saw the original page was sighted, which made me think it was some sort of flagged revs issue, and noticed the movestable right).

Re: Igottheconch: normally the move tab is in the drop down box beside the star icon for watching, is there anything in that drop down? Bawolff 00:36, 30 December 2011 (UTC)

Reference and #tag:ref no more work together in Mediawiki 1.18.0

Hello,

here is a template (Template:Remark) using the #tag:ref

{{#tag:ref|{{{2}}}|group=remark|{{{1}}}|{{{2}}}|{{{1}}}|{{{2}}}|remark}}

argument {{{1}}} is the part of the text where the remark is set.
argument {{{2}}} is the text of the remark.

and here is an example of a Wiki Page using the Remark template with and without a reference in the "remark text" (second argument)

Page :

Some text {{Remark|This is a remark without any reference|No reference}} some other text<ref>Reference outside remark</ref>

Some more text {{Remark|This is a remark|Reference included<ref>Reference inside remark</ref>}} some more other text

== Remarks ==
<references group="remark" />

== References ==
<references />

---

The result given by MW 1.18.0 may be seen here : http://wikinfo.eu/index.php/Reference_error
The result given by MW 1.17.0 may be seen here : http://de942.ispfr.net/wikisys/index.php/Reference_error

Could someone tell us what to do to fix this?

Best. Champagne (talk) 17:55, 29 December 2011 (UTC)

I think its something specific to your setup (some other extension interfering, different version of Cite extension, etc. Not entirely sure).

Here's what I did to try to test:

• enabled cite
• copied template:Remark and Reference_error to my wiki

It worked fine for me on both 1.18 as well as trunk (1.19alpha). Bawolff 07:25, 30 December 2011 (UTC)

And scratch that. Looks like my copy of 1.18 was 1.18wmf1, not 1.18.0. On 1.18.0 I can reproduce your issue. Bawolff 07:29, 30 December 2011 (UTC)

Appears issue was fixed in rev:99062 (which happened after 1.18 was released). Bawolff 07:43, 30 December 2011 (UTC)

Thanks, it works now fine. Champagne 16:49, 30 December 2011 (UTC)

search function does NOT include similar characters like "á" and "a"

Mediawiki 1.16.6 PHP 5.3.6 MySQL 5.5.13 WE have an article in our WIKI called Ernesto Famá So the last character is an "á" Searching to Fama leads to no result? Any ideas? Donxello 21:33, 29 December 2011 (UTC)

That's the technically correct result returned by the default database search. For a more advanced search you need to install an indexing serach engine, e.g. Lucene. Subfader 23:09, 29 December 2011 (UTC)

Thanks Subfader for you reply. Are you experienced in installing this extension because after reading the documentation it's not so easy.

If so please contact me that we agree on a price :)

Cheers Donxello 13:24, 8 January 2012 (UTC)

No I don't use it. You can hire someone on http://www.mwusers.com/forums/forumdisplay.php?45-MediaWiki-Jobs Subfader 15:37, 8 January 2012 (UTC)

Yes, the default MW search engine is notoriously limited I'm afraid. Another oversight in search results occurs when a word is preceded by a quotation mark. For any extra functionality, you might be able to do two things:

(1) Install a search engine such as Lucene or Sphinx, as Subfader already suggested, and an appropriate MW extension (for a list see my user page). Unfortunately, this may not be an option for the average user, because it requires shell access. If you're on a shared host, you're probably out of luck, but contacting your hosting company can do no harm.

(2) use an external search engine such as Google. One serious downside to this strategy is that it may be slow on updates.

See also Search (though it rather shows how much things have remained still).

Of course, you can always redirect "Ernesto Fama" to "Ernesto Famá". Cavila ^{MW 1.17, MySQL 5.5.16, Php 5.3.8} 16:18, 8 January 2012 (UTC)

How to add "approve page for visible"

Hi, i would like funkcinonality which automatically doesn´t publick new site, but add this site for "approve" . Once is site approved, this site is showed on wiki.

Thanks 216.245.47.34 (talk) 09:27, 30 December 2011 (UTC)

MediaWiki is no CMS. Subfader 14:13, 30 December 2011 (UTC)

-( ok, thanks 216.245.47.34 07:04, 2 January 2012 (UTC)

You could do nasty template tricks with dates but not the standard CMS features like aproving articles by "authors" for the public. Subfader 15:57, 2 January 2012 (UTC)

Hiding of language selector possible ?

How can I hide the language selector on each page with MediaWiki 1.17.0 ?

For others: I already found this similar threads:

• hiding selector in preferences of the user

$wgHiddenPrefs[] = 'language';

on reference Manual:$wgLanguageCode

• disabling unused languages (a german thread)

on reference Manual:$wgLanguageCode/de

But that's not what I mean. My local Wiki needs no language selector. How can I get rid of it.

Thank you for answering ... StephenFalken~mediawikiwiki (talk) 21:47, 30 December 2011 (UTC)

You could hide the sidebar entry via MediaWiki:Common.css. To disable the user pref, see $wgHiddenPrefs. To use a certain language as default see $wgDefaultUserOptions. To roll back all possible prior language settings to a default use maintenance/userOptions.php Subfader 16:33, 31 December 2011 (UTC)

Thank you for answering so fast, Subfader.

"You could hide the sidebar entry via MediaWiki:Common.css."

Please could you give me an example for this ... ? Of course I use Common.css but only for my background color settings. I'm not really familiar with CSS for hiding something.

"To disable the user pref, see $wgHiddenPrefs.

To use a certain language as default see $wgDefaultUserOptions.

To roll back all possible prior language settings to a default use maintenance/userOptions.php."

Thats not what I need. In my Wiki there is a select box straigth under the page title. I want to disable or hide this language selector because I don't like it in my layout. In my older system (MediaWiki 1.15.0) there is no such a language selector ... StephenFalken 01:58, 2 January 2012 (UTC)

It sounds like you installed an extension to specifically do that. MediaWiki doesn't do that by itself. You should disable that extension (Which extensions you have enabled should be visible on Special:Version ).

The language selector in special:preferences really doesn't affect page content, and I can't imagine that you actually want to hide that. Bawolff 07:50, 2 January 2012 (UTC)

Thank you for this information. You'are right ... one collegue has installed a new extension language selector without informing me ... and he also forget to migrate the extension from 1.15.0 to 1.17.0  :-)

Shame on me :-(

Sorry for boring you ...

May this thread help others in the same situation! StephenFalken 11:47, 2 January 2012 (UTC)

Why don't mediawiki use css sprite on vector skins?

vector skins did not change frequently

Why don't we combine all those small pictures into one picture? 71.201.158.52 (talk) 00:59, 31 December 2011 (UTC)

I guess cos customizing is harder then. Subfader 16:29, 31 December 2011 (UTC)

No, customizability was not the reason not to use sprites.

In the past the Vector skin did use some sprites, but since MediaWiki has ResourceLoader we've de-sprited everything. ResourceLoader comes with a feature to convert referenced images into embedded Data URIs. That gives the power of sprites (loading all images in a single request) and the power of separate images (customizability).

Data URI embedding is even better than sprites also in terms of requests, as with a sprite there is a request for the CSS file and one for the sprite. With data URL embedding there is only request for the CSS file and that contains all images inside of it.

See also this slide. And the two presentations on the "more info" list here. Krinkle 20:34, 1 January 2012 (UTC)

Angry-autoblock

What is the difference between a normal autoblock and an "angry-autoblock"? In this case, I refer specifically to the AbuseFilter extension, where when it blocks, it blocks as an "angry-autoblock". Hazard-SJ (talk) 03:37, 31 December 2011 (UTC)

Is anyone aware?  Hazard-SJ  ±  03:21, 2 January 2012 (UTC)

A normal auto-block will block the last IP used by the user being blocked. An angry autoblock would (historically) "Block any IP used in the last 7 days. Up to five IPs".

However, support for angry autoblocking was removed in rev:92220. It appears there's still messages related to it in Logging code and abuse filter though (?) Bawolff 07:42, 2 January 2012 (UTC)

OK, thanks. I guess abusefilter needs updating :P  Hazard-SJ  ±  22:41, 4 January 2012 (UTC)

parserfunctions help

Is there a beginner's version of Help:Extension:ParserFunctions? I found a template on a talk page I could adapt to mostly do what I wanted but when a field is empty it leaves a line blank (see [http://argumentrix.com/wiki/Governments_should_recognize_both_opposite_and_same_sex_marriages here for an example), on the right under "external articles by viewpoint", all that whitespace is unused template calls) and it takes up space. Thanks, Modrobene Modrobene (talk) 06:47, 31 December 2011 (UTC)

Some general tips with parserfuncs (may or may not help you in your situation): Try making sure there are no newlines between the parser func calls. If mediawiki's table format is constricting, try using html table syntax instead (Which doesn't care about whitespace) Bawolff 12:59, 31 December 2011 (UTC)

Thanks for the tip! That didn't help though, removing the new lines broke the parser functions completely. Modrobene 15:15, 31 December 2011 (UTC)

No access to Restricted Special Pages

Mediawiki 1.16.5 PHP 5.3.4 MySQL 5.0.92

Hi, we're running a wiki at http://wiki.fractalaudio.com/axefx2.

Problem is this: I have Administrator rights but I can't access the page Restricted Special Pages. I need that to give someone else Admin rights. The person who has Bureaucrat rights has himself locked out one way or another.

How can we fix this? I have FTP access to the server.

Thanks a lot already! Cheers, Alexander 83.86.193.229 (talk) 13:04, 31 December 2011 (UTC)

You can't access Special:UserRights? Dunno then. If you have access to the database you could edit the userrights table manually. If not, wait for someelse to reply --Subfader 16:27, 31 December 2011 (UTC)

Add $wgGroupPermissions['sysop']['userrights'] = true;

to LocalSettings.php via FTP. —Emufarmers^(T|C) 18:58, 31 December 2011 (UTC)

Thanks. Did so but page is still not accessible (no link). 83.86.193.229 16:01, 1 January 2012 (UTC)

I accessed the page on your site and got this:

You do not have permission to do that, for the following reason:

You must log in with an administrator account to assign user rights.

So, it looks like the settings change Subfader suggested did take effect. Are you sure you are logged in properly and that your account is really set to sysop?    Thorncrag   15:05, 2 January 2012 (UTC)

Bureaucrat made me "Administrator", thinking that it would suffice.

Seems like it doesn't.

Is there a file I can edit manually? 83.86.193.229 14:09, 3 January 2012 (UTC)

If you added the line that Emufarmers suggested to your LocalSettings.php, that should have permitted you to access the Special:UserRights page - what exactly is there error that you are encountering? If you added the line, you should make sure that there is not another line later in the file that does the same thing but has "bureaucrat" instead of sysop. On your list of Special pages you are looking for the link "User rights management" under the section "Users and rights."    Thorncrag   14:47, 3 January 2012 (UTC)

Note, according to http://wiki.fractalaudio.com/axefx2/index.php?title=Special:ListGroupRights , admins don't have the 'userrights' right, which means there's probably something wrong with what you set in your LocalSettings.php (as others have said). Make sure the $wgGroupPermissions['sysop']['userrights'] = true; is the very last line in LocalSettings.php Bawolff 03:09, 4 January 2012 (UTC)

Thanks for you help, people. This is what's currently in LocalSettings.php:

<?php
# This file was automatically generated by the MediaWiki installer.
# If you make manual changes, please keep track in case you need to
# recreate them later.
#
# See includes/DefaultSettings.php for all configurable settings
# and their default values, but don't forget to make changes in _this_
# file, not there.
# If you customize your file layout, set $IP to the directory that contains
# the other MediaWiki files. It will be used as a base to locate files.
if( defined( 'MW_INSTALL_PATH' ) ) {
	$IP = MW_INSTALL_PATH;
} else {
	$IP = dirname( __FILE__ );
}
$path = array( $IP, "$IP/includes", "$IP/languages" );
set_include_path( implode( PATH_SEPARATOR, $path ) . PATH_SEPARATOR . get_include_path() );
require_once( "includes/DefaultSettings.php" );
# If PHP's memory limit is very low, some operations may fail.
# ini_set( 'memory_limit', '20M' );
if ( $wgCommandLineMode ) {
	if ( isset( $_SERVER ) && array_key_exists( 'REQUEST_METHOD', $_SERVER ) ) {
		die( "This script must be run from the command line\n" );
	}
}
## Uncomment this to disable output compression
# $wgDisableOutputCompression = true;
$wgSitename         = "Fractal Audio Systems Wiki";
## The URL base path to the directory containing the wiki;
## defaults for all runtime URL paths are based off of this.
$wgScriptPath       = "";
## For more information on customizing the URLs please see:
## http://www.mediawiki.org/wiki/Manual:Short_URL
$wgEnableEmail      = true;
$wgEnableUserEmail  = true;
$wgEmergencyContact = "webmaster@fractalaudio.com";
$wgPasswordSender = "webmaster@fractalaudio.com";
## For a detailed description of the following switches see
## http://meta.wikimedia.org/Enotif and http://meta.wikimedia.org/Eauthent
## There are many more options for fine tuning available see
## /includes/DefaultSettings.php
## UPO means: this is also a user preference option
$wgEnotifUserTalk = true; # UPO
$wgEnotifWatchlist = true; # UPO
$wgEmailAuthentication = true;
$wgDBtype           = "mysql";
$wgDBserver         = "localhost";
$wgDBname           = "wiki";
$wgDBuser           = "fractalwiki";
$wgDBpassword       = "";
$wgDBport           = "5432";
$wgDBprefix         = "";
# MySQL table options to use during installation or update
$wgDBTableOptions   = "TYPE=InnoDB";
# Schemas for Postgres
$wgDBmwschema       = "mediawiki";
$wgDBts2schema      = "public";
# Experimental charset support for MySQL 4.1/5.0.
$wgDBmysql5 = false;
## Shared memory settings
$wgMainCacheType = CACHE_NONE;
$wgMemCachedServers = array();
## To enable image uploads, make sure the 'images' directory
## is writable, then set this to true:
$wgEnableUploads       = true;
$wgUseImageMagick = true;
$wgImageMagickConvertCommand = "/usr/bin/convert";
## If you want to use image uploads under safe mode,
## create the directories images/archive, images/thumb and
## images/temp, and make them all writable. Then uncomment
## this, if it's not already uncommented:
# $wgHashedUploadDirectory = true;
## If you have the appropriate support software installed
## you can enable inline LaTeX equations:
$wgUseTeX           = true;
$wgLocalInterwiki   = $wgSitename;
$wgLanguageCode = "en";
$wgProxyKey = "";
## Default skin: you can change the default skin. Use the internal symbolic
## names, ie 'standard', 'nostalgia', 'cologneblue', 'monobook':
$wgDefaultSkin = 'monobook';
## For attaching licensing metadata to pages, and displaying an
## appropriate copyright notice / icon. GNU Free Documentation
## License and Creative Commons licenses are supported so far.
$wgEnableCreativeCommonsRdf = true;
$wgRightsPage = ""; # Set to the title of a wiki page that describes your license/copyright
$wgRightsUrl = "http://www.gnu.org/copyleft/fdl.html";
$wgRightsText = "GNU Free Documentation License 1.2";
$wgRightsIcon = "${wgScriptPath}/skins/common/images/gnu-fdl.png";
# $wgRightsCode = "gfdl"; # Not yet used
$wgDiff3 = "/usr/bin/diff3";
# When you make changes to this configuration file, this will make
# sure that cached pages are cleared.
$configdate = gmdate( 'YmdHis', @filemtime( __FILE__ ) );
$wgCacheEpoch = max( $wgCacheEpoch, $configdate );
	
$wgLogo="/images/b/bc/axefx_square_logo.gif";
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['*']['createaccount'] = false;
$wgFileExtensions+=array( 'png', 'gif', 'jpg', 'jpeg', 'ppt', 'pdf', 'doc', 'psd', 'mp3','xls', 'zip','swf', 'doc', 'odt', 'odc', 'odp', 'odg', 'mpp');
$wgUploadSizeWarning=2097152;
$wgNamespacesWithSubpages[NS_MAIN] = true;
require_once($IP.'/extensions/InputBox/InputBox.php');
require_once("extensions/videoflash.php");
require_once("extensions/Randominclude.php");
$wgRandomInclude['pattern'] = '----';
$wgShowExceptionDetails = true;
$wgGroupPermissions['*']['edit'] = false; 
$wgRestrictDisplayTitle = false;
$wgDefaultUserOptions ['editsection'] = false;
$wgDisableAnonTalk = false;
$wgExternalLinkTarget = '_blank';
$wgGroupPermissions['sysop']['userrights'] = true;

83.86.193.229 08:43, 4 January 2012 (UTC)

P.S. Never mind the missing line breaks in the text above. 83.86.193.229 08:44, 4 January 2012 (UTC)

I have no idea why that doesn't work. It definitly should. Are you sure you're editing the correct LocalSettings.php file and all that? Bawolff 13:06, 4 January 2012 (UTC)

And that is the clue!

I was editing the LocalSettings in the root, where I should have been editing one in a subfolder.

My bad ....

Thanks a lot. Working now. 83.86.193.229 07:47, 6 January 2012 (UTC)

Short URL causes base URL to redirect to wiki main page

Wiki URL: http://shadestudios.elementfx.com/wiki MediaWiki Version: 1.18.0 PHP Version: 5.3.8 (litespeed) MySQL Version: 5.1.56

I just got the Short URL working, and it works fine. However, in my public_html folder, I have index.php set to redirect to my forum portal. When I enabled Short URLs, it started redirecting to my main page, even though it should be to my forum portal. Do I need a .htaccess just for the wiki or something? Hoodedwarbler12 (talk) 16:48, 31 December 2011 (UTC)

Assuming you followed this manual: Manual:Short URL/wiki/Page title -- no root access, yes a small change to .htaccess is needed. Or rather, undoing something you did that was in the manual:

Replace

RewriteEngine On
RewriteRule ^/?wiki(/.*)?$ /w/index.php [PT,L,QSA]
RewriteRule ^/*$ /w/index.php [L,QSA]

with:

RewriteEngine On
RewriteRule ^/?wiki(/.*)?$ /w/index.php [PT,L,QSA]

So, remove the last line that redirects the root directory to MediaWiki (RewriteRule ^/*$ /w/index.php [L,QSA]). Krinkle 16:58, 1 January 2012 (UTC)

Database error "1114: The table 'objectcache' is full' ..."

Hello.

I am using the newest version of mediawiki, started using it about 2 months ago. Setting up was easy, I use the webspace I have been running my blog on (for 8 years) without problems. The Wiki is small. There might be 30 pages or so, just text.

When I connected today it said:

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden) from within function "SqlBagOStuff::set". Database returned error "1114: The table 'objectcache' is full (xxx-wikimedia.mysql-gateway.de)".

I haven't changed anything in any admin menu for 2 months, everything ran smooth. Noone else has access to the wiki, I use it for my research ideas and projects. The last edit was about a week ago, a minor edit, adding a couple of lines.

What is the error message about? I googled it, but found this to be connected to different problems.

Thank you so much for your help. Happy new year!

Torvon 108.7.147.51 (talk) 23:47, 31 December 2011 (UTC)