I just did a fresh installation, details below, and I'm getting a blank home page. If I view the source I see basic HTML header lines and an empty body. I looked in the archives and it seems like this might be a bug with 1.8.2, but I'd rather get some feedback before going to the hassle of downgrading. I moved LocalSettings.php as required. Win Server 2003, IIS6, PHP5, MySQL 4.1 The other installation details are (**** obscures some details for security):
PHP 5.1.6 installed Found database drivers for: MySQL Warning: PHP's register_globals option is enabled. Disable it if you can. MediaWiki will work, but your server is more exposed to PHP-based security vulnerabilities. PHP server API is cgi-fcgi; using ugly URLs (index.php?title=Page_Title) Have XML / Latin1-UTF-8 conversion support. PHP is configured with no memory_limit. Have zlib support; enabling output compression. Couldn't find Turck MMCache, eAccelerator or APC. Object caching functions cannot be used. GNU diff3 not found. Found GD graphics library built-in, image thumbnailing will be enabled if you enable uploads. Installation directory: C:\Domains**** Script URI path: Environment checked. You can install MediaWiki. Warning: $wgSecretKey key is insecure, generated with mt_rand(). Consider changing it manually. Generating configuration file...
Database type: MySQL Loading class: DatabaseMysql Attempting to connect to database server as ****...success. Connected to 4.1.21-community-max-nt-log Database **** exists Creating tables... using MySQL 4 table defs... done. Initializing data... Created sysop account ****. Initialising "MediaWiki" namespace for language code en... Done. Updated: 0, inserted: 1495, kept: 0. Creating LocalSettings.php...
Installation successful! Move the config/LocalSettings.php file into the parent directory, then follow this link to your wiki.
Why is PHP's register_globals option is enabled??? Thats rather unsafe, any person has access to MediaWiki's source code, If they find one mistake in the way vars are handled they could get your admin password using an xss exploit?
As far as the page not working, what is the page you expect to work?
site.com/wiki/index.php
is error reporting turned on in php.ini if index.php exists it should atleast throw some errors? The only other thing I can think of is did you modify MonoBook.php? or index.php in some wierd way? I had added a html comment under the </html> tag on my MonoBook.php file once and it gave me simular trouble to what you have: sometimes only page headers would be sent, no page content.
Chris
Monday, January 8, 2007, 7:11:23 AM, Chris wrote:
Why is PHP's register_globals option is enabled??? Thats rather unsafe, any person has access to MediaWiki's source code, If they find one mistake in the way vars are handled they could get your admin password using an xss exploit?
Don't know about that. My host is a biggish company. I'll email their support.
As far as the page not working, what is the page you expect to work?
site.com/wiki/index.php
Yup
is error reporting turned on in php.ini if index.php exists it should atleast throw some errors? The only other thing I can think of is did you modify MonoBook.php? or index.php in some wierd way? I had added a html comment under the </html> tag on my MonoBook.php file once and it gave me simular trouble to what you have: sometimes only page headers would be sent, no page content.
According to phpinfo() error_reporting = 341, otherwise error_* is "no value". Can I change these using my own php.ini in the root folder? If so, what are recommended values?
I haven't made any changes at all to the out-of-the-box mediawiki setup.
You need access to somthing like "/usr/local/lib/php.ini" do you have ssh access? If you mess with the index.php file like add some html to the top <h1>test</h1> does it show up? If it does try writting some bad php at the top <?php aaa ?> does this display the correct error msg?
You really need to figure out where you have problems, is it the php install, is it the wiki install is it apache, etc ... Figure out what does and doesnt work on your system, do other php pages load correctly, are errors being reported when there is a problem etc.. A blank page is a really hard problem to access.
Any one else have any ideas?
Chris
On 1/8/07, Robin Faichney robin@robinfaichney.org wrote:
Monday, January 8, 2007, 7:11:23 AM, Chris wrote:
Why is PHP's register_globals option is enabled??? Thats rather unsafe, any person has access to MediaWiki's source code, If they find one mistake in the way vars are handled they could get your admin password using an xss exploit?
Don't know about that. My host is a biggish company. I'll email their support.
As far as the page not working, what is the page you expect to work?
site.com/wiki/index.php
Yup
is error reporting turned on in php.ini if index.php exists it should atleast throw some errors? The only other thing I can think of is did you modify MonoBook.php? or index.php in some wierd way? I had added a html comment under the </html> tag on my MonoBook.php file once and it gave me simular trouble to what you have: sometimes only page headers would be sent, no page content.
According to phpinfo() error_reporting = 341, otherwise error_* is "no value". Can I change these using my own php.ini in the root folder? If so, what are recommended values?
I haven't made any changes at all to the out-of-the-box mediawiki setup.
-- Robin Faichney The Invisible Eye on Consciousness http://www.robinfaichney.org/
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Wednesday, January 10, 2007, 5:59:22 AM, Chris wrote:
You need access to somthing like "/usr/local/lib/php.ini" do you have ssh access?
No, and it's a shared machine.
If you mess with the index.php file like add some html to the top
<h1>test</h1> does it show up? If it does try writting some bad php at the top <?php aaa ?> does this display the correct error msg?
I guessed this might be the same problem as Jan was seeing, ie this behaviour from 1.8.2 while all other versions work fine, so I tried 1.7.1 and it works. I'm going to stick with that for now. Thanks anyway.
On 10/01/07, Robin Faichney robin@robinfaichney.org wrote:
I guessed this might be the same problem as Jan was seeing, ie this behaviour from 1.8.2 while all other versions work fine, so I tried 1.7.1 and it works. I'm going to stick with that for now. Thanks anyway.
Haphazard guessed workaround based on the most common problem people are having with 1.8.x for "no apparent reason":
Set $wgDisableCounters = true; in LocalSettings.php.
If this works, then the problem should be fixed in the 1.9 branch, 1.9.0rc2 is available now.
Rob Church
Hello Robin!
Robin Faichney schrieb:
I guessed this might be the same problem as Jan was seeing
Yes, seems so. Downgrading to 1.7.1 helped :) I think, Brion now identified the reason with the Zend Optimizer.
I'm going to stick with that for now. Thanks anyway.
In the last days this bug seemed to be fixed in the 1.9-svn-trunk, so in the upcomming 1.9 release this will be fixed. This this bug: http://bugzilla.wikimedia.org/show_bug.cgi?id=8439
1.9 will be release today or tomorror ... in the notes you will find:
=== Zend Optimizer === A bug in some versions of PHP 5 and Zend Optimizer which was triggered under MediaWiki 1.8.x has been worked around by disabling some internal debugging features when Zend Optimizer is loaded. This should solve some common "blank page" problems.
Regards, Jan
Hi Jan, having looked at the bug report it now seems this is not the same problem after all, because I get valid HTML back, with head and body tags but no content. I might try 1.9 anyway just to see what happens, and if so I'll report the result here.
Wednesday, January 10, 2007, 10:27:30 AM, Jan wrote:
Hello Robin!
Robin Faichney schrieb:
I guessed this might be the same problem as Jan was seeing
Yes, seems so. Downgrading to 1.7.1 helped :) I think, Brion now identified the reason with the Zend Optimizer.
I'm going to stick with that for now. Thanks anyway.
In the last days this bug seemed to be fixed in the 1.9-svn-trunk, so in the upcomming 1.9 release this will be fixed. This this bug: http://bugzilla.wikimedia.org/show_bug.cgi?id=8439
1.9 will be release today or tomorror ... in the notes you will find:
=== Zend Optimizer === A bug in some versions of PHP 5 and Zend Optimizer which was triggered under MediaWiki 1.8.x has been worked around by disabling some internal debugging features when Zend Optimizer is loaded. This should solve some common "blank page" problems.
Regards, Jan
On 10/01/07, Robin Faichney robin@robinfaichney.org wrote:
Hi Jan, having looked at the bug report it now seems this is not the same problem after all, because I get valid HTML back, with head and body tags but no content. I might try 1.9 anyway just to see what happens, and if so I'll report the result here.
You've tried the workaround I suggested?
If so, and it didn't fix it, then check the PHP and Apache error logs for relevant lines. If there are errors there, but you don't understand them fully, just post them here and someone is bound to fire back a diagnosis.
Rob Church
Wednesday, January 10, 2007, 5:18:10 PM, Rob wrote:
On 10/01/07, Robin Faichney robin@robinfaichney.org wrote:
Hi Jan, having looked at the bug report it now seems this is not the same problem after all, because I get valid HTML back, with head and body tags but no content. I might try 1.9 anyway just to see what happens, and if so I'll report the result here.
You've tried the workaround I suggested?
You must have missed my previous message in which I said I'd downgraded to 1.7.1, which worked for me. I've now tried 1.9rc2, which also works. You'll understand I'm not about to go back to 1.8.2 just to find out why it didn't work!
On 10/01/07, Robin Faichney robin@robinfaichney.org wrote:
You must have missed my previous message in which I said I'd downgraded to 1.7.1, which worked for me. I've now tried 1.9rc2, which also works. You'll understand I'm not about to go back to 1.8.2 just to find out why it didn't work!
*shrug*
I'm betting it was that problem, then.
Rob Church
mediawiki-l@lists.wikimedia.org