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!

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!

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...

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

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.

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

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

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.