Difference between revisions of "Issue:DPL incompatible with MW 1.16 alpha"

From FollowTheScore
Jump to: navigation, search
 
(5 intermediate revisions by 4 users not shown)
Line 60: Line 60:
  
 
:: 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)
 
:: 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)
 +
:::::Just as a note, the version in mediawiki's svn doesn't have this bug (mostly because the people on irc were whiny about it). It still enables raw html which has the obvious XSS vulnrability. [[User:Bawolff|Bawolff]] 01:18, 20 October 2010 (UTC)
 +
----
 +
Another approach is to add
 +
  format=,\n*<nowiki>[[%PAGE%|%TITLE%]]</nowiki>
 +
to the dpl-wikitext --[[User:Bescheid|Bescheid]] 22:00, 8 May 2011 (CEST)
 +
 +
:Right, this is a simple work around. Please note that the DPL version which is running in this wiki here DOES NO LONGER USE raw html. [[User:Gero|Gero]] 01:23, 9 May 2011 (CEST)

Latest revision as of 00:23, 9 May 2011

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)

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. 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. :-) Thanks. Maiden taiwan 13:37, 13 October 2010 (UTC)
A friend pointed out that DPL might be able to eliminate the whole <html> hack if you use $parser->insertStripItem() to handle the raw HTML instead. See this article on tag extensions and this article on parser functions, both by MediaWiki contributor Jim Wilson. 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 ... Gero 15:43, 16 October 2010 (UTC)
Just as a note, the version in mediawiki's svn doesn't have this bug (mostly because the people on irc were whiny about it). It still enables raw html which has the obvious XSS vulnrability. Bawolff 01:18, 20 October 2010 (UTC)

Another approach is to add 

 format=,\n*[[%PAGE%|%TITLE%]]

to the dpl-wikitext --Bescheid 22:00, 8 May 2011 (CEST)

Right, this is a simple work around. Please note that the DPL version which is running in this wiki here DOES NO LONGER USE raw html. Gero 01:23, 9 May 2011 (CEST)
Retrieved from "http://followthescore.org/dpldemo/index.php?title=Issue:DPL_incompatible_with_MW_1.16_alpha&oldid=15312"