Last modified: 2011-04-14 15:12:45 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T6132, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 4132 - dumpHtml.php causes PHP fatal errors (due to premature output) when read access is locked
dumpHtml.php causes PHP fatal errors (due to premature output) when read acce...
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
DumpHTML (Other open bugs)
unspecified
All All
: Low normal with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
: testme
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-01 14:49 UTC by Sider
Modified: 2011-04-14 15:12 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Sider 2005-12-01 14:49:11 UTC
I used MW 1.5 beta 3, upgraded to 1.52 and later to 1.6devel, got still a
problem with dumphtml.

One problem to be solved was the case if wiki is secured by password, i got a
workaround from Tim Starling for this, which get me some lines further.

new entry in function setupGlobals
$wgGroupPermissions;

in advance of $this->setupDone = true; the following line
$wgGroupPermissions['*']['read'] = true;

Before i had to change localsettings.php, but got the same at the end:

maintenance>php dumphtml.php
Creating static HTML dump in directory static.
Starting from page_id 1 of 1929.
Using database localhost
Writing MediaWiki~Common.css
Writing MediaWiki~Standard.css

After a while there is an error in php.exe:

Die Anweisung in "0x100ab2cb" verweist auf Speicher in "0x0240f000" Der Vorgang
"read" konnte nicht auf dem Speicher durchgeführt werden.

dumpHTML.inc contains following..

'REPORTING_INTERVAL', 500

# Destination directory
var $dest;

# Show interlanguage links?
var $interwiki = true;
	
# Depth of HTML directory tree
var $depth = 3;

# Directory that commons images are copied into
var $sharedStaticPath;
	
# Relative path to image directory
var $imageRel = 'upload';

# Copy commons images instead of symlinking
var $forceCopy = false;

# Make links assuming the script path is in the same directory as 
# the destination
var $alternateScriptPath = false;

# Original values of various globals
	var $oldArticlePath = false, $oldCopyrightIcon = false;

# Has setupGlobals been called?
var $setupDone = false;

# List of raw pages used in the current article
var $rawPages;

Error only seems to appear if $setupDone = false, but with set to true it doesnt
write MediaWiki~Common.css and MediaWiki~Standard.css.

The next problem seems to be that category tables aren't found because the table
prefix is not used and the table isn't found because of that.

There is no index.html in /static. The pages which were created only link to
Namespace:Article, but not to http://xxx/Namespace:Article.

Any help available?
Comment 1 Sider 2005-12-01 14:52:22 UTC
One problem i forgot: the pages in html which were created are in UTF-8, but
browser show them in ISO-8859-1, so the umlautz are incorrect.
Comment 2 Sider 2005-12-05 15:41:56 UTC
Additional information: I use PHP: 5.0.4 (apache2handler), MySQL: 4.1.12-nt.

translation of error message in php.exe in english:

The instruction in "0x100ab2cb" refers to memory in "0x0240f000". The "read"
process could not be done in memory.

Tim Starling suggested to try another version of php, like 4.4.1, to use a
debugger or linux instead.

But it still remains a bug. :-/
Comment 3 Sider 2005-12-13 09:32:59 UTC
The bug appears on Windows 2000 and Windows XP too, just checked it.
Comment 4 Sider 2006-04-05 14:24:10 UTC
In the meantime I upgraded to MW 1.5.8 on PHP: 5.1.1, MySQL: 5.0.18-nt, Apache:
2.2.0 

If I write $wgGroupPermissions['*']['read'] = true; into Localsettings
everything seems to work fine. But if I dont do so, I get these errors, even
with the modification of dumpHTML.inc suggested by Tim Starling, which I stated
at start here:

Warning: Cannot modify header information - headers already sent by (output star
ted at \maintenance\dumpHTML.php:66) in \includes\OutputPage.php on line 355

Warning: Cannot modify header information - headers already sent by (output star
ted at \maintenance\dumpHTML.php:66) in \includes\OutputPage.php on line 359

Warning: Cannot modify header information - headers already sent by (output star
ted at \maintenance\dumpHTML.php:66) in \includes\OutputPage.php on line 387

Warning: Cannot modify header information - headers already sent by (output star
ted at \maintenance\dumpHTML.php:66) in \includes\OutputPage.php on line 388

Warning: Cannot modify header information - headers already sent by (output star
ted at \maintenance\dumpHTML.php:66) in \includes\OutputPage.php on line 390

Any help available?
Comment 5 Niklas Laxström 2009-04-07 07:47:10 UTC
Does this problem still occur?
Comment 6 Sider 2009-08-14 10:38:53 UTC
Yes, still there. The move from core into an extension did not change it.

Used Windows XP Pro, MediaWiki 1.13.4, PHP 5.2.8 (apache2handler), MySQL 5.1.30-community. 

Error message: Warning: Cannot modify header information - headers already sent by (output started at \extensions\DumpHTML\dumpHTML.inc:619) in \includes\WebResponse.php on line 10

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links