Project:Support desk/Sections/System

__NEWSECTIONLINK__

= MediaWiki System Support =

Resolved: 404 when using short url

 * MediaWiki: 1.11.0
 * PHP: 5.2.5 (cgi-fcgi)
 * MySQL: 5.0.67.d7-ourdelta-log
 * URL: www.jainkosh.org

Hello, I have been trying to use short url for my wiki by following instructions at http://www.mediawiki.org/wiki/Manual:Short_URL/wiki/Page_title_--_no_root_access but could not achieve the results. My server is Apache and my wiki is saved at htdocs\Mediawiki. I have tried saving the .htaccess file in htdocs\Mediawiki, htdocs\, htdocs\sample_html, htdocs\Mediawiki\sample_html, but it didn't work. Whenever I tried to go to www.jainkosh.org/wiki/Main_Page, it throws error 404, page not found. This is what I have put in my .htaccess file:

RewriteEngine On RewriteRule ^wiki/(.*)$ /Mediawiki/index.php?title=$1 [PT,L,QSA] RewriteRule ^wiki/*$ /Mediawiki/index.php [L,QSA] RewriteRule ^/*$ /Mediawiki/index.php [L,QSA]

Can you please help me in getting this working?

Thanks a lot, Vikas

I tried the same settings on Godaddy.com server and it worked fine there. Somehow on my localhost it didn't work and was giving 404. Works great on the godaddy server.

Can I link files directly off my server to our wiki page, or must they be uploaded?

 * MediaWiki version:
 * PHP version:
 * MySQL version:
 * URL:

Is it possible for me to link files from my server to MediaWiki without uploading them. We have an extensive database of projects we would like to incorporate into the our wiki site but do not want to duplicate all those files by uploading them.

Permissions not working correctly

 * MediaWiki version: 1.15.1
 * PHP version: 5.2.9-1 (cgi-fcgi)
 * MySQL version: 5.0.24-community-nt
 * URL: Behind Firewall

I am having issues with users (including sysops) not beign able to edit, upload files, etc, when the $wgGroupPermissions['*'][value] = false. For instance, I want anonymous users to NOT be able to edit pages, but when I change the ['edit'] to FALSE, no one can edit pages. I have looked in the admin guides and forums and have not been able to find an answer as to why this is happening. Below is what I have for permissions set in my LocalSettings.php

$wgAddGroups['sysop'] = array( 'bot' ); $wgRemoveGroups['sysop'] = array( 'bot'); $wgGroupPermissions['sysop']['userrights'] = true; $wgGroupPermissions = array( 'sysop' ); $wgGroupPermissions['sysop']['passwordresetself'] = true; $wgGroupPermissions['sysop']['passwordreset'] = true; $wgGroupPermissions['sysop']['move'] = true; $wgGroupPermissions['sysop']['read'] = true; $wgGroupPermissions['sysop']['edit'] = true; $wgGroupPermissions['sysop']['viewedittab'] = true; $wgGroupPermissions['sysop']['createpage'] = true; $wgGroupPermissions['sysop']['createtalk'] = true; $wgGroupPermissions['sysop']['userrights'] = true; $wgGroupPermissions['sysop']['noratelimit'] = true; $wgGroupPermissions['sysop']['block'] = true; $wgGroupPermissions['sysop']['createaccount'] = true; $wgGroupPermissions['sysop']['delete'] = true; $wgGroupPermissions['sysop']['bigdelete'] = true; $wgGroupPermissions['sysop']['deletedhistory'] = true; $wgGroupPermissions['sysop']['undelete'] = true; $wgGroupPermissions['sysop']['editinterface'] = true; $wgGroupPermissions['sysop']['editusercssjs'] = true; $wgGroupPermissions['sysop']['import'] = true; $wgGroupPermissions['sysop']['importupload'] = true; $wgGroupPermissions['sysop']['move'] = true; $wgGroupPermissions['sysop']['patrol'] = true; $wgGroupPermissions['sysop']['autopatrol'] = true; $wgGroupPermissions['sysop']['protect'] = true; $wgGroupPermissions['sysop']['proxyunbannable'] = true; $wgGroupPermissions['sysop']['rollback'] = true; $wgGroupPermissions['sysop']['trackback'] = true; $wgGroupPermissions['sysop']['upload'] = true; $wgGroupPermissions['sysop']['reupload'] = true; $wgGroupPermissions['sysop']['reupload-shared'] = true; $wgGroupPermissions['sysop']['unwatchedpages'] = true; $wgGroupPermissions['sysop']['autoconfirmed'] = true; $wgGroupPermissions['sysop']['upload_by_url'] = true; $wgGroupPermissions['sysop']['ipblock-exempt'] = true; $wgGroupPermissions['sysop']['blockemail'] = true; $wgGroupPermissions['sysop']['markbotedits'] = true; $wgGroupPermissions['sysop']['suppressredirect'] = true; $wgGroupPermissions['sysop']['apihighlimits'] = true; $wgGroupPermissions['sysop']['browsearchive'] = true; $wgGroupPermissions['sysop']['deleterevision'] = true; $wgGroupPermissions = array( 'user' ); $wgGroupPermissions['user']['read'] = true; $wgGroupPermissions['user']['createpage'] = true; $wgGroupPermissions['user']['createtalk'] = true; $wgGroupPermissions['user']['edit'] = false; $wgGroupPermissions['user']['viewedittab'] = true; $wgGroupPermissions['user']['upload'] = true; $wgGroupPermissions = array( '*' ); $wgGroupPermissions['*']['createaccount'] = true; $wgGroupPermissions['*']['read'] = true; $wgGroupPermissions['*']['edit'] = true; $wgGroupPermissions['*']['createpage'] = true; $wgGroupPermissions['*']['createtalk'] = true; $wgGroupPermissions['*']['upload'] = true; $wgGroupPermissions['*']['viewedittab'] = true;

—Rob Presley

(RESOLVED) Page look-and-feel (and login status) differs by page & user after upgrade from 1.12 to 1.15.1
We recently upgraded our intranet wiki from 1.12 to 1.15.1, to get access to collapsible tables (with a little customization). However, the look-and-feel of pages varies. Most pages for me look "better" ie. what I presume is the latest theme. Whereas, some pages look decidedly less artful - and they also display the "Log In" link - whereas I am shown as logged in on the "better" pages. A page can look different depending on who the logged-in person is, but the view seems consistent for a given user & page. Unsure whether the correct look-and-feel is only for pages I have recently modified, but I could mount an argument. Browsers used are Firefox & IE (later versions). I know nothing about the use of skins. Installed extensions: ParserFunctions (version 1.2.0); SyntaxHighlight Any help would be greatly appreciated. —203.8.33.195 08:12, 7 September 2009 (UTC)
 * MediaWiki version: 1.15.1
 * PHP version: 5.2.3 (isapi)
 * MySQL version: 5.0.24-community-nt
 * URL: (intranet wiki)

Problem was apparently due to the browser's cookie handling. Logging out, then logging in again, seems to have fixed the problem. —203.8.33.195 00:23, 16 September 2009 (UTC)

Load Issues on server

 * MediaWiki version: 1.13.0
 * PHP version: 5.2.8 (cgi-fcgi)
 * MySQL version: 5.1.30
 * URL: http://poketeca.com

My hosting says that my installation is causing load issues on the server. They recommend me asking here for assistance in improving the performance of my wiki. The hosting tells me abaout Caching but, what more can I do?

—87.221.133.156 20:02, 11 September 2009 (UTC)


 * MediaWiki version:
 * PHP version:
 * MySQL version:
 * URL:

Hi!

I find how you can move a text and create redirects but I want an automatic redirect. How do I do so that everytime someone searches for "Cbetting" they will get to "Cbet" ?

—83.233.131.131 19:56, 17 September 2009 (UTC)


 * MediaWiki version: 1.15.1
 * PHP version: 5.3.0
 * MySQL version: 5.1.37
 * URL: stopphei.zapto.org/wiki

How can I only use "wiki/(etc)" instead of "wiki/index.php/(etc)" when someone use my wiki?

—82.116.83.55 15:57, 24 September 2009 (UTC)

a page doesn't exist

 * MediaWiki version: 1.15.1
 * PHP version: 5.3
 * MySQL version: 5.1
 * URL: intranet

I'm working for a EDF, and we will install a wiki. Our server is a ZendServer, and php was exectuted in CGI mode. We just install it, and when I click on Help so this URL : http://my-adresse.fr/wiki/index.php/Help:Accueil I have and error message because the page doesn't exist.

But with this URL : http://my-adresse.fr/wiki/index.php/Category:Toto It works...

So I don't know why. Do you have a answer??

—Olivier.riche 15:17, 28 September 2009 (UTC)

Signatures don't work properly on 1.15.1
Also asked here: http://en.wikipedia.org/wiki/Wikipedia_talk:Signatures#Invalid_links_in_signatures_-_MediaWiki_1.15.1.

I just realized that ~ is creating links to SomeUserName and not User:SomeUserName. Is this a known MediaWiki bug? Is there a fix and/or workaround?