Jump to:

1149 Posts in 2553 Topics by 408 members

Upgrading SilverStripe

SilverStripe Forums » Upgrading SilverStripe » Upgrading to 2.4.1 results in 
 in HTML code

Ask questions about upgrading SilverStripe to the latest version.

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

Page: 1 2
Go to End
Author Topic: 2692 Views
  • cyberde
    Avatar
    Community Member
    10 Posts

    Upgrading to 2.4.1 results in 
 in HTML code Link to this post

    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!

  • filip667
    Avatar
    Community Member
    10 Posts

    Re: Upgrading to 2.4.1 results in &#13; in HTML code Link to this post

    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!

  • cyberde
    Avatar
    Community Member
    10 Posts

    Re: Upgrading to 2.4.1 results in &#13; in HTML code Link to this post

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

  • cyberde
    Avatar
    Community Member
    10 Posts

    Re: Upgrading to 2.4.1 results in &#13; in HTML code Link to this post

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

  • cake
    Avatar
    Community Member
    19 Posts

    Re: Upgrading to 2.4.1 results in &#13; in HTML code Link to this post

    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.

  • chadws
    Avatar
    Community Member
    9 Posts

    Re: Upgrading to 2.4.1 results in &#13; in HTML code Link to this post

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

  • cyberde
    Avatar
    Community Member
    10 Posts

    Re: Upgrading to 2.4.1 results in &#13; in HTML code Link to this post

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

  • Marcus
    Avatar
    Administrator
    86 Posts

    Re: Upgrading to 2.4.1 results in &#13; in HTML code Link to this post

    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.

    2692 Views
Page: 1 2
Go to Top

Want to know more about the company that brought you SilverStripe? Then check out SilverStripe.com

Comments on this website? Please give feedback.