Good day. I'm a new user to MediaWiki. I'm having problems getting it installed.
* used today's nightly.
* install went with no difficulty. the only seeming weirdness was that I chose a CreativeCommon license, and when the CC site "proceeded" me back to the install page, I had to manually choose the CC license radiobox (UI-wise, the existence of the form values, or a referrer from CC shoulda checked that radiobutton for me automatically).
* after going through the install, I moved my LocalSettings.php into place, and proceeded to loadup the index.php. all I received was a blank page (which contained the <html><body> </body></html> things of a typical PHP error).
Things I've looked at and tried:
* I'm not seeing any PHP errors in my error log (E~ALL) at all.
* I've confirmed that register_globals is on. In my .htaccess file for the /wiki directory, I've got the following:
<IfModule mod_php4.c> php_value register_globals 1 php_value log_errors 1 </IfModule>
<IfModule mod_rewrite.c> RewriteEngine off </IfModule>
I know .htaccess files work because these are actually overrides for a parent .htaccess file I've previously created (which turns OFF register globals).
* My PHP does NOT have iconv compiled (confirmed by looking at the compile line in an phpinfo()), and I am not able to recompile it. I put the iconv() hack into LocalSettings.php, same blank page, then realized that the iconv hack is now in the nightly (includes/ GlobalFunctions). I am worried, however, about the "might not work", but I would have suspected seeing some sort of "function iconv not defined" or whatever in my error log.
* Running "php index.php" from the command line doesn't give me much info besides a few warnings (this command was run NOT as the web server user, but rather as the root user):
Undefined index: SERVER_NAME in DefaultSettings.php on line 22 Undefined index: SERVER_PORT in DefaultSettings.php on line 23 Undefined index: SERVER_PORT in DefaultSettings.php on line 23 Undefined index: REQUEST_METHOD in Setup.php on line 90 Undefined index: REQUEST_URI in Setup.php on line 90 Uninitialized string offset: 0 in Setup.php on line 233
The only thing this confirms is a) well, it's at least loading up Setup.php, and c) the index undefines are caused because I'm running from the command line, not the Apache environ.
Any further thoughts on this? I'm not sure where else to explore.
Any further thoughts on this? I'm not sure where else to explore.
I've seen this asked a few times in the mediawiki-l archives, so just go over what I've fiddled with:
* I've confirmed that the MySQL PHP extension exists.
* I've turned on debugging, and only received a single header dump within debug file. I can provide it upon request, but there doesn't look to be anything interesting in there.
* The <html><body></body></html> thing I'm seeing is when Mozilla receives no data from the service. That literal output has nothing to do with PHP - my apologies.
* Adding display_errors at various points in various files doesn't help at all (but, as confirmation that php error logging IS working, if I make a syntax error in my meanderings with MW, that is logged successfully).
* Attempting URLs like index.php?title=Special:Specialpages gave me the same browser behavior, and besides the expected GET change, the same header output in the debug log.
Any further thoughts on this? I'm not sure where else to explore.
So, I've been stepping through this with die()'s and so forth, and eventually traced it to User::SetupSession(), which is called from Setup.php:
function SetupSession() { global $wgSessionsInMemcached, $wgCookiePath, $wgCookieDomain; if( $wgSessionsInMemcached ) { require_once( 'MemcachedSessions.php' ); } session_set_cookie_params( 0, $wgCookiePath, $wgCookieDomain ); session_cache_limiter( 'private, must-revalidate' ); @session_start(); }
And this is where the problem lies. If I remove the @ from session_start, I'll receive the following in my error log:
PHP Fatal error: session_start(): Failed to initialize storage module: user (path: /tmp) in User.php on line 159
Which at least gives me a bit more to go on now. I'll continue to poke around and report what I find, if anything, for the sake of future searchers.
PHP Fatal error: session_start(): Failed to initialize storage module: user (path: /tmp) in User.php on line 159
Alright, I've got it. A quick Google search brings me to this page:
http://bugs.php.net/bug.php?id=25876
and one suggestion is to:
As suggested by mivox on Feb 12 in comments to bug 26038, which seems to be a duplicate of this one, I added a line in my apache.conf: php_value session.save_handler files
I added this to my .htaccess file, and immediately was able to see the index page of the MediaWiki. Why, I'm not really sure. Here's what I know:
* the /tmp directory is used by a number of other PHP installations to save sessions, and there are easily one hundred saved sessions in there. I can't delete them, as per one suggestion, because, well, that'd suck for those folks.
* I think the big culprint, however, is my parent .htaccess file, which was created by Drupal (a PHP CMS) and myself. Within that file, amongst other things, are the following definitions:
php_value session.cache_expire 200000 php_value session.gc_maxlifetime 200000 php_value session.cookie_lifetime 2000000 php_value session.auto_start 0 php_value session.save_handler user php_value session.cache_limiter none
Notice the save_handler set to "user", which also appeared in the error message pasted above.
So thus the solution, as per the above suggestion, was to reset the save_handler to the default setting in my /etc/httpd/php.ini file, which was "files". Once I did that, everything was magical.
Morbus Iff wrote:
- I've confirmed that register_globals is on. In my .htaccess file for the /wiki directory, I've got the following:
I would strongly recommend that you turn register_globals *off*. MediaWiki doesn't need it, and it may be a security risk in general.
-- brion vibber (brion @ pobox.com)
I would strongly recommend that you turn register_globals *off*. MediaWiki doesn't need it, and it may be a security risk in general.
Ah - then I've read some old instructions that told me to turn them on...
http://meta.wikimedia.org/wiki/Documentation:Installation Build and install as instructed. Set "register_globals" on
I do see, at the bottom, the following:
Solution: use on of the newer versions 1.2++ and you don't need register_globals anymore!
which I hadn't seen before. And also: http://meta.wikimedia.org/wiki/FAQ MediaWiki currently depends on http://www.php.net/register_globalsregister_globals (http://www.php.net/register_globals), which is off by default in most PHP installations since version 4.2.0. Until a version is released that does without, you'll have to enable it.
Are these just old bits that aren't updated for the Phase III code?
Morbus Iff wrote:
I would strongly recommend that you turn register_globals *off*. MediaWiki doesn't need it, and it may be a security risk in general.
Ah - then I've read some old instructions that told me to turn them on... http://meta.wikimedia.org/wiki/Documentation:Installation
Argh, will someone remind me again who thought it would be a good idea to make two or three separate documentation hierarchies on meta? Sigh...
Are these just old bits that aren't updated for the Phase III code?
They are old, but note that phase III refers to the entire lineage of the code since the rewrite of mid-2002. Anything with "MediaWiki" in the name is Phase III.
-- brion vibber (brion @ pobox.com)
As the database of my Wiki grows biger and biger in size, I wonder if I can delete some useless pages permanently from the database.
Thank you for your comment!
Cheers, Collin
Collin Hsu wrote:
As the database of my Wiki grows biger and biger in size, I wonder if I can delete some useless pages permanently from the database.
Delete the page using the normal page deletion feature, then clear out the archive table (where deleted revisions are stored):
DELETE FROM archive;
-- brion vibber (brion @ pobox.com)
Thank you!
But can I just delete some earlier histories of a page and keep the later and current page?
Collin -----Original Message----- From: mediawiki-l-bounces@Wikimedia.org [mailto:mediawiki-l-bounces@Wikimedia.org] On Behalf Of Brion Vibber Sent: Saturday, August 07, 2004 12:59 PM To: MediaWiki announcements and site admin list Subject: Re: [Mediawiki-l] Is it possible to delete a page permanently fromthe database?
Collin Hsu wrote:
As the database of my Wiki grows biger and biger in size, I wonder if I can delete some useless pages permanently from the database.
Delete the page using the normal page deletion feature, then clear out the archive table (where deleted revisions are stored):
DELETE FROM archive;
-- brion vibber (brion @ pobox.com)
mediawiki-l@lists.wikimedia.org