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.

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

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)


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

MediaWiki 1.15.1 PHP 5.2.10 (apache2handler) MySQL 5.0.51a-3ubuntu5.4 Os - Ubuntu 9.10 (on VMWare workstation).

My problem is - I can not save changes in "my preferences". When I enter some changes (real name for example) and then click "save", page reloads and all changes are discarded. No changes appear in mysql database - I checked it. I don't receive any error messages (I tried to turn error_reporting (E_ALL)). I tried from various computers and browsers - the same problem, so I suppose It is not client-side issue.

All other functions works fine. I can create users, create and edit pages and so. Only edit user preferences doesn't work.

—92.243.174.132 13:55, 15 December 2009 (UTC)

action=raw gives an error

 * MediaWiki version: 1.13.0
 * PHP version: 5.2.9
 * MySQL version: 5.0.77
 * URL: http://www.mansonwiki.com/

Hi, I've recently switched from using an addon domain (siteground, cpanel) to using a parked domain for my wiki. By using the right mod_rewrite rules I managed to let everything work exactly as before, simply by rewriting all traffic incoming to the domain to the proper subfolder. In that folder there is a wiki install (in /w/, as usual) and of course the mod_rewrite rules that come with it, including for short urls.

As stated, everything works as before, with one exception: action=raw gives an error, saying it can only be accessed through the primary script entry point. This means some of my custom css doesn't load. I don't get what I've done wrong, how can a mod_rewrite break something internal like a parameter to index.php? The exact url that's requested: http://www.mansonwiki.com/w/index.php?title=MediaWiki:Common.css&usemsgcache=yes&action=raw&ctype=text/css&smaxage=18000 (and 3 others)

—Litso 11:06, 18 December 2009 (UTC)
 * It's a known issue, and looks like it has been fixed for some time. If upgrade to 1.15.1 doesn't help, please reopen that bug. Max Semenik 11:21, 18 December 2009 (UTC)


 * Ah, bummer, I'll have to try and upgrade. Thanks :) Litso 11:28, 18 December 2009 (UTC)