Haven't seen this before, not sure if it's due to the way my files are setup, or if it's a change in 2.4.

Normally a special character like … will cause the XSLT engine to fall over. That's fine, I'm used to using the number equivalents. However using … (edited to add that this code is wrong, but not the source of the issue. Second edit: turns out it was the cause of the issue! doh) outputs a blank space (not quite 'nothing', some kind of null character) instead of the expected . This isn't a font issue, as I haven't even attached a stylesheet yet, just default Helvetica. Also tested other characters to make sure it's not something specific to the ellipsis, and it's not.

Any thoughts?

I use … instead of … and that always seems to work (taken from wikipedia's list unicode codepoint references

btw, if you happen to be using Vim I wrote a handy plugin to quickly convert all unicode characters to their named HTML entity equivalents and all HTML entities to their unicode codepoints (i.e. #…) - it makes handling this stuff super quick and easy. It's simply a giant collection of search/replace so should be easy enough to convert to other editors e.g. Sublime etc.

Hi Firegoby,

As mentioned the character itself isn't a problem, so I have the same issue with that code. I've never had this issue before either, quite an odd one!

That looks like a handy resource if you're looking to rebuild an existing site into Symphony!


Ah, sorry I see (should have read more closely!) - I just checked this on a local test install of 2.4 and on mine … outputs the ellipsis but not… - that doesn't output anything here either. Other entities like Greek Beta β also work fine, so not sure if this is a 2.4 issue or not. Perhaps there's some obscure server or PHP config setting that might be affecting it??

Yea that'd be my guess as well, but this is just in MAMP, at work, so I'd have spotted it on another site if that were the case.

I've just checked at home on a different site being built on 2.4 (integration) and it does seem fine, so unlikely a 2.4 thing. - although I can confirm that … doesn't work, I think that's just from a poor reference (quick google), I only remember the named codes :)

I'll have to get that site pulled here later and check to see if it's an odd environment variable!

The correct numeric entity is either … (decimal) or … (Hex).

Yup, was a dodgy reference (I google for the unicodes), although as mentioned that's a red herring :)

Well this is embarrassing. Turns out it was just the dodgy character reference.

Especially annoying as I tested the suggested replacement anyway (along with a couple of other characters, although they were from the same source, so no surprise they didn't work), I must have still had a dodgy reference in my clipboard, or something silly like that.

So, um, yea, if you use incorrect character references the characters won't work! :p


Stop judging me.

He, I wasn't! I was referring to:

if you use incorrect character references the characters won't work!


alt text

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