View source for Issue:DPL incompatible with MW 1.16 alpha

{{Issue
 |Type        = Bug
 |Extension   = DPL
 |Version     = 1.8.9
 |Description = all modes (except 'userformat') produce invalid code
 |Status      = open
}}

== Problem ==
All modes produce invalid code (except mode='userformat').

Example:
<pre><nowiki><DPL>
  category=some_cat
  mode=unordered
  randomcount=3
</DPL></nowiki></pre>

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:

* [[Article1]]
* [[Article2]]
* [[Article3]]

Example in our wiki: [http://kamelopedia.mormo.org/index.php/Kamel:Nachteule/DPLbug DPLbug] --[[User:Nachteule|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".
 
[[User:Gero|Gero]] 23:31, 20 February 2010 (UTC)

:[http://svn.wikimedia.org/viewvc/mediawiki?view=rev&sortby=date&revision=61905 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 [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>&lt;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>&lt;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>&lt;html>-&lt;/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 &lt;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 &lt;html> in general. --[[User:Dedlfix|Dedlfix]] 08:14, 28 June 2010 (UTC)

:: Thank you for finding this out. As you may have noticed I am not actively developing DPL at the moment. By the end of the year I will have more time. Unless somebody wants to restructure the code (volunteers welcome!) I will have to use some time to break up those huge functions before development can go on. I will come back to all hints and findings that come up until then. [[User:Gero|Gero]] 21:26, 30 June 2010 (UTC)

::: Gero, is there any chance this bug can be addressed soon? It's blocking adoption of MW 1.16 at our site, as we depend heavily on DPL. (We tried the above workaround but it had no effect on our site with the official 1.16 release.) I know you're busy with other things, but this is a fatal problem that completely prevents DPL from working. I am willing to bribe you with chocolate. <code>:-)</code> Thanks. [[User:Maiden taiwan|Maiden taiwan]] 13:37, 13 October 2010 (UTC)

::: A friend pointed out that DPL might be able to eliminate the whole <code><nowiki><html></nowiki></code> hack if you use <code>$parser->insertStripItem()</code> to handle the raw HTML instead. See [http://jimbojw.com/wiki/index.php?title=Raw_HTML_Output_from_a_Parser_Extension this article on tag extensions] and [http://jimbojw.com/wiki/index.php?title=Raw_HTML_Output_from_a_MediaWiki_Parser_Function this article on parser functions], both by MediaWiki contributor Jim Wilson. [[User:Maiden taiwan|Maiden taiwan]] 17:30, 13 October 2010 (UTC)

:::: I see your point but currently I m quite busy in my job. Maybe in three or four weeks ... [[User:Gero|Gero]] 15:43, 16 October 2010 (UTC)