Search

Hmmm, there seems to be a strange “blank page phenomenon” in Sympohy 2.1.2 - see this bug.

Now I’m not liking the HTML5 Doctype extension hack. Unfortunately, it turns Symphony errors into blank pages. While you’re developing, disable the extension.

Can you elaborate? What URL is showing up blank?

This is on my localhost, with the php.ini set to display errors:

 display_errors = On

Normally, the following error would display if I have not properly defined a character entity:

XSLTProcessor::importStylesheet(): /Users/stephen/Sites/domain7/team/workspace/pages/resources.xsl:17: parser error : Entity 'rsquo' not defined

The full output would be something like this:

<!DOCTYPE html>
<html xml:lang="en">
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
        <title>Symphony &ndash; XSLT Processing Error</title>
        <link rel="stylesheet" type="text/css" media="screen" href="http://home/domain7/team/symphony/assets/error.css">
    </head>
    <body>
        <div id="description">
            <h1>XSLT Processing Error</h1>
            <p>This page could not be rendered due to the following XSLT processing errors.</p>
        </div>
        <ul id="details">
            <li>
                <h2>General</h2>
                <dl>
                    <dt><a href="?debug" title="Show debug view">Compile</a></dt>
                    <dd>XSLTProcessor::importStylesheet(): /Users/stephen/Sites/domain7/team/workspace/pages/resources.xsl:17: parser error : Entity 'rsquo' not defined</dd>
                    <dd>XSLTProcessor::importStylesheet(): l combination. As always, with great power comes great responsibility. It&rsquo;</dd>
                    <dd>XSLTProcessor::importStylesheet():                                                                                ^</dd>
                    <dd>XSLTProcessor::importStylesheet(): compilation error: file /Users/stephen/Sites/domain7/team/ line 3 element import</dd>
                    <dd>XSLTProcessor::importStylesheet(): xsl:import : unable to load /Users/stephen/Sites/domain7/team/workspace/pages/resources.xsl</dd>
                    <dd>XSLTProcessor::transformToXml(): No stylesheet associated to this object</dd>
                </dl>
            </li>
        </ul>
    </body>
</html>

But when I have my fork of the HTML5 Doctype extension enabled, the output contains only the events XML:

<!-- 
<events>
    <member-login-info logged-in="false" />
</events>
 -->

So, it seems the extension maybe hijacking the output of Symphony errors.

I haven’t tried it, but just spotted this as an alternative.

Thanks, Nick. That does look interesting.

New to the system, but excited about the possibilities here. After reading this whole thread though I am confused. Is there a preferred method for handling the HTML5 doctype in XSLT? Do most use the Hack or @nickdunn’s alternative with the text doctype? What is the recommended way?

Unfortunately, it seems like the answer is: it depends.

The HTML5 Master Stylesheet seems like the preferred approach unless you need to support XML namespaces, which is why nickdunn created the HTML5 string parsing hack.

I just really wanted my output to be indented, so I pursued the hack method. For now, I’m just using indented XHTML output while I develop, with the option of turning the hack back on when I feel like displaying an HTML5 doctype.

I think for now I will stick with the HTML5 Master Stylesheet. Thank you for the quick reply!

I happened upon this article today where the author suggests a novel solution to getting IE to support HTML5 without the need for a JS shim. To quote:

The solution is actually pretty simple; put the new HTML5 elements in their own namespace. By doing so, Internet Explorer skips checking (and collapsing) the new elements and they display just fine. It’s the same method as styling an XML document with CSS and Internet Explorer displays that just fine, too.

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:html5="http://www.w3.org/1999/xhtml">
    <body>
        <html5:section>...</html5:section>
    </body>
</html>

He mentions that XHTML5 validates, whilst HTML5 does not. How would we produce this namespace via XSLT? And does anyone think this is a dangerous method?

edit: I should add that he mentions using an xml declaration at the top and setting different mime types for non IE browsers, which in hindsight is starting to look a little overcooked.

Configure the server to send application/xhtml+xml to modern browsers and text/html to Internet Explorer, even though it’s considered harmful by some. Internet Explorer won’t display your page otherwise, instead, it would show a file dialog.

@fazal I’ve experimented with namespaced elements some time ago too. It works, but still is a lot more hassle than the JS shim.

http://valuedstandards.com/static/test/html5-ie-noscript.html

I suppose It all depends on the project: for some (most?) client projects it is pretty safe to assume JS support and that it is not too big of a deal that e.g. Layout breaks when JS is not supported.

For me personally: I would shy away ‘going the full-on XHTML way’.

I looked at the HTML5 hack extension, and I think that this is a good way to go. I solved the problems bauhouse had with error pages coming up blank, and additionally prevent parsing attempts for documents which are not XHTML.

https://github.com/michael-e/html5_doctype

I would love to have one “official” version of this extension. @Nick, will you take care for this? Or do you think that this extension is of general interest for Symphony, so we should ask the core team? (Drop me a line if I should send a pull request.)

Sure, send pull requests and I’ll release the extension properly.

What frustrates me is using mode="html" to get the leanest HTML markup (no self-closing <meta>, <br> etc), but losing indenting. So I’ve been playing with adding indenting back with this extension. I’ve not perfected it yet, since parsing HTML5 is a lot harder than XHTML (it’s not XML for a start). But this extension could eventually provide a range of markup manipulations the developer can enable/disable at will.

Why would you like to have HTML output? You would loose the ability to use namespaces. In my eyes XHTML compatible output (self-closing tags etc.) is fine even for HTML5.

Why would you like to have HTML output?

Because I’d like to end up with HTML and not XHTML. Using XHTML-compatible syntax is fine (and valid), but my personal stylistic preference is HTML.

My main argument against pure HTML syntax is that the output is not parseable by an XML parser — I suffered from this too often… :-)

See, it’s ironic, but I specifically go out of my way to have it collapse all my code down to one line. It makes it a pain for someone reading my source (assuming they don’t use Firebug or the WebKit Inspector) but the minor compression helps in page load-times.

It also allows me to output HTML without having to deal with all the little problems you guys are mentioning.

Well, minifying the HTML sure helps a bit in page load-times but this is really nothing (especially when you enable gzip compression in Apache).

All in all I find it annoying that I have to ‘jump through hoops’ just to get the markup I want. I simply want a minimalistic HTML5 Document (HTML syntax) with the ‘mini’ Charset Definition etc. and properly indented markup. The fact that this forces me to use some funky RegEx post-processing bothers me…

I keep coming back to the fact that I’d really like to see my code properly indented. Sure: it might be OCD-ish but “code is poetry” you know :)

Plus: I’ve ran into other issues where script and textarea elements get auto-closed thus breaking the page.

Automatically indenting markup (in PHP) seems difficult: I hear people use utility functions that keep up with a ‘padder-count’ or really try and manually indent their templates/snippets correctly.

I’ve been thinking about indenting the markup by hooking in Tidy etc. but this is a lot of hassle with performance drawbacks.

:(

If all you’re looking for is indenting, you could use Marc Liyanage’s XML Prettyprinter XSLT.

bauhaus: nice, thanks! How exactly would I use this and does it have a negative impact on performance?

Sorry, I spoke without thinking.

I actually have no idea how the XML Prettyprinter XSLT might be used in this context. It requires XML as a source document, so you would need to have already parsed the desired output. Then you would process the result document with XML Prettyprinter.

I believe this would be possible only if you had another page that processed the XML for the source document, then another page would refer to the source document to perform a second transformation with XML Prettyprinter. It doesn’t sound like a very practical solution.

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details