Serge,

Thanks for reporting this. We'll look into it for sure. I agree that the code view could use some help. 

Regarding the <div> -- that's how SmarterTrack enforces the Brand's default font. A potential workaround would be to set the Brand's default font to whatever "theme assigned" font you're using. Just realize that this font would be used throughout SmarterTrack for that Brand, including in your replies, KB articles, etc. 

Hi Derek,

Thanks for looking into this.

And for explaining the reason for the <div>. 

Our designers would argue that is not the best way to "enforce" the brand's default font since that font can change over time and now you have the old default font hardcoded into the old content and the new content showing up with the new hardcoded font selection.

Wouldn't it be better to use that <div> to wrap the post/reply/article content when it is rendered onto the page and instead of forcing it when editing and saving as part of the content? In this case, whenever the brand's default font selection changes, both new and existing content are rendered in that new font selection?

I have never seen the Default Font within the Brand, I went to reset it to not forcing any font found that is not possible currently - I can only select from your predefined list. Not very helpful - you list the handful of "classic" (read - old) font options while in the modern theme design it not that uncommon to use modern and custom fonts. 

Just FYI.

Thanks again!

This fix is in the latest release of SmarterTrack. Code formatting is much cleaner!

Thanks, Derek! 

Installed the update and the source code formatting is beautiful.

Derek,

There is a side effect of the new source viewer - it messes up the <pre/> block content. 

Steps to reproduce: open a post with <pre/> in it, switching to source view removes the CRLFs within and turns the <pre/> content into one long line.

Thanks!