MediaWiki

Topic on Project:Support desk

< Project:Support desk

[RESOLVED] Some Special: pages won't display in version 1.22.2 Apache Win 7

11 comments • 20:31, 18 January 2017 7 years ago
11
Canuckdev (talkcontribs)

MediaWiki 1.22.2 / PHP 5.3.10 (apache2handler) / MySQL 5.5.20

Some Special:* pages won't display in version 1.22.2, especially Special:SpecialPages. The only sign of a problem is the following message in Apache error log:

[Wed Feb 12 13:08:59.451552 2014] [core:error] [pid 4052:tid 764] (20024)The given path is misformatted or contained invalid characters: [client 192.168.1.104:61178] AH00127: Cannot map GET /wiki/Special:SpecialPages HTTP/1.1 to file

Some Special: pages seem OK such as Special:ListUsers or Special:Version, others just won't display at all.

18:25, 12 February 2014 10 years ago
AKlapper (WMF) (talkcontribs)
22:55, 12 February 2014 10 years ago
Canuckdev (talkcontribs)

OK. Turning on php errors gave me nothing, so I enabled a debug log file which gave me this:

Extended content 
Start request GET /wiki/Special:SpecialPages
HTTP HEADERS:
ACCEPT: image/gif, image/jpeg, image/pjpeg, application/x-ms-application, application/vnd.ms-xpsdocument, application/xaml+xml, application/x-ms-xbap, application/x-shockwave-flash, application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword, */*
ACCEPT-LANGUAGE: en-ca
USER-AGENT: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; Trident/5.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.30729; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E)
ACCEPT-ENCODING: gzip, deflate
HOST: win04
CONNECTION: Keep-Alive
COOKIE: <content removed>
CACHES: EmptyBagOStuff[main] SqlBagOStuff[message] SqlBagOStuff[parser]
[cookie] session_set_cookie_params: "0", "/", "", "", "1"
LocalisationCache: using store LCStore_DB
Fully initialised
User: cache miss for user 4
Connected to database 0 at localhost
User: loading options for user 4 from database.
User: logged in from session
User: loading options for user 4 from override cache.
Connected to database 0 at localhost
MessageCache::load: Loading en... got from global cache
Unstubbing $wgParser on call of $wgParser::firstCallInit from MessageCache::getParser
Parser: using preprocessor: Preprocessor_DOM
Unstubbing $wgLang on call of $wgLang::_unstub from ParserOptions::__construct
Unstubbing $wgAuth on call of $wgAuth::allowPasswordChange from SpecialPasswordReset::canChangePassword

I don't really know what I'm looking at, is there anything there?

Edited 19:52, 14 February 2014 10 years ago
Ciencia Al Poder (talkcontribs)
10:40, 13 February 2014 10 years ago
Canuckdev (talkcontribs)

Thanks for your reply. I agree it may be a Windows problem, but I had already reviewed the page you suggested and ruled it out for the following reasons:

  1. The problem occurs even when not using short URLs. The same debug output is produced.
  2. Only some Special: pages are not working (see my first post).
  3. Problem does not occur with version 1.21.1.
  4. Problem does not occur with the same wiki on Vista.
  5. Problem still occurs when the mediawiki installation is moved to a FAT32 partition.

Here is sample debug output from Vista which is different from the Win 7 debug output I posted above:

Extended content 
Start request GET /wiki/Special:SpecialPages
HTTP HEADERS:
ACCEPT: text/html, application/xhtml+xml, */*
REFERER: http://localhost/wiki/jjpWiki_Home_Page
ACCEPT-LANGUAGE: en-ca
USER-AGENT: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/5.0)
ACCEPT-ENCODING: gzip, deflate
HOST: localhost
CONNECTION: Keep-Alive
COOKIE: <content removed>
CACHES: EmptyBagOStuff[main] SqlBagOStuff[message] SqlBagOStuff[parser]
[cookie] session_set_cookie_params: "0", "/", "", "", "1"
LocalisationCache: using store LCStore_DB
Fully initialised
User: cache miss for user 4
Connected to database 0 at localhost
Connected to database 0 at localhost
MessageCache::load: Loading en... got from global cache
User: loading options for user 4 from database.
User: logged in from session
User: loading options for user 4 from override cache.
Unstubbing $wgParser on call of $wgParser::firstCallInit from MessageCache::getParser
Parser: using preprocessor: Preprocessor_DOM
Unstubbing $wgLang on call of $wgLang::getMessageFromDB from ExtArrays::init
Unstubbing $wgAuth on call of $wgAuth::allowPasswordChange from SpecialPasswordReset::canChangePassword
Did not find alias for special page 'GetData'. Perhaps no aliases are defined for it? [Called from SpecialPageFactory::getLocalNameFor in C:\w4\jpwork2\web\mediawiki-1.22.2\includes\SpecialPageFactory.php at line 567]
Did not find alias for special page 'GetData'. Perhaps no aliases are defined for it? [Called from SpecialPageFactory::getLocalNameFor in C:\w4\jpwork2\web\mediawiki-1.22.2\includes\SpecialPageFactory.php at line 567]
DatabaseBase::query: Writes done: REPLACE INTO `mw_msg_resource` (mr_resource,mr_lang,mr_blob,mr_timestamp) VALUES ('user.options','en','{}','20140213162548')
OutputPage::sendCacheControl: private caching;  **
LoadBalancer::reuseConnection: this connection was not opened as a foreign connection
LoadBalancer::reuseConnection: this connection was not opened as a foreign connection
LoadBalancer::reuseConnection: this connection was not opened as a foreign connection
LoadBalancer::reuseConnection: this connection was not opened as a foreign connection
[jobqueue] SMW\UpdateJob Property:Has_type
Success, Time: 51 ms
Request ended normally
Edited 19:55, 14 February 2014 10 years ago
Ciencia Al Poder (talkcontribs)

