Hi,
I'm running mediawiki 1.4beta6. Pageloads are taking up to 10 seconds when I use Firefox, but are much quicker when I use IE. Has anyone had this problem before, and is there a simple fix?
I'm running behind Apache2, and my rewrite rules look like:
RewriteCond %{REQUEST_URI} !index.php RewriteCond %{QUERY_STRING} ^title= RewriteRule ^.*$ /index.php [L,QSA]
RewriteCond %{REQUEST_URI} !^/(stylesheets|images|skins)/ RewriteCond %{REQUEST_URI} !^/(redirect|texvc|index).php RewriteCond %{REQUEST_URI} !^/error/(40(1|3|4)|500).html RewriteCond %{REQUEST_URI} !^/favicon.ico RewriteCond %{REQUEST_URI} !^/robots.txt
# Rewrite http://wiki.domain.tld/article properly, this is the main rule RewriteRule ^/(.*)$ /index.php/$1 [L,QSA]
When I look at the Apache logs, the reason seems pretty obvious. The requests from Firefox are duplicated up to 20 times each. I captured two request sets for the main page, one made by firefox and the other by IE. There are 65 GET requests in the Firefox session, and only 7 in the IE log. I've attached the logs.
Anyone know why this could be?
Thanks,
Nic Suzor
Nic Suzor wrote: [snip]
When I look at the Apache logs, the reason seems pretty obvious. The requests from Firefox are duplicated up to 20 times each. I captured two request sets for the main page, one made by firefox and the other by IE. There are 65 GET requests in the Firefox session, and only 7 in the IE log. I've attached the logs.
Anyone know why this could be?
Make sure $wgScript is set to "/index.php". Search list archives for previous discussions of Internet Explorer security flaws that require us to be strict about incoming URLs for raw mode.
-- brion vibber (brion @ pobox.com)
Brion Vibber [Sun Feb 20, 2005 at 10:20:57PM -0800]:
Make sure $wgScript is set to "/index.php". Search list archives for previous discussions of Internet Explorer security flaws that require us to be strict about incoming URLs for raw mode.
Thanks for your quick response Brion. That fixed the speed problem up. I remember that I had set $wgScript to "/" when I was trying to figure out the rewrite rules. I changed it because I couldn't figure out why some links would display as http://siteroot/link while others would display as http://siteroot/index.phplink. For example, the discussion link on the main page correctly reads http://wikijuris.net/Talk:Main_Page, but the edit link shows http://wikijuris.net/index.phpMain_Page?title=Main_Page&action=edit
It seems that all the links with parameters don't get built properly. Eg Special:Watchlist but index.phpSpecial:Contributions?title=...
The changes I made to the path variables are:
#---Rewrite rule changes $wgScriptPath = ""; $wgScript = "/index.php"; $wgRedirectScript = '/redirect.php'; $wgUploadPath = '/images'; $wgArticlePath = "/$1"; #--
I imagine this is related to the problem I had with the rewrite rules. When I finally got my rewrite rules working properly, I had to add a special case for URLs of the form http://domain/?title=...
As far as I can tell, none of the links should prepend $wgScript.
Sorry, I've had a look through the archives, but can't find anyone that has had the same problem. The only suggestion I could find was to set $wgUsePathInfo = false;, but that didn't work.
Thanks,
Nic Suzor
Nic Suzor wrote:
I changed it because I couldn't figure out why some links would display as http://siteroot/link while others would display as http://siteroot/index.phplink. For example, the discussion link on the main page correctly reads http://wikijuris.net/Talk:Main_Page, but the edit link shows http://wikijuris.net/index.phpMain_Page?title=Main_Page&action=edit
Well that's certainly unusual...
#---Rewrite rule changes $wgScriptPath = ""; $wgScript = "/index.php"; $wgRedirectScript = '/redirect.php'; $wgUploadPath = '/images'; $wgArticlePath = "/$1"; #--
I copied these exact settings into my 1.4 test wiki, and I'm getting normal-looking links (eg /index.php?title=Main_Page&action=edit)
Have you made any changes to Title::getLocalURL() in Title.php? Try adding in some debug statements or something to make sure the variables are what they look like they should be. I really can't see how you could be getting this output unless that function had been altered.
-- brion vibber (brion @ pobox.com)
Brion Vibber [Mon Feb 21, 2005 at 12:17:50AM -0800]:
Have you made any changes to Title::getLocalURL() in Title.php? Try adding in some debug statements or something to make sure the variables are what they look like they should be. I really can't see how you could be getting this output unless that function had been altered.
Thanks. I upgraded to 1.4RC1, which would've overwritten any changes I'd made to getLocalURL(), and everything works fine, and fast.
I'd forgotten that I'd made a change to getLocalURL() when I was trying to get my rewrite rules to work. I had so many problems getting them to work that I had tried (unsucessfully, obviously) to force the correct syntax when I had $wgScript = ''.
Thanks for all your help.
Nic Suzor
All,
The following error is generated by the following sequence of code:
Error: Fatal error: Call to a member function on a non-object in /var/www/html/internal/wiki/includes/Title.php on line 1196
Begin Code: (Note: $_SERVER["REMOTE_USER"] = jcstraff) (in modified User.php) $name = $_SERVER["REMOTE_USER"]; $u = User::newFromName( $name ); (elsewhere in User.php) function newFromName( $name ) { $u = new User(); $t = Title::newFromText( $name ); ... (in Title.php) /* static */ function &newFromText( $text, $defaultNamespace = 0 ) { $fname = 'Title::newFromText'; ... /** * Normally, all wiki links are forced to have * an initial capital letter so [[foo]] and [[Foo]] * point to the same place. * * Don't force it for interwikis, since the other * site might be case-sensitive. */ if( $wgCapitalLinks && $this->mInterwiki == '') { $t = $wgContLang->ucfirst( $r ); # # # # # # <== LINE 1196 } else { $t = $r; } :End Code
There are lots of "$r"s throughout Title.php, but they all seem to be used temporarily and are set explicitly before each use... I cannot see where the "$r" on line 1196 originates. When I comment out this Title.php block, the code works fine (with other issues that will be discussed in a later email.) Did I find a bug or am I doing something wrong/unnatural/evil/etc.?
- John
On Mon, 21 Feb 2005 13:15:04 -0500, John Straffin john.straffin@duke.edu wrote (in part):
The following error is generated by the following sequence of code:
What version of the code are you working with?
-Rich Holton
Richard Holton wrote:
On Mon, 21 Feb 2005 13:15:04 -0500, John Straffin john.straffin@duke.edu wrote (in part):
The following error is generated by the following sequence of code:
What version of the code are you working with?
Ooop! Sorry for omitting that little detail... this is 1.4beta6 (soon to be 1.4rc1).
- John
On Mon, 21 Feb 2005 13:15:04 -0500, John Straffin john.straffin@duke.edu wrote:
Error: Fatal error: Call to a member function on a non-object in /var/www/html/internal/wiki/includes/Title.php on line 1196
[...]
$t = $wgContLang->ucfirst( $r ); # # # # # # <== LINE 1196
From the error message, it's not the $r that's the problem, but the
$wgContLang - the code is saying "perform member function ucfirst of object $wgContLang", but it doesn't know what $wgContLang is.
Are you perhaps performing this code sequence so far up that the global hasn't been defined yet? Double-guessing what you might be doing, I figure you just might be - $wgContLang is created in Setup.php, line 277; this appears to be *after* the user object is created, which looks like being what you're trying to modify.
Without knowing more about your code, or indeed the exact way things work, I can't suggest anything very specific, but I guess you'll have to try a slightly different approach.
John Straffin wrote:
Error: Fatal error: Call to a member function on a non-object in /var/www/html/internal/wiki/includes/Title.php on line 1196
Begin Code: (Note: $_SERVER["REMOTE_USER"] = jcstraff) (in modified User.php) $name = $_SERVER["REMOTE_USER"]; $u = User::newFromName( $name );
[snip]
$t = $wgContLang->ucfirst( $r ); # # # # # # <== LINE 1196
[snip]
Is this mysterious contextless modified User.php code being run before $wgLang and $wgContLang are initialized?
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
John Straffin wrote:
Error: Fatal error: Call to a member function on a non-object in /var/www/html/internal/wiki/includes/Title.php on line 1196
Begin Code: (Note: $_SERVER["REMOTE_USER"] = jcstraff) (in modified User.php) $name = $_SERVER["REMOTE_USER"]; $u = User::newFromName( $name );
[snip]
$t = $wgContLang->ucfirst( $r ); # # # # # # <== LINE 1196[snip]
Is this mysterious contextless modified User.php code being run before $wgLang and $wgContLang are initialized?
Sorry (re: "contextless"). This is still me trying to get the user identified by $_SERVER["REMOTE_USER"] auto-logged in. The code previously posted by David Cameron on 18 Feb works to do this providing that I do the following:
(1) Comment out the five Title.php lines that relate to line 1196 (2) Comment out the Cookie testing code in User::loadFromSession (3) Comment out the UserUpdate() and $wgDeferredUpdateList line from David's code (apparently legacy code from 1.3.x, I'm using 1.4.x)
With those three changes, MediaWiki successfully logs me in automatically. Ideally, however, I'd like to not have to comment out the Title.php lines and the cookie code, but I'm kinda stuck. It appears that (as you suppose above) the User.php code is being run before $wgLang and $wgContLang are initialized. Is there any way I can juggle this around so as to have these objects initialized (perhaps initializing them in my code block?)
**OR**, conversely, can anyone give a quick "howto" on AuthPlugin.php? Now that I've peeked at it, it appears to be what I should really be using...
- John
On 20 Feb 2005, at 22:20, Brion Vibber wrote:
Make sure $wgScript is set to "/index.php".
When I do that, I get ugly links. When I don't do that, I get pretty links (no index.php) but things are slow.
:::: You know you have reached perfection of design not when you have nothing more to add, but when you have nothing more to take away. -- Antoine de'Exupery :::: Jan Steinman http://www.Bytesmiths.com
Jan Steinman wrote:
On 20 Feb 2005, at 22:20, Brion Vibber wrote:
Make sure $wgScript is set to "/index.php".
When I do that, I get ugly links. When I don't do that, I get pretty links (no index.php) but things are slow.
Regular article links always use $wgArticlePath, which has a replacement parameter in it (the $1). These can be made "pretty" in various ways.
Links with additional data parameters use $wgScript directly and tack on the parameters one by one. These are always going to be "ugly" in one way or another.
-- brion vibber (brion @ pobox.com)
mediawiki-l@lists.wikimedia.org