Greetings Wiki Admins!
Thanks for letting me join your list, I hope it's OK to ask support-style questions here.
I recently installed a MediaWiki 1.3.9 instance on FreeBSD 4.10, Apache 1.3.33, and mySQL 4.0.15. I wanted the stable release (which is why I'm < 1.4) but the secure one (which is why I went > 1.3.7). The pages are not loading quite right: that is to say, the page source loads immediately but the page does not render for 30s in IE, 2m in NN, and never in Opera. I have narrowed the problem to these three tags:
Line 17 <script src="/index.php?title=-&action=raw&gen=js&smaxage=0" type="text/javascript"></script>
Lines 19-21 <style type="text/css">/*<![CDATA[*/ @import "/index.php?title=-&action=raw&smaxage=0&gen=css"; @import "/index.php?title=User:Buz/monobook.css&action=raw&ctype=text/css"; /*]]>*/</style>
and Line 22 <script src="/index.php?title=User:Buz/monobook.js&action=raw&ctype=text/javascript&dontcountme=s" type="text/javascript"></script>
(I apologize in advance if my mail client wraps these lines).
In each case, instead of rendering output, the php sends a redirect header to (I can only assume) itself over and over and over. So IE gives up in 30s, NN gives up with an error message "Redirection limit for this URL exceeded." and Opera continues redirecting forever.
So here's my action point and question: Is this a known problem? Is there a known fix/workaround? Does the known fix imply upgrading MediaWiki to an unstable build or changing the database? Does anyone else experience this problem or have they fixed it? If there is no good fix I'll simply start commenting out lines of the PHP source until it works, since these all seem to be targeted to user settings flexibility which is a concern I do not share at the moment. Correct me if I'm wrong :)
Much respect to the hard-working members of the open-source community.
On Jan 9, 2005, at 9:51 AM, N. M. Buzdor wrote:
In each case, instead of rendering output, the php sends a redirect header to (I can only assume) itself over and over and over. So IE gives up in 30s, NN gives up with an error message "Redirection limit for this URL exceeded." and Opera continues redirecting forever.
Fix your $wgScript setting or rewrite rules. Read the list archives for many instances of this problem.
-- brion vibber (brion @ pobox.com)
Fix your $wgScript setting or rewrite rules. Read the list archives for many instances of this problem.
Brion Vibber--
Thanks for your attention. I have searched the archives, as well as the MediaWiki documentation that I could find. I have come to conclude that my variables appear to be correct:
---LocalSettings.php snippet--- $wgScriptPath = ""; $wgScript = "$wgScriptPath/index.php"; $wgRedirectScript = "$wgScriptPath/redirect.php"; ---End snippet---
since my wiki is installed at the root http://cmw.buzdor.org/ meaning that http://cmw.buzdor.org/index.php?title=Main_Page is the correct location for the main page. Now, this is not the root of the filesystem, merely the root from a browser point of view (which is how redirects are sent). If this variable needs to represent /home/www/username/htdocs/cmw/ (which I believe would be wrong), I would need to change it.
I checked with several .htaccess experts and they agreed that my .htaccess was functioning correctly:
---.htaccess snippet--- RewriteEngine On RewriteOptions MaxRedirects=15 Options +FollowSymlinks RewriteBase / [... other rewrites excluded, confirmed innocent and irrelevant ...] RewriteCond %{HTTP_HOST} cmw.buzdor.org RewriteCond %{REQUEST_URI} !^/cmw/ RewriteRule ^(.*)$ cmw/$1 [L] ---End snippet---
I have no wish to deal with the "ugly url" issue, and have made no tweaks or changes to eliminate the long URLs. I prefer to leave them (in case I need an article with the name LocalSettings.php, for example :) ).
I looked through the archives and could not find any evidence that this $wgScript value (or it's dependency, $wgScriptPath) was incorrect. I request that you show me what I've got misconfigured and we can put a flag of some sort on your reply so that every time someone else has this problem ("many instances of this problem") we can point them to a specific URL with the exact answer.
Also, this represents a problem with the installer since this is a fresh install with no modifications to the code or settings other than those made by the installer script at install-time. Perhaps the installer can be patched.
Thanks so much for your time and I value your advice, --N. Buzdor
On Jan 11, 2005, at 10:48 AM, N. M. Buzdor wrote:
Fix your $wgScript setting or rewrite rules. Read the list archives for many instances of this problem.
---LocalSettings.php snippet--- $wgScriptPath = ""; $wgScript = "$wgScriptPath/index.php"; $wgRedirectScript = "$wgScriptPath/redirect.php"; ---End snippet---
[snip]
RewriteRule ^(.*)$ cmw/$1 [L] ---End snippet---
Won't this cause all the /index.php.* to be rewritten to /cmw/index.php.* internally?
This could produce a mismatch between the defined $wgScript and the path the wiki sees itself at internally when checking that raw pages are being loaded from the canonical URL.
-- brion vibber (brion @ pobox.com)
On Sun, 2005-01-09 at 12:51 -0500, N. M. Buzdor wrote:
In each case, instead of rendering output, the php sends a redirect header to (I can only assume) itself over and over and over. So IE gives up in 30s, NN gives up with an error message "Redirection limit for this URL exceeded." and Opera continues redirecting forever.
So here's my action point and question: Is this a known problem? Is there a known fix/workaround? Does the known fix imply upgrading MediaWiki to an unstable build or changing the database? Does anyone else experience this problem or have they fixed it? If there is no good fix I'll simply start commenting out lines of the PHP source until it works, since these all seem to be targeted to user settings flexibility which is a concern I do not share at the moment. Correct me if I'm wrong :)
You can comment out the redirect part in RawPage.php, about 2/3 down. I'm not sure it even makes a difference for IE, but haven't thoroughly tested it.
On Jan 11, 2005, at 11:07 PM, Gabriel Wicke wrote:
You can comment out the redirect part in RawPage.php, about 2/3 down. I'm not sure it even makes a difference for IE, but haven't thoroughly tested it.
DO NOT COMMENT THAT OUT! It's a workaround for an IE security flaw, for which we made a security fix release in late September.
Here's a demonstration of the flaw:
* Log in to your wiki. * Make a wiki page [[Evil.html]] * Put in it this text: <script type="text/javascript">alert(document.cookie);</script> * Comment out that check in RawPage.php * In IE, go to http://yourwiki/Evil.html?action=raw * Watch as your session cookie, user ID and name, and login token (if using 'remember my password') are displayed in a popup dialog.
Even though the wiki sends a "Content-type: text/x-wiki" header, the combination of a ".html" "file extension" on the URL and a "<script" in the first 200 bytes of the data tells IE that it should interpret the data as HTML -- including execution of any embedded JavaScript. Instead of a popup, this could be sending everything needed to log in as you to a malicious web site or submitting forms on the wiki with your privileges (editing pages, deleting, blocking, unblocking).
In Windows XP SP2, IE now has an option to turn off some of this autodetection, though I'm not sure it fixes all such holes. The unsafe behavior is on by default.
The workaround is to require that a 'raw' access be made from a canonical script URL, which will have a nice boring .php or .phtml extension and doesn't trigger the IE type autodetection bug. I did this with a redirect (instead of simply a 403 rejection) to preserve existing links.
-- brion vibber (brion @ pobox.com)
On Tue, 2005-01-11 at 23:49 -0800, Brion Vibber wrote:
In Windows XP SP2, IE now has an option to turn off some of this autodetection, though I'm not sure it fixes all such holes. The unsafe behavior is on by default.
Brion,
in my test only 5.0 exhibits this bug, 5.5 and 6.0 both offer to save the file (both on Win2K). For them the behaviour with php is unchanged. There are likely more interesting exploits with 5.0 anyway, possibly requiring more effort from the attacker.
The workaround is to require that a 'raw' access be made from a canonical script URL, which will have a nice boring .php or .phtml extension and doesn't trigger the IE type autodetection bug. I did this with a redirect (instead of simply a 403 rejection) to preserve existing links.
Unfortunately this breaks wikis where edit/diff etc urls are supposed to be short and tidy. There the browser gets stuck in an endless redirection loop. It's not too hard to fix this though, will change it in the next days.
Gabriel Wicke wrote:
in my test only 5.0 exhibits this bug, 5.5 and 6.0 both offer to save the file (both on Win2K).
I have tested only on 6.0 on WinXP, which most certainly exhibits the bug.
http://leuksman.com/misc/IE-bug-demo.png http://leuksman.com/misc/IE-bug-version.png
Unfortunately this breaks wikis where edit/diff etc urls are supposed to be short and tidy.
Such are inherently dangerous with IE bugs like this, which is why it was removed and sane URLs are now produced instead.
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
Even though the wiki sends a "Content-type: text/x-wiki" header, the
I think this is the problem in the first place. IE only guesses the content type if the MIME is something weird that it doesn't recognize. Would it be that bad to make it something like text/plain? It seems like the current fix, while it works, has caused a lot of needless confusion.
Official documentation on IE's MIME guessing:
http://msdn.microsoft.com/library/default.asp?url=/workshop/networking/monik...
On Jan 13, 2005, at 10:37 AM, Matthew Mullenweg wrote:
Brion Vibber wrote:
Even though the wiki sends a "Content-type: text/x-wiki" header, the
I think this is the problem in the first place. IE only guesses the content type if the MIME is something weird that it doesn't recognize.
Actually, that's not true. IE will attempt type recognition from the content if it *does* recognize the content-type, or if it *does* recognize the "file extension" on the URL.
If it *doesn't* recognize the content-type and it *doesn't* recognize the "file extension", then the content-type is taken at face value, usually.
Would it be that bad to make it something like text/plain? It seems like the current fix, while it works, has caused a lot of needless confusion.
We changed it *from* text/plain to prevent the automatic interpretation of data as HTML by Internet Explorer whenever the first 200 bytes contained '<html', '<head', '<body', or '<script'.
Official documentation on IE's MIME guessing:
http://msdn.microsoft.com/library/default.asp?url=/workshop/ networking/moniker/overview/appendix_a.asp
You'll notice it says that an unrecognized type will not be autodetected:
"1. If the "suggested" (server-provided) MIME type is unknown (not known and not ambiguous), FindMimeFromData immediately returns this MIME type as the final determination. The reason for this is that new MIME types are continually emerging, and these MIME types might have formats that are difficult to distinguish from the set of hard-coded MIME types for which tests exist. A good example of this is SGML, which can easily be classified incorrectly as HTML because it contains many of the same tags. Rather than weakening the hard-coded tests or risk incorrectly classifying new and as-yet-unknown MIME types for hard-coded known ones, priority is given to the server-supplied MIME type if it is unknown, since these MIME types are both specific and likely uncommon, and there are no hard-coded tests that can positively identify them."
Note that "text/plain" is explicitly listed as an "ambiguous" type which will always trigger type autodetection, which is why it cannot be used safely for user-supplied content.
-- brion vibber (brion @ pobox.com)
Hi, I entered title in install options field. However, I can see only [article_name] - Wikipedia in real title, not the name i entered.
I checked LocalSettings.php and found $wgSitename = 'Name I entered'
So what may be wrong?
Thanks, Linas
Special:Allmessages is a good page to search for messages. Please note that in some cases different skins display text from different messages.
Which version of mediawiki are you running?
-- Zigger
On Fri, 14 Jan 2005 01:52:31 +0200, Nomad wrote:
Hi, I entered title in install options field. However, I can see only [article_name] - Wikipedia in real title, not the name i entered.
I checked LocalSettings.php and found $wgSitename = 'Name I entered' ...
I run MediaWiki 1.4 BETA 4
Thanks, I've replaced all "Wikipedia"s to my title here. I guess it were "wikisitesuffix", "pagetitle" and "sitetitle" sections.
Now I can see my title everywhere (articles, help pages, Special: page etc) but main page. Starting page's title is not Main - My Title but still Main - Wikipedia instead.
Skins/MonoBook.php (skin I guess I'm using, default one) has
<title><?php $this->text('pagetitle') ?></title> title tag.
-----Original Message----- From: mediawiki-l-bounces@Wikimedia.org [mailto:mediawiki-l-bounces@Wikimedia.org] On Behalf Of Zigger Sent: 2005 m. sausio 14 d. 02:16 To: MediaWiki announcements and site admin list Subject: Re: [Mediawiki-l] Title of the site
Special:Allmessages is a good page to search for messages. Please note that in some cases different skins display text from different messages.
Which version of mediawiki are you running?
And one more question. Is there any way to configure starting page better than any other article-page? I mean i see www.wikipedia.org has highly customized main page (http://en.wikipedia.org/wiki/Main_Page) with featured article, many links to other pages, languages, external links, news section and so on. I don't need so many features, but to add something like "todays article" or "random article" would be nice. Is there any way to have main page include random article after the main greeting text? I guess maybe it has something to do with Template namespace?
I'm sorry about such maybe stupid questions, but mediaWiki is not very good documented (It is a very good soft however ;) ). In other hand maybe i just didn't find an answer in FAQ's and HELP's..
Linas
On Fri, 14 Jan 2005 02:57:08 +0200, Nomad nomad@nic-nac-project.de wrote:
... I don't need so many features, but to add something like "todays article" or "random article" would be nice. Is there any way to have main page include random article after the main greeting text? I guess maybe it has something to do with Template namespace?
The English Wikipedia's front page makes use of a combination of templates and variables (there's nothing special about front pages, these tricks can be used wherever you like): see http://meta.wikimedia.org/wiki/Help:Template and http://meta.wikimedia.org/wiki/Help:Variable
The basic idea is that you can have a load of templates called [[Template:Monthly page/January]], [[Template:Monthly page/Februrary]], or whatever, and then put code on the page like:
{{Monthly page/{{CURRENTMONTHNAME}}}}
Or, in en.wp's case: {{Wikipedia:Today's featured article/{{CURRENTMONTHNAME}} {{CURRENTDAY}}, {{CURRENTYEAR}}}}
There's one problem - unless I'm mistaken, you have to "purge" the page every so often [every day, for a different template per day], to update the inclusion. I think appending "?action=purge" (or, if it's already a "?title=..." style URL, adding "&action=purge") does the trick. But I may be completely wrong about all that.
Meanwhile, I'm afraid that, AFAIK, there's no way of grabbing a random number from the software, so a random article wouldn't work. You could of course use something like {{CURRENTTIME}}, and have a seperate template for every minute of the day (!) - but only if I'm wrong about having to manually purge the page.
On Fri, 14 Jan 2005 02:41:46 +0200, Nomad nomad@nic-nac-project.de wrote:
I've replaced all "Wikipedia"s to my title here. I guess it were "wikisitesuffix", "pagetitle" and "sitetitle" sections.
Hm. That's odd, I thought all hard-coded "wikipedia"s had been ripped out long ago - did you upgrade from a previous version at all?
Now I can see my title everywhere (articles, help pages, Special: page etc) but main page. Starting page's title is not Main - My Title but still Main - Wikipedia instead.
Could this be a caching problem? Try ctrl-f5 or ctrl-shift-r or however your browser does forced reload, and/or edit the page, to make sure you're not just looking at an out of date copy.
On Jan 13, 2005, at 3:52 PM, Nomad wrote:
I entered title in install options field. However, I can see only [article_name] - Wikipedia in real title, not the name i entered.
I checked LocalSettings.php and found $wgSitename = 'Name I entered'
So what may be wrong?
Likely possibilities:
a) Your database consists of an import from Wikipedia, and has "Wikipedia" hardcoded in the messages.
b) Your database has been upgraded from an older version which incorrectly hardcoded "Wikipedia" in the messages, and have kept the messages.
c) You have configured the wiki for some language where the language file has not been updated with the correct variables and has incorrectly hardcoded "Wikipedia" in the messages.
d) You changed the configuration from "Wikipedia" to your name in some odd way and need to clear the message cache. Delete all rows in the objectcache table.
-- brion vibber (brion @ pobox.com)
Thanks a lot everybody, the last one's bug reason was simple - Opera cached main page and didn't others for some weird reason. So i was able to see correct <title> for regular pages and wasn't for a main page. Problem solved.
And thanks for the templates and variables help links. Got it ;) If there is any way to request a feature, I would like to request an opportunity to access an article by it's database ID or somethink like that - to make it possible to have template with random article.
Linas
And thanks for the templates and variables help links. Got it ;) If there is any way to request a feature, I would like to request an opportunity to access an article by it's database ID or somethink like that - to make it possible to have template with random article.
Let me tell you what we do for this. We pass curid to index.php to bring the article with that id. You can take a look at the source of index.php. Close to top of the file, there's a section that checks if curid is being passed. When there's a curid, it doesn't look at the title variable, as far as I can remember.
So, http://host/w/index.php?title=x&curid=100 should bring the article with the database id 100.
This is for 1.3.9, don't know if it would work for 1.4. I might be wrong although it seems to work. There might be other things going on for earlier versions of an article.
-----Original Message----- From: mediawiki-l-bounces@Wikimedia.org [mailto:mediawiki-l- bounces@Wikimedia.org] On Behalf Of Nomad Sent: Friday, January 14, 2005 4:09 AM To: 'MediaWiki announcements and site admin list' Subject: RE: [Mediawiki-l] Title of the site
mediawiki-l@lists.wikimedia.org