Sadly, the original error Cannot map GET /wiki/Special:SpecialPages HTTP/1.1 to file is not a MediaWiki error. There are lots of people getting this error on WAMP (google:AH00127) and not only for MediaWiki, but for other PHP applications as well (wordpress, etc)

I haven't found a solution for this neither.

10:49, 14 February 2014 10 years ago
Canuckdev (talkcontribs)

I understand the original error is not a MediaWiki error, but it seems apparent from the debug log outputs above that this error is being caused by MediaWiki not completing the page generation. It appears to be crapping out at or after:

Unstubbing $wgAuth on call of $wgAuth::allowPasswordChange from SpecialPasswordReset::canChangePassword

because there are not debug log entries after that one for the failure condition.

Not seeing:

...
Request ended normally

In the debug log for the failure condition.

14:58, 14 February 2014 10 years ago
Ciencia Al Poder (talkcontribs)

This issue is reported at php.net bugs . On this report, it's caused when a require() is done on a ntfs junction. That might explain why there are some entries on the debug log, until PHP hits that bug and apache comes with this odd message.

Maybe upgrading WAMP or using a different version of WAMP may solve this issue.

19:04, 14 February 2014 10 years ago
Canuckdev (talkcontribs)

Thanks for your reply. That's very interesting, but I'm not sure it's the same problem for the following reasons:

  1. I'm not using an NTFS junction, or any special NTFS file/directory types in the MediaWiki installation.
  2. The problem still occurs even with the MediaWiki installation located on a FAT32 partition.
  3. The php errors shown in the php bug report are nowhere to be seen.

I've tried Apache 2.4.1, 2.4.4, and 2.4.7 with all having the same problem. If you still think it's worthwhile, I could try a different version of PHP.

19:47, 14 February 2014 10 years ago
Canuckdev (talkcontribs)

That's it! Thanks for all your most patient advice. Updated php to latest 5.3 branch and all is well again in my windows wiki world.

06:07, 15 February 2014 10 years ago
Ciencia Al Poder (talkcontribs)

Glad to see this fixed the issue! :)

11:42, 15 February 2014 10 years ago
Retrieved from "https://www.mediawiki.org/wiki/Topic:Rp3ch884qkelkkgh"