1053 Posts in 383 Topics by 376 members
| Go to End | Next > | |
| Author | Topic: | 2268 Views |
-
Upgrading to 2.4.1 results in in HTML code
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> ?
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!
-
Re: Upgrading to 2.4.1 results in in HTML code
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 
 character doesnt appear there! -
Re: Upgrading to 2.4.1 results in in HTML code
20 August 2010 at 2:01am Last edited: 20 August 2010 2:07am
Exactly, I also thought to edit the 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 " " 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 to the database, so editing that record using phpMyAdmin fixes it untill you edit the page using SilverStripe again... -
Re: Upgrading to 2.4.1 results in in HTML code
3 September 2010 at 4:48am Last edited: 3 September 2010 4:51am
Any news on this one?
It appears to be happening after every </li> element. -
Re: Upgrading to 2.4.1 results in in HTML code
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.
-
Re: Upgrading to 2.4.1 results in in HTML code
28 September 2010 at 10:06am
Are you by chance switching between a mac and windows or are you always on one platform?
-
Re: Upgrading to 2.4.1 results in in HTML code
29 September 2010 at 3:41pm
Nope, just updating the silverstripe installation on my linux webserver...
-
Re: Upgrading to 2.4.1 results in in HTML code
7 October 2010 at 7:37am Last edited: 7 October 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 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
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.
| 2268 Views | ||
| Go to Top | Next > |
