Project:Support desk/Sections/System

__NEWSECTIONLINK__

= MediaWiki System Support =

404 for non-logged in users

 * MediaWiki	1.15.1 (r59167)
 * PHP	5.2.10 (cgi-fcgi)
 * MySQL	5.0.51a-community-nt
 * URL: (private network)
 * Win2k/IIS5 (using php5isapi.dll)

Many links result in a 404 error, if the user tries to navigate as a non-logged in user. As soon as they log in, everything is then fine...

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.

(Resolved) Error 404 Page Not Found - MediaWiki Install on IIS 6.0, PHP, Windows 2003, FastCGI
I had some trouble resolving the error 404 Page Not Found Resolution IIS virtual directory configuration: On Home Directory tab, click on Configuration and add Application Extension Mapping for php. The entry must be ".php" and "C:\WINDOWS\system32\inetsrv\fcgiext.dll" for FastCGI, otherwise use c:\php\php5isapi.dll. My version of fcgiext.ini had incorrect [Types] section... Should be (verify php path on your install) [Types] php=PHP

[PHP] ExePath=C:\PHP\php-cgi.exe InstanceMaxRequests=10000 ActivityTimeout=600 RequestTimeout=600 EnvironmentVars=PHP_FCGI_MAX_REQUESTS:10000,PHPRC:C:\PHP\

Also, http://blog.tjitjing.com/index.php/2006/05/php5-with-iis6-on-windows-server-2003.html was very helpful.

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


 * You're repeatedly overwriting your variable:

$wgGroupPermissions = array( 'sysop' ); ... $wgGroupPermissions = array( 'user' ); ... $wgGroupPermissions = array( '*' );
 * Max Semenik 07:52, 21 November 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?


 * HELP! Anyone?

Something similar to early WikiWords?
Hey, I'm setting up a wiki right now and i need to know if it is possible to create variables/functions for strings in wiki articles and pages?
 * MediaWiki: 1.14.0

e.g. wikipage Some text on the page And even more text. So now i know for sure that ppl at my company filling the wiki will miss to add links to other pages from time to time. I just want to make sure that the links to other pages that exist will be created. So i need to know if it's possible (maybe using MagicWords) if i set the string text as a variable for the function text. I have no idea how to do that and if it is even possible :).

TOC/Numbered List Formatting Bug

 * MediaWiki version: 1.12.0 and 1.15.1
 * PHP version: 5.1.6 (apache2handler)
 * MySQL version: 5.0.27
 * URL: http://wiki.electronicvisions.com/index.php/Formatbug

There is a formatting bug when a left aligned TOC has a numbered list to its right. The indentations don't appear to occur and the numbers themselves are located within the TOC box.

