@japh – Will do.
I think I have a patch that may work, I need to wrap ALL output in [raw]..[/raw]. That is a horrible way to fix this as it can cause all sorts of odd things to happen on all themes that are NOT using the ThemeForest “special sauce”.
The short less-tech version of this is that ThemeForest is forcing a call to the internal wptexturize() function AFTER shortcodes are rendered. That is NOT how that function is supposed to be used. That WordPress function has a specific filter that says “please do not process my shortcode with texturizing”.
What that means is if I write code like this:
[ Moderator Note: Please post code or markup snippets between backticks or use the code button. Or just think “The Code Button is Your Friend and should be respected and used.” ]
<table
cellpadding="2"
style="display:none"
>
I can tell WordPress “leave this alone, it is not standard post content”. If I do not do that then WordPress changes the HTML to this, which is WRONG:
<tablecellpadding="2"style="display:none">
It adds in HTML codes where I had soft returns in my HTML code. I added that in a LOT Of places for readability, which is why 3.6.1 “suddenly broke”.
<rant>
However simply adding a soft return in my HTML to make it more readable should NOT break anything. That is not the function of a theme and is not for a theme to decide. I told WordPress “hey, don’t format this stuff, it is code”.
ThemeForest has a “special sauce” function that many theme developers use that is called AFTER shortcodes are rendered. Thus it completely ignores my “please don’t format this instruction”.
In short, Theme Forest themes are saying “SCREW YOU PLUGIN DEVELOPER, I’ll format this anyway”. That sucks.
Now I need to add a “I’m using ThemeForest or another wonky theme” setting that wraps my clean HTML in [raw]…[/raw] tags, which is NOT valid HTML nor valid WordPress code. It is “don’t let ThemeForest break my code” code. At the very least they should provide and DOCUMENT a filter that allows people to tell that function “please don’t touch this”. Even smarter… re-process the shortcode and script fitlers that are standard WordPress fodor. Even smart still… do NOT re-texturize content AFTER the shortcodes and scripts are rendered, since WordPress clearly does not expect nor want you to do this.
</rant>
Enough with the rant. I know what is breaking, why it breaks, and how to get around the shortcomings of the themes. Now I need to come up with a creative way to provide an easy end-user fix without breaking 10,000 other installations that are working right now. That is going to take a week or so.
Back to vacation… I have a beer to finish and family to take to the theme parks in the morning. 🙂
