Page MenuHomePhabricator

Forward slashes in arguments break extensions
Closed, ResolvedPublic


Author: j.niesen

The input

<ref name="foo/1">bla</ref>

is not recognized as a tag for Cite.php because of the forward slash in the

Version: 1.6.x
Severity: normal



Event Timeline

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

j.niesen wrote:

Proposed bug fix


j.niesen wrote:

So, what are the valid values for the attributes in extension tags? The only
thing I could find was
which says that the tags are "XML-style" and that "[t]he value strings have
already had HTML character entities decoded for you", which implies that they
can contain more than alphanumeric characters.

Perhaps I shouldn't have used the Cite.php extension. The problem is not there,
but in the parser. In particular, Parser::extractTagsAndAttribs() does not
recognize any tag whose attribute has a value containing a forward slash,
because the regular expression in line 335 does not match such tags. I guess I
should have said this in the bug report, sorry.

It has nothing to do with extension tags, just HTML. Please see the specs, they're
available online.

j.niesen wrote:

I suppose you mean that the value of 'name' attributes must not contain slashes.
I agree, and I concede that my example in the first comment was badly chosen.

However, this does not hold for all attributes. For instance, the value of the
'href' attribute in <a href='...'> may most certainly contain slashes. In the
parser test in the patch, I use

<tag filename='/tmp/bla'></tag>

Here, tag refers to the extension defined in
maintenance/parserTestsParserHook.php . I think that MediaWiki should recognize
this as a parser extension. However, it does not do this, hence the bug report.

I wish you hadn't been so specific about using <ref name> here!

Sorry for the wait! Entirely my fault, I should have read

Applied on trunk at r13539, and REL1_6 at r13540.