Hi everybody,
a SysAdmin in my company has attempted to migrate our Mediawiki installation from a Windows server to a Linux one, but discrepancies are arising between the contents of the two.
Specifically, while many pages work just fine, hinting to a mostly working installation, but many other pages result into blank browsers, no matter if they should have been carried over as normal by the MySQL-dump that has been used to transfer the DB.
The only difference I can think of between the failing pages and those that work is that the former had been originally generated via XML imports and transclude subpages. (*)
Is this something that could represent a problem? And is there a page on mediawiki.org that I could recommend to our SysAdmin to go through?
Thank you in advance.
Manu
(*) The rationale behind this was to use the XML import function to procedurally generate the subpages while the users retain the capability to edit the bits of the actual page that do not rely on transclusion of the subpages.
Further on my previous email on this subject:
through Special:Export I have verified that the content of the Windows and Linux installation is, as far as I can see, identical for pages that fail on Linux. I can't even begin to fathom where the problem might be.
Each individual element contributing to any given non-working page seems to work fine in other pages. I.e., subpages work, templates work, parser functions work, string functions work.
Invisible characters pages? Might be, as stated here: http://www.mediawiki.org/wiki/Manual:Backing_up_a_wiki#Character_set
I asked the SysAdmin to verify if this problem applies, but if it doesn't I'm running out of ammo.
Also is this the right syntax to enable logging? $wgDebugLogFile = "{$IP}/debugLogFile.txt";
Somehow it worked on Windows but not on Linux.
Manu
On 31/10/2007, Emanuele D'Arrigo manu3d@gmail.com wrote:
Also is this the right syntax to enable logging? $wgDebugLogFile = "{$IP}/debugLogFile.txt";
Somehow it worked on Windows but not on Linux.
You'll need to touch the file (to create it) and ensure that whatever user Apache is running under has permission to write to it. Under Windows, Apache usually runs as a service with Local System privileges, so such things don't generally crop up with the default setup.
Rob Church
On Oct 31, 2007 5:40 PM, Rob Church robchur@gmail.com wrote:
You'll need to touch the file (to create it) and ensure that whatever user Apache is running under has permission to write to it. Under Windows, Apache usually runs as a service with Local System privileges, so such things don't generally crop up with the default setup.
Thank you Rob, this did work.
For you and everybody else who might be able to help, here is the log of one page that returns a blank page:
------------------------------------------------------------------------------------
Start request GET /index.php?title=Template:GenericElement Host: wiki.vtr.co.uk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: en-gb,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: wikidb_session=lslbfq52ql2osp73sqmhe4i1h4; wikidbUserID=7; wikidbUserName=Manu.d
Main cache: FakeMemCachedClient Message cache: MediaWikiBagOStuff Parser cache: MediaWikiBagOStuff Unstubbing $wgMessageCache on call of $wgMessageCache->addMessages from wfCite Unstubbing $wgParser on call of $wgParser->setHook from Cite::setHooks Unstubbing $wgContLang on call of $wgContLang->getMagic from MagicWord::load Unstubbing $wgOut on call of $wgOut->addScript from TreeView::addJS Unstubbing $wgLang on call of $wgLang->getCode from smwfInitMessages Unstubbing $wgUser on call of $wgUser->getOption from StubUserLang::_newObject Cache miss for user 7 Unstubbing $wgLoadBalancer on call of $wgLoadBalancer->getConnection from wfGetDB Logged in from session Fully initialised Language::loadLocalisation(): got localisation for en from source OutputPage::checkLastModified: USER DISABLED CACHE Article::tryFileCache(): not cacheable Article::view using parser cache: yes Trying parser cache wikidb:pcache:idhash:145-0!1!0!!en!2 Found. MessageCache::load(): got from global cache
------------------------------------------------------------------------------------
Beside the fact that it doesn't end with "Request ended normally" is there anything that hints to where the problem is?
Manu
On 31/10/2007, Emanuele D'Arrigo manu3d@gmail.com wrote:
For you and everybody else who might be able to help, here is the log of one page that returns a blank page:
Completely blank page (blank source)?
Check the PHP error log to see what's going on, since a completely blank page usually implies a fatal error, and this often won't be printed to the screen (and should never be, in a production environment). MediaWiki's abrupt log halt would also support this theory.
Also worth checking is the amount of memory allocated to PHP, i.e. the memory_limit in PHP.ini, since if this is significantly lower on the new box, that could indicate the pages are simply too large to process under that configuration. The parser is a beast, and needs quite a bit of room when dealing with a large, fancy page.
Rob Church
On Wednesday 31 October 2007 12:35, Emanuele D'Arrigo wrote:
Further on my previous email on this subject:
through Special:Export I have verified that the content of the Windows and Linux installation is, as far as I can see, identical for pages that fail on Linux. I can't even begin to fathom where the problem might be.
Each individual element contributing to any given non-working page seems to work fine in other pages. I.e., subpages work, templates work, parser functions work, string functions work.
Invisible characters pages? Might be, as stated here: http://www.mediawiki.org/wiki/Manual:Backing_up_a_wiki#Character_set
I asked the SysAdmin to verify if this problem applies, but if it doesn't I'm running out of ammo.
Also is this the right syntax to enable logging? $wgDebugLogFile = "{$IP}/debugLogFile.txt";
just a guess but you may need to check the $IP declaration in LocalSettings.php if you simply dumped the wikidb from windows to linux. The actual directory strings will be different. I noticed this on some extensions that I wanted to use that were actually developed on a windows machine. You may have directory trouble on the pages themselves as well.
Somehow it worked on Windows but not on Linux.
Manu
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
We had some problems with migrating to Linux as well.
In the end we found that the trouble was caused by an ftp-program that converted anything (files and directories) into lowercase.
Due to the fact that mediawiki is case sensitive that ended in blank pages as well. You might have a look.
Kind regards
Albert Cremer
"Emanuele D'Arrigo" manu3d@gmail.com schrieb im Newsbeitrag news:915dc91d0710311035s77db604era33583b5fda9bab2@mail.gmail.com...
Further on my previous email on this subject:
through Special:Export I have verified that the content of the Windows and Linux installation is, as far as I can see, identical for pages that fail on Linux. I can't even begin to fathom where the problem might be.
Each individual element contributing to any given non-working page seems to work fine in other pages. I.e., subpages work, templates work, parser functions work, string functions work.
Invisible characters pages? Might be, as stated here: http://www.mediawiki.org/wiki/Manual:Backing_up_a_wiki#Character_set
I asked the SysAdmin to verify if this problem applies, but if it doesn't I'm running out of ammo.
Also is this the right syntax to enable logging? $wgDebugLogFile = "{$IP}/debugLogFile.txt";
Somehow it worked on Windows but not on Linux.
Manu
mediawiki-l@lists.wikimedia.org