xmlsyntax error with entities on Plone template pages like the search page

[Jan Murre]

Using collective.xdv with Plone 4.0b5 generates errors on Plone template pages like 'search'.

Traceback is below.

The rules_parser that is passed in into 'compile_theme' has two resolvers, the InternalResolver and the PythonResolver.
When the 'rules.xml' does not start with a slash, a request is created that should generate a NotFound exception.

However, with the Plone search template this is not the case. The contents of the Plone search page is in the response, containing an —. This is fed into the xml parser further on, generating the XMLSyntaxError (see code in collective.xdv.utils.InternalResolver).

Workaround is to use the python resolver, luckily it comes before the InternalResolver.
Another workaround is using an absolute filesystem url like:

file:///full/path/to/your/file

It would be nice to introduce something like:

file://relative/path/to/buildout-dir

Traceback (most recent call last):
  File "/home/jan/.buildout/eggs/plone.transformchain-1.0b1-py2.6.egg/plone/transformchain/transformer.py", line 42, in __call__
    newResult = handler.transformIterable(result, encoding)
  File "/home/jan/.buildout/eggs/collective.xdv-1.0rc9-py2.6.egg/collective/xdv/transform.py", line 263, in transformIterable
    transform = self.setupTransform()
  File "/home/jan/.buildout/eggs/collective.xdv-1.0rc9-py2.6.egg/collective/xdv/transform.py", line 221, in setupTransform
    access_control=access_control,
  File "/home/jan/.buildout/eggs/xdv-0.3-py2.6.egg/xdv/compiler.py", line 120, in compile_theme
    rules_doc = etree.parse(rules, parser=rules_parser)
  File "lxml.etree.pyx", line 2706, in lxml.etree.parse (src/lxml/lxml.etree.c:49945)
  File "parser.pxi", line 1500, in lxml.etree._parseDocument (src/lxml/lxml.etree.c:71784)
  File "parser.pxi", line 1529, in lxml.etree._parseDocumentFromURL (src/lxml/lxml.etree.c:72067)
  File "parser.pxi", line 1429, in lxml.etree._parseDocFromFile (src/lxml/lxml.etree.c:71162)
  File "parser.pxi", line 975, in lxml.etree._BaseParser._parseDocFromFile (src/lxml/lxml.etree.c:68160)
  File "parser.pxi", line 539, in lxml.etree._ParserContext._handleParseResultDoc (src/lxml/lxml.etree.c:64244)
  File "parser.pxi", line 625, in lxml.etree._handleParseResult (src/lxml/lxml.etree.c:65165)
  File "parser.pxi", line 565, in lxml.etree._raiseParseError (src/lxml/lxml.etree.c:64508)
XMLSyntaxError: Entity 'mdash' not defined, line 287, column 20
> /home/jan/zope/knmp.nl/parser.pxi(565)lxml.etree._raiseParseError (src/lxml/lxml.etree.c:64508)()

[Laurence Rowe (lrowe)]

Can you check this with the current trunk, I think Marshall may have
fixed this the other day.

Laurence

On 9 August 2010 20:54, Jan Murre <email address hidden> wrote:
> Public bug reported:
>
> Using collective.xdv with Plone 4.0b5 generates errors on Plone template
> pages like 'search'.
>
> Traceback is below.
>
> The rules_parser that is passed in into 'compile_theme' has two resolvers, the InternalResolver and the PythonResolver.
> When the 'rules.xml' does not start with a slash, a request is created that should generate a NotFound exception.
>
> However, with the Plone search template this is not the case. The
> contents of the Plone search page is in the response, containing an
> &mdash;. This is fed into the xml parser further on, generating the
> XMLSyntaxError (see code in collective.xdv.utils.InternalResolver).
>
> Workaround is to use the python resolver, luckily it comes before the InternalResolver.
> Another workaround is using an absolute filesystem url  like:
>
> file:///full/path/to/your/file
>
> It would be nice to introduce something like:
>
> file://relative/path/to/buildout-dir
>
>
> Traceback (most recent call last):
>  File "/home/jan/.buildout/eggs/plone.transformchain-1.0b1-py2.6.egg/plone/transformchain/transformer.py", line 42, in __call__
>    newResult = handler.transformIterable(result, encoding)
>  File "/home/jan/.buildout/eggs/collective.xdv-1.0rc9-py2.6.egg/collective/xdv/transform.py", line 263, in transformIterable
>    transform = self.setupTransform()
>  File "/home/jan/.buildout/eggs/collective.xdv-1.0rc9-py2.6.egg/collective/xdv/transform.py", line 221, in setupTransform
>    access_control=access_control,
>  File "/home/jan/.buildout/eggs/xdv-0.3-py2.6.egg/xdv/compiler.py", line 120, in compile_theme
>    rules_doc = etree.parse(rules, parser=rules_parser)
>  File "lxml.etree.pyx", line 2706, in lxml.etree.parse (src/lxml/lxml.etree.c:49945)
>  File "parser.pxi", line 1500, in lxml.etree._parseDocument (src/lxml/lxml.etree.c:71784)
>  File "parser.pxi", line 1529, in lxml.etree._parseDocumentFromURL (src/lxml/lxml.etree.c:72067)
>  File "parser.pxi", line 1429, in lxml.etree._parseDocFromFile (src/lxml/lxml.etree.c:71162)
>  File "parser.pxi", line 975, in lxml.etree._BaseParser._parseDocFromFile (src/lxml/lxml.etree.c:68160)
>  File "parser.pxi", line 539, in lxml.etree._ParserContext._handleParseResultDoc (src/lxml/lxml.etree.c:64244)
>  File "parser.pxi", line 625, in lxml.etree._handleParseResult (src/lxml/lxml.etree.c:65165)
>  File "parser.pxi", line 565, in lxml.etree._raiseParseError (src/lxml/lxml.etree.c:64508)
> XMLSyntaxError: Entity 'mdash' not defined, line 287, column 20
>> /home/jan/zope/knmp.nl/parser.pxi(565)lxml.etree._raiseParseError (src/lxml/lxml.etree.c:64508)()
>
> ** Affects: xdv
>     Importance: Undecided
>         Status: New
>
> --
> xmlsyntax error with entities on Plone template pages like the search page
> https://bugs.launchpad.net/bugs/615530
> You received this bug notification because you are a member of xdv
> maintainers, which is the registrant for xdv.
>

[Jan Murre (jan-murre-gmail)]

Just checked, but the bug is still there.

[Laurence Rowe (lrowe)]

OK, I think I understand this now. Zope has no concept of the buildout directory, so it is not possible to use that for the relative path. I think the correct thing to do here is to prevent rules or theme being set to relative paths. They should either be full urls or absolute paths (which are resolved internally relative to the portal).