Last modified: 2008-09-04 06:24:50 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 13770 - Use Preprocessor_Hash by default to avoid missing DOM module errors
Use Preprocessor_Hash by default to avoid missing DOM module errors
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: Normal normal with 1 vote (vote)
: ---
Assigned To: Tim Starling
: patch, patch-need-review
: 14884 14885 14911 14946 15326 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-16 23:58 UTC by Brion Vibber
Modified: 2008-09-04 06:24 UTC (History)
9 users (show)

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


Attachments
Fallback to Preprocessor_DOM on install (1.05 KB, patch)
2008-05-05 19:42 UTC, Chad H.
Details

Description Brion Vibber 2008-04-16 23:58:13 UTC
Although PHP 5's DOM module is included by default when you compile PHP yourself, a surprising number of Linux and Unix-y distros like to remove it.

(Reported cases include FreeBSD ports and Fedora Core 6.)

This results in MediaWiki 1.12 and 1.13-svn failing due to DOMDocument class being missing, so Preprocessor_DOM gets you nowhere.

Assuming Preprocessor_Hash is functioning correctly (passes tests, and seems ok...), we should consider using it by default and dropping the DOM-based processor.
Comment 1 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-04-17 00:02:07 UTC
(In reply to comment #0)
> (Reported cases include FreeBSD ports and Fedora Core 6.)

And RHEL 5.
Comment 2 Chad H. 2008-05-05 19:42:50 UTC
Created attachment 4879 [details]
Fallback to Preprocessor_DOM on install

I think it makes more sense to default to Preprocessor_DOM, then fall back to Preprocessor_Hash if DOMDocument doesn't exist. This patch will add a check to the LocalSettings.php generation to add $wgParserConf['preprocessorClass'] = 'Preprocessor_Hash' to the configuration if class_exists() returns false.
Comment 3 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-05-05 23:44:53 UTC
This doesn't belong in the generated LocalSettings.php.  That means it won't take effect for upgraded installs.  Instead, it should gracefully fall back to the hash preprocessor when you try to load the DOM preprocessor, right before it would normally give a fatal error about DOMDocument not existing (or some suitable time period before that, anyway).

This is assuming there's a reason to keep the DOM-based preprocessor at all.
Comment 4 Brion Vibber 2008-05-05 23:47:20 UTC
Setting the default appropriately in DefaultSettings.php (based on DOM module presence) should do the job fine.

Probably someone should do a quick benchmark to compare performance; if the hash version is about as fast or faster, then just using it by default would be easiest. :)
Comment 5 Brion Vibber 2008-05-06 00:02:16 UTC
Damn the torpedoes!

Switched to hash by default in r34283 (trunk) and r34284 (1.12 branch for 1.12.1). Would be nice to do more testing of memory and CPU usage.
Comment 6 Chad H. 2008-05-06 00:49:29 UTC
(In reply to comment #4)
> Setting the default appropriately in DefaultSettings.php (based on DOM module
> presence) should do the job fine.
> 
> Probably someone should do a quick benchmark to compare performance; if the
> hash version is about as fast or faster, then just using it by default would be
> easiest. :)
> 

I considered that, but figured a 1-time check-and-set would be less expensive in the long run rather than doing the check each time Mediawiki is run.
Comment 7 Brion Vibber 2008-07-22 19:05:23 UTC
*** Bug 14885 has been marked as a duplicate of this bug. ***
Comment 8 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-07-22 21:10:03 UTC
*** Bug 14884 has been marked as a duplicate of this bug. ***
Comment 9 Niklas Laxström 2008-07-27 16:43:34 UTC
*** Bug 14946 has been marked as a duplicate of this bug. ***
Comment 10 Bryan Tong Minh 2008-07-27 17:03:40 UTC
It appears that if php-xml is not installed, another class with the same name but a different constructor <http://www.php.net/manual/en/class.domdocument.php> is present. The current fix checks for class_exists('DOMDocument') which will pass but fail on construction of the DOMDocument. 

The detection mechanism should probably be a bit more sophisticated...
Comment 11 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-07-27 18:16:00 UTC
Any suggestions?

Should this block 1.13 release, since this completely breaks MediaWiki out of the box on default RHEL installations?
Comment 12 Bryan Tong Minh 2008-07-27 19:29:42 UTC
I think extension_loaded('xml') should work, but I'm not exactly sure whether 'xml' is the correct string. I can not test this as there appears to be no way to disable php-xml on Windows.

It should probably be fixed in 1.13 branch before the release. 

Somebody here who can test this? Replace

} elseif ( class_exists( 'DOMDocument' ) ) {

by

} elseif ( extension_loaded( 'xml' ) ) {

in Parser.php on line 136.
Comment 13 Bryan Tong Minh 2008-07-27 19:41:42 UTC
*** Bug 14911 has been marked as a duplicate of this bug. ***
Comment 14 Brion Vibber 2008-07-30 20:27:08 UTC
I'm pretty sure 'xml' is the SAX parser and utf8_encode/utf8_decode functions (which we rely on in lots of low-level code and check for in the installer).

I believe 'dom' is the current PHP 5 DOM module.

This is not to be confused with 'domxml' which existed in PHP 4 and is not compatible.
Comment 15 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-07-30 21:07:03 UTC
I can confirm that the package I needed to install to get this to work *seems* to give 'dom' loaded if it's installed, 'dom' not loaded if it's not installed.  So that would seem to be correct.
Comment 16 Brion Vibber 2008-08-01 22:10:43 UTC
Assigning to Tim to double-check the current status of this before 1.13 final release.
Comment 17 Tim Starling 2008-08-11 18:00:26 UTC
Fixed in 39158, backported for release in 1.13.0rc3
Comment 18 DCLXVI 2008-08-17 22:26:32 UTC
strange, the error still exist on windows install of 1.13.0

I can post the error and information about XAMPP version and included software, if needed.
Comment 19 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-08-17 23:46:31 UTC
I'm guessing phpinfo() would be most useful.
Comment 20 Brion Vibber 2008-08-18 21:48:18 UTC
Got a report from some folks on IRC whose server reported true for both:

extension_loaded('dom')

*and*

extension_loaded('domxml')

It looks like the DOMXML extension is overriding the class, probably by loading second, so "wins", and we get the broken one that doesn't work.

(They say they installed XAMPP and it's PHP 5.2.6, so should be a recent package. Sounds like they're just blindly shipping both modules without realizing they conflict!)


We can either check to make sure they're not both loaded:
} elseif ( extension_loaded( 'dom' ) && !extension_loaded( 'domxml' ) ) {

or we can check in more detail which class we're going to get when we instantiate it, maybe with some reflection or some crap.
Comment 21 Bryan Tong Minh 2008-08-19 12:51:54 UTC
Checking on instantiation sounds like an incredible difficult way to do it.

I would go for the ( extension_loaded( 'dom' ) && !extension_loaded( 'domxml' ) ) solution.
Comment 22 Brion Vibber 2008-08-26 18:31:02 UTC
*** Bug 15326 has been marked as a duplicate of this bug. ***
Comment 23 Tim Starling 2008-09-04 06:24:50 UTC
Fixed in r40419 using the method in comment #21. Tested with a conflicting install of both dom and domxml. I had to hack the config.m4 in domxml, disabling conflict checks, to force it to create this unholy combination. Will backport to 1.13.1.


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


Navigation
Links