Page MenuHomePhabricator

Dynamic page Links broken
Closed, ResolvedPublic

Description

In revision r63067 DynamicPageList extention displays all web links without pointing to them

By example I read in a wikipage !

  • <html><a href="/wiki/index.php/D%C3%A9cret_n%C2%B0_2006-1657_du_21_d%C3%A9cembre_2006" title="Décret n° 2006-1657 du 21 décembre 2006">Décret n° 2006-1657 du 21 décembre 2006</a></html>
  • <html><a href="/wiki/index.php/D%C3%A9cret_n%C2%B0_2006-1658_du_21_d%C3%A9cembre_2006" title="Décret n° 2006-1658 du 21 décembre 2006">Décret n° 2006-1658 du 21 décembre 2006</a></html>

Version: unspecified
Severity: major

Details

Reference
bz22675

Event Timeline

bzimport raised the priority of this task from to High.Nov 21 2014, 11:09 PM
bzimport set Reference to bz22675.
bzimport added a subscriber: Unknown Object (MLST).

I cannot reproduce this. Can you give me the wikicode that generated this?

source code:

<includeonly><DPL>
debug=1
ordermethod=lastedit
category=Arrêts et jugements
count=10
addeditdate=true
order=descending
</DPL></includeonly>
<noinclude><DPL>
debug=1
ordermethod=title
category=Arrêts et jugements
order=ascending
mode=ordered
</DPL></noinclude>

Thats a different extension. (DyanmicPageList on bugzilla refers to the version used by wikimedia - the one's using <DynamicPageList> tags. the extension using <DPL> tags is referred to as DynamicPageList2 on bugzilla.

Moving component

It appears to be linked to calling $parser->recursiveTagParse() (Parser.php) from ExtDynamicPageList::executeTag() (DPLSetup.php). Going in, it appears to be a mix of HTML and templates that needs parsing. The returned text now has <html> tags around it and is in escaped format.

If you set $wgRawHtml = true;, the problem goes away. (Obviously this is not a good workaround.)

carlb613 wrote:

I've been able to replicate the same issue with DynamicPageList as of MediaWiki 1.17alpha (http://toolserver.org/~vvv/mw-nightly/ Dumped on: 12:13, 20 June 2010 Subversion revision: r68310). I downloaded both the core code and extensions.

The "third party" DynamicPageList in MediaWiki SVN had been working quite well under MediaWiki 1.16 and today is now broken on "upgrade" to 1.17 alpha:

DynamicPageList (Versão 1.8.6) A highly flexible report generator for MediaWikis - manual and examples: see [1] Gero Scholz

Últimas notícias:

  • 2010-06-20: <html><a href="/wiki/Desnot%C3%ADcias:Faltou_gana_para_Gana" title="Desnotícias:Faltou gana para Gana">Faltou gana para Gana</a></html>
  • 2010-06-20: <html><a href="/wiki/Desnot%C3%ADcias:Em_partida_catimbada,_Brasil_vence_jogo_de_capoeira_contra_Costa_do_Marfim" title="Desnotícias:Em partida catimbada, Brasil vence jogo de capoeira contra Costa do Marfim">Em partida catimbada, Brasil vence jogo de capoeira contra Costa do Marfim</a></html>

[...]

The Wikimedia-style "intersection" still works - aka:

DynamicPageList (r55550) constrói uma lista pontuada dos itens mais recentes presentes numa categoria, ou uma união de várias categorias Amgine e IlyaHaykinson

Últimas notícias:

  • 20 de junho de 2010: Faltou gana para Gana
  • 20 de junho de 2010: Em partida catimbada, Brasil vence jogo de capoeira contra Costa do Marfim

I've changed http://notici.as and other sites on the same servers to use the less-powerful "intersection" version until a proper fix is available but otherwise haven't tried changing anything in the configuration files from what was a properly-working MW 1.16 configuration.

Created attachment 7536
Patch that fixes <html> issue - however this entire thing is insecure...

I found what was wrong. DPL was using <html> in a rather hacky (and somewhat insecure way). When mediawiki changed how it handled <html> in r61913, the hack this extension used broke.

the attached patch fixes the issue as far as I can tell. However, not only is the approach this extension takes to raw html utterly scary, it is also insecure. (This patch doesn't add any new security issues, but i feel hesitant contributing a fix to the mechinism, which in my opinion is insecure until the underlying security problems have been addressed)

Attached:

fixed in r68812

I also fixed some of the obvious security issues in r68811 however this extension still scares me somewhat.

morgon.kanter wrote:

This is still not fixed. Strangely it works just fine for #dpl, but when using &lt;dpl&gt; you encounter the same bug.

Using the latest release of DPL, with r68812, we have the following two pages:

This is really weird because it appears to me that the fix wasn't dependent on a tag-vs-parser conditional.

morgon.kanter wrote:

Apologies for the previous reopen, seems to be a results cache issue. Anyone else having this problem, try waiting 24 hours.