Difference between revisions of "Issue:DPL incompatible with MW 1.16 alpha"
(reason for this bug and a dirty solution) |
|||
| Line 45: | Line 45: | ||
:Comment was: ''"Remove <a> tag hook for now, pending resolution of implementation issues as discussed on CR [http://www.mediawiki.org/wiki/Special:Code/MediaWiki/58717 r58717]."'' --[[User:Nachteule|Nachteule]] 13:35, 22 February 2010 (UTC) | :Comment was: ''"Remove <a> tag hook for now, pending resolution of implementation issues as discussed on CR [http://www.mediawiki.org/wiki/Special:Code/MediaWiki/58717 r58717]."'' --[[User:Nachteule|Nachteule]] 13:35, 22 February 2010 (UTC) | ||
---- | ---- | ||
| − | + | ||
| − | + | The reason is: Since MW-1.16 there is no tag hook for <code><html></code> in the list of hooks if [http://www.mediawiki.org/wiki/Manual:$wgRawHtml $wgRawHtml] is false. See includes/parser/CoreTagHooks.php in function register (the first one). '''!!!'''Don't set <code>$wgRawHtml=true</code> in an environment where everyone can edit pages, because this is a security hole'''!!!''' | |
| − | + | ||
| − | + | ([[:Image:Semeb_extensions.zip|Version of 2009-10-01]]:) In DPLMain.php line 27 - in the very, very, very long (over 3000 lines) function dynamicPageList - you set $wgRawHtml to true, which affects only new parsers (after a method of the Parser class calls clearState(), which calls firstCallInit(), which calls CoreParserFunctions::register()). And in line 2472 you again set $wgRawHtml to true. The $localParser has the <code><html></code>-Hook, but it's seems to be used only for some minor parse things, definitively not for the main result. So the result contains sometimes some <code><html>-</html></code> but no parser resolves this. In DPLSetup.php in function dplParserFunction() I added between the version_compare 1.12.0 and the last return statement: | |
| − | + | ||
| − | + | <pre>if ( version_compare( $wgVersion, '1.16' ) > 0 ) { | |
| − | + | $p = new Parser(); | |
| − | + | $p->setHook('html', array($parser->mTagHooks['pre'], 'html')); | |
| + | $parsed = $p->parse($dplresult, $parser->mTitle, $parser->mOptions); | ||
| + | return array(substr($parsed->mText, 0, strrpos($parsed->mText, '<!--')), 'noparse' => false, 'isHTML' => true); | ||
| + | }</pre> | ||
| + | |||
| + | This dirty hack will now resolve the <html> parts in the returned result, but not in every case. I.e. [[DPL_Example_019]] will not work, because the <nowiki>[[Image:...]]</nowiki> will not be resolved. Maybe a better solution would be to find a way to avoid the <html> in general. --[[User:Dedlfix|Dedlfix]] 08:14, 28 June 2010 (UTC) | ||
Revision as of 10:14, 28 June 2010
| Description: | all modes (except 'userformat') produce invalid code |
| Extension / Version: | DPL / 1.8.9 |
| Type / Status: | Bug / open |
Problem
All modes produce invalid code (except mode='userformat').
Example:
<DPL> category=some_cat mode=unordered randomcount=3 </DPL>
produces:
- <html><a href="/wikiname/index.php/Article1" title="Article1">Article1</a></html>
- <html><a href="/wikiname/index.php/Article2" title="Article2">Article2</a></html>
- <html><a href="/wikiname/index.php/Article3" title="Article3">Article3</a></html>
instead of:
Example in our wiki: DPLbug --Nachteule 09:15, 20 February 2010 (UTC)
Reply
Obviously MW is undergoing another change in its internal structure. I am afraid DPL will have to be changed accordingly. Right now I do not have time for investigations. It would be very helpful if somebody could give details on the nature of change and the consequences for extensions like DPL which use MW interfaces.
I may be able to get DPL running on the latest stable version of MW if somebody could provide details on what the change is and how to cope with it. Last time when something like this happened it was quite a painful process ....
And probably there will be another version incompatibilty - meaning that the modified DPL version will not run on MW versions below 1.16....
The effect you found might be caused by a difference in handling commands which allow "raw HTML".
Gero 23:31, 20 February 2010 (UTC)
- The change in revision 61905 is the reason for this "bug"
- Comment was: "Remove <a> tag hook for now, pending resolution of implementation issues as discussed on CR r58717." --Nachteule 13:35, 22 February 2010 (UTC)
The reason is: Since MW-1.16 there is no tag hook for <html> in the list of hooks if $wgRawHtml is false. See includes/parser/CoreTagHooks.php in function register (the first one). !!!Don't set $wgRawHtml=true in an environment where everyone can edit pages, because this is a security hole!!!
(Version of 2009-10-01:) In DPLMain.php line 27 - in the very, very, very long (over 3000 lines) function dynamicPageList - you set $wgRawHtml to true, which affects only new parsers (after a method of the Parser class calls clearState(), which calls firstCallInit(), which calls CoreParserFunctions::register()). And in line 2472 you again set $wgRawHtml to true. The $localParser has the <html>-Hook, but it's seems to be used only for some minor parse things, definitively not for the main result. So the result contains sometimes some <html>-</html> but no parser resolves this. In DPLSetup.php in function dplParserFunction() I added between the version_compare 1.12.0 and the last return statement:
if ( version_compare( $wgVersion, '1.16' ) > 0 ) {
$p = new Parser();
$p->setHook('html', array($parser->mTagHooks['pre'], 'html'));
$parsed = $p->parse($dplresult, $parser->mTitle, $parser->mOptions);
return array(substr($parsed->mText, 0, strrpos($parsed->mText, '<!--')), 'noparse' => false, 'isHTML' => true);
}
This dirty hack will now resolve the <html> parts in the returned result, but not in every case. I.e. DPL_Example_019 will not work, because the [[Image:...]] will not be resolved. Maybe a better solution would be to find a way to avoid the <html> in general. --Dedlfix 08:14, 28 June 2010 (UTC)
