Compare to Current with <style> tags issue
We're running into a problem with the Compare to Current functionality. In each WYSIWYG, we give the ability for the content manager to directly edit the HTML. A few of the more enterprising editors have started using style tags inside the HTML as a way to format their individual areas. Doing this, there is no display problem in either the Current or Previous Version views. However, when they do Compare to Current, nothing appears on the screen below where the style tags in the code are placed.
Looking at the source for the page, everything fails after this: <style type="text/css"/> The browser sees it as a non-void element, removes the slash and all the issues go to town. It may be because the WYSIWYG editor is insistent upon putting HTML Comment tags immediately after the style tag and right before the closing tag.
Is there a way for us to be able to turn off the HTML Comment tags or configure the system not to have the XML Parser reduce the style tag to self-closing? Thanks.
Discussions are closed to public comments.
If you need help with Cascade CMS please
start a new discussion.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
1 Posted by Ryan Griffith on 11 Sep, 2015 01:41 PM
Hi Jason,
The self-closing
<style>tag behavior you are running into is due to a process used during XML serialization that expands specific tags. Specifically, there is a configuration file that determines what tags should be left expanded; otherwise, the tag will be converted to a self-closing tag. This is because XML has no notion of HTML tags that are not meant to be self-closing.We have a known defect logged for this behavior. Feel free to use this link to track the progress of this issue or keep an eye out for it on our Release Notes site.
Unfortunately, there is nothing you could do from within Cascade to change this other than perhaps trying to surround the
<style>tag with a#protectcode section, to see if the serialization leaves it. I'm not 100% sure it will, though.That being said, if you would like a temporary workaround for certain tags, let me know and I can provide you with steps to update the configuration file I mentioned with tags you wish to be left alone and we can see if that helps out. The downside here is these changes would need to be re-added after each upgrade since the file would be overwritten by the update.
Please let me know if you have any questions.
Thanks!
2 Posted by jason.verschage on 11 Sep, 2015 02:16 PM
Greetings Ryan,
Yes, the instructions would be highly useful, even if they would need to be redone during an upgrade. There aren't many content editors adding in style tags, but the ones that are tend to edit a large number of pages and across multiple sites. In addition, Compare to Current has become essential in our workflows as our content checkers can focus specifically on the areas where changes occur. Previously they had to switch back and forth between Current and Working Copy or snag the HTML of the two and run it through WinMerge.
Cheers,
Jason Verschage
________________________________
3 Posted by Ryan Griffith on 11 Sep, 2015 05:12 PM
Sounds good, Jason, definitely worth a shot.
tomcat/webapps/ROOT/WEB-INF/classes/com/hannonhill/cascade/xml/output/expanded-elements.xmlstyletag:Note: as I mentioned, these steps will need to be re-applied after any update because this file is replaced during the upgrade.
Please let me know if you have any questions.
Thanks!
4 Posted by Ryan Griffith on 24 Sep, 2015 12:40 PM
Hi Jason,
Just wanted to follow up to see if you had a chance to view my recent comment. If you were able to follow the steps, did they resolve the issue you were encountering?
Please let us know if you have any questions.
Thanks.
5 Posted by jason.verschage on 24 Sep, 2015 01:05 PM
Apologies for not responding sooner.
We did update our test server by making the configuration update. The good news is that It no longer collapses the style to a single tag, so the page doesn't break. However, on Compare to Current, the style seems to be removed completely. So, if the only thing changed by a content editor is the style, there's no indication on the page. We haven't yet met with Web Team Management to discuss moving the change to production and if the partial solution is satisfactory, but at the very least standard content changes are viewable.
Cheers,
Jason
________________________________
6 Posted by Ryan Griffith on 05 Oct, 2015 12:27 PM
Hi Jason,
Just wanted to follow up to see if you had a chance to speak with your team to discuss whether the fix will suffice. Curious, but if you scope out the source code of the comparison, does the
<style>tag contain any additional markup?Please let me know if you have any questions.
Thanks!
Ryan Griffith closed this discussion on 02 Nov, 2015 08:07 PM.