I tried upgrading to 1.15.1 to see if it had been fixed but it looked the same. (I then went back to 1.12.0 because I was having trouble convincing 1.15.1 to allow page edits, but that's likely my issue)

Here's the simple code that my example page uses to test it:

Special notice text

Sample Section Heading

 * First item in an indented, numbered list
 * Second item in an indented, numbered list
 * Third item in an indented, numbered list

Another Sample Heading
Blah, blah, blah

How to show search hits but hide page content?

 * MediaWiki version:  	1.15.1
 * PHP version: 2.5.6
 * MySQL version: 5.0.67
 * URL:

Is there any way to display search hits to a page but hide the page content from unregistered users?

Bruce—130.76.32.181 23:23, 20 November 2009 (UTC)

TOC bookmark URLs

 * MediaWiki version: 1.15.1
 * PHP version: 5.2.6-3ubuntu4.2 (apache2handler)
 * MySQL version: 5.0.75-0ubuntu10.2
 * URL: http://www.spacetimeresearch.com/wiki/

We have installed MediaWiki in a sub folder of our website /wiki. LocalSettings.php has been modified to ensure that /wiki is setup as the $wgScriptPath. All the links to different wiki entries etc are working as expected, however Table of Contents URLs are linking to /index.php#bookmarkname rather than /wikki/index.php?title=Page_Name.

Is there some setting that needs to be set to ensure that this is working correctly?

Thanks

—202.124.118.98 01:39, 26 November 2009 (UTC)

Problem Loading Page

 * MediaWiki version: 1.15.1
 * PHP version: 5.2.9
 * MySQL version: 5.0.77
 * URL: http://www.familiesteinborn.de/wiki/index.php

When I click on "impressum", "Über SteinbornWiki" and "Datenschutz" Links at the bottom of the Mainpage and on all the other pages on the left menu the requested pages will shortly appear and afterwards a 404 error "the page could not be found" appears! Why? And how could this be solved?

—Max Semenik 11:26, 3 December 2009 (UTC)

Zero-length results given back for some pages only when returned with gzip content encoding.

 * MediaWiki version: 1.15.0
 * PHP version: 5.2.10-2ubuntu6.3
 * MySQL version: 5.1.37-1ubuntu5
 * URL: intranet

Certain pages are returning zero length only when returned with content encoding.

For example, the following wget produces expected results. See "Content-Length" in the response. Everything is fine. $ wget -O history.html http://192.168.1.90/mediawiki/index.php?title=Main_Page\&action=history -d

---request begin--- GET /mediawiki/index.php?title=Main_Page&action=history HTTP/1.0 User-Agent: Wget/1.11.4 Accept: */* Host: 192.168.1.90 Connection: Keep-Alive ---request end---

---response begin--- HTTP/1.1 200 OK Date: Thu, 03 Dec 2009 19:04:37 GMT Server: Apache/2.2.12 (Ubuntu) X-Powered-By: PHP/5.2.10-2ubuntu6.3 Content-language: en Vary: Accept-Encoding,Cookie X-Vary-Options: Accept-Encoding;list-contains=gzip,Cookie;string-contains=wikidbToken;string-contains=wikidbLoggedOut;string-contains=wikidb_session Expires: Thu, 01 Jan 1970 00:00:00 GMT Cache-Control: private, must-revalidate, max-age=0 Last-Modified: Thu, 03 Dec 2009 18:45:12 GMT Content-Length: 14152 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html; charset=UTF-8 ---response end---

Now, try that again with 'Accept-Encoding: gzip', and the result is zero bytes! See Content-Length below.

$ wget -O history-90.html.gz http://192.168.1.90/mediawiki/index.php?title=Main_Page\&action=history -d --header='Accept-Encoding: gzip'

---request begin--- GET /mediawiki/index.php?title=Main_Page&action=history HTTP/1.0 User-Agent: Wget/1.11.4 Accept: */* Host: 192.168.1.90 Connection: Keep-Alive Accept-Encoding: gzip ---request end---

---response begin--- HTTP/1.1 200 OK Date: Thu, 03 Dec 2009 19:06:44 GMT Server: Apache/2.2.12 (Ubuntu) X-Powered-By: PHP/5.2.10-2ubuntu6.3 Content-language: en Vary: Accept-Encoding,Cookie X-Vary-Options: Accept-Encoding;list-contains=gzip,Cookie;string-contains=wikidbToken;string-contains=wikidbLoggedOut;string-contains=wikidb_session Expires: Thu, 01 Jan 1970 00:00:00 GMT Cache-Control: private, must-revalidate, max-age=0 Last-Modified: Thu, 03 Dec 2009 18:45:12 GMT Content-Encoding: gzip Content-Length: 0 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html; charset=UTF-8 ---response end---

This is not a wget-specific problem. Same results with Opera, Safari, and curl. This happens to some pages and not others. All 'history' and 'edit' pages have this behaviour. Some "Special:" pages have it, others work fine.

I have also set up a brand new server with ONLY MediaWiki (and pre-req's, of course), and still this behaviour persists for me.

Unfortunately, it means I cannot use MediaWiki on this server, because I can't go around and tell all my regular web clients to disable "Accept-Encoding" headers.

Thanks so much for any help you can provide!

—Jc000 19:13, 3 December 2009 (UTC)

(Resolved) Search results displaying raw HTML code?

 * MediaWiki version: 1.15.1
 * PHP version: 5.2.11
 * MySQL version: 5.0.81
 * URL: (Disclosed)

I have decided to convert all of my HTML pages for my internal work website into a Wiki page. I have added the $wgRawHtml = true; in the LocalSettings.php file so it would be an easy transition.

What I ran into when searching, was that when it displays a result, it does show the correct page, but instead of a clean 'description', it shows the raw HTML from that page, or table, containing the string that I searched for.

It seems like the search function isn't wanting to use the raw HTML as easily as the pages. Is there a fix for that?

Here's a little screen shot of what I'm talking about since I can't provide the URL since it's in the intranet. Click here

--24.154.0.21 16:39, 8 December 2009 (UTC) Cory


 * MediaWiki version: latest from November 2009
 * PHP version:
 * MySQL version:
 * URL:

I keep on wondering on one tiny thing I'm getting totally confused with: if I've successfully installed the wikimedia system on my server and if I've already written a few articles - is there any option/menu to see some kind of "table of contents" of my wiki? some kind of article-overview about stuff that has already been written? Some kind of summary where readers can easily pick out their favoured articles?

I'm aware of the fact that there are some extension flying around that generate article lists but isn't there any already built in system within the mediawiki basic installation - or is it just me who hasn't found the option yet, even if it is right before my eyes...

So, I hope you can help me a bit, Greetings from Austria,

Stefan (novalis_@gmx.net)

—88.117.121.169 20:16, 9 December 2009 (UTC)