Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

Upgrading SilverStripe /

Ask questions about upgrading SilverStripe to the latest version.

Moderators: martimiz, Sean, biapar, Willr, Ingo, swaiba, simon_w

Upgrading to 2.4.1 results in 
 in HTML code


Go to End
Reply


10 Posts   2875 Views

Avatar
cyberde

Community Member, 10 Posts

18 August 2010 at 1:08am

Hi,

I noticed that after upgrading to 2.4.1 and editing an article suddenly every linebreak has a 
 so that the code is not XHTML Strict nor Transitional anymore:

Line 109, Column 37: character data is not allowed here
<ul><li>Runs on your phone!</li>&#13;?
You have used character data somewhere it is not permitted to appear. Mistakes that can cause this error include:

•putting text directly in the body of the document without wrapping it in a container element (such as a <p>aragraph</p>), or
•forgetting to quote an attribute value (where characters such as "%" and "/" are common, but cannot appear without surrounding quotes), or
•using XHTML-style self-closing tags (such as <meta ... />) in HTML 4.01 or earlier. To fix, remove the extra slash ('/') character. For more information about the reasons for this, see Empty elements in SGML, HTML, XML, and XHTML.

Anyone else having this issue?

Cheers!

Avatar
filip667

Community Member, 10 Posts

20 August 2010 at 1:58am

yep, i've got the same problem mate, updating doesnt have nothing to do with it as i used the new 2.4.1 version. what worse it doesnt validate the website as that character is not allowed there http://validator.w3.org.
interestingly when you edit HTML code as admin in SS CMS, the &#13 character doesnt appear there!

Avatar
cyberde

Community Member, 10 Posts

20 August 2010 at 2:01am

Edited: 20/08/2010 2:07am

Exactly, I also thought to edit the &#13; out using the HTML source but they didn't show up...

To make things even more weird, I just created a new page and the "&#13;" stuff doesn't show up there?!

[edit]
Nevermind, I just checked the result HTML and it does show up there. Yet another page that doesn't validate now. Articles created with 2.4 don't have this issue untill I edit them.

[edit2]
SilverStripe saves the pages with the &#13; to the database, so editing that record using phpMyAdmin fixes it untill you edit the page using SilverStripe again...

Avatar
cyberde

Community Member, 10 Posts

3 September 2010 at 4:48am

Edited: 03/09/2010 4:51am

Any news on this one?
It appears to be happening after every </li> element.

Avatar
cake

Community Member, 19 Posts

16 September 2010 at 2:43am

In my case it appears after each linebreak (not HTML, just the carriage return!).

This only happens if I use DOM and a Popup to edit a DataObject.

You can workaround this if you create a Textarea for the editable field:

function getCMSFields() {
$fields = parent::getCMSFields();
      $fields->addFieldToTab("Root.Main", new TextareaField("Content", "Content"));
      return $fields;
   }

I think this only occurs if you use the HTMLText data type.

Avatar
chadws

Community Member, 9 Posts

28 September 2010 at 10:06am

Are you by chance switching between a mac and windows or are you always on one platform?

Avatar
cyberde

Community Member, 10 Posts

29 September 2010 at 3:41pm

Nope, just updating the silverstripe installation on my linux webserver...

Avatar
Marcus

Administrator, 86 Posts

7 October 2010 at 7:37am

Edited: 07/10/2010 7:40am

So I've just spent a couple of hours tracking down why this happens (google's not much help because it just interprets &#13; as a carriage return... smart google). I've found what causes it, but not why it happens. In short, when you save any content that is of type HTMLText, it gets examined for link integrity. To help with the messy XML work needed, SilverStripe passes the content into a DOMDocument, does the DOM manipulations needed, then gets the content back out. What's happening though is that carriage return characters (\r) are being converted into their unicode equivalents at some point of the process, coming back as the dreaded &#13;

So why does this happen? As you might know, *nix systems represent their newlines as "\n", whereas windows systems use "\r\n". So DOMDocument processing on your Linux server expects newlines to be "\n" delimited, and converts the trailing "\r" to its entity equivalent. Why it happens on some content areas and not others though is a complete mystery to me at the moment. Content fields in the backend work without a problem, because for whatever reason they return "\n" newline characters, but switching to frontend content fields (eg in the blog module) start sending back "\r\n" characters when posting/editing via the frontend.

Even stranger, I'm actually on a linux system, so in theory I should be always sending "\n" as my newlines; however, in both Firefox and Chrome, it's sending "\r\n". I'm stumped at the moment as to what's introducing the "\r" in there.

Anyway - for the quick fix I've put in place as I continue trying to track down the real problem, you can try adding something like

In sapphire/integration/HTMLValue.php at ~line 48 (the setContent method)

   public function setContent($content) {
      if (PHP_EOL == "\n") {
         $content = str_replace("\r\n", PHP_EOL, $content);
      }
      return @$this->getDocument()->loadHTML(
         '<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head>' .
         "<body>$content</body></html>"
      );
   }

This basically checks to see whether we're running on a system expecting "\n" as the line feed, and forcibly replaces any "\r\n" characters.

Hope that helps a bit - it'd be great if someone knew WHY "\r\n" was forcing its way in though.

Go to Top