That’s becasue it changes the order of wpautop and/or other parsing and filtering functions, what causes the output of EasyRotator shortcode to be mangled and one comment tag is changed to html entity, which causes havoc.
The short discussion which lead to this discovery is here: http://www.dwuser.com/forums/viewtopic.php?f=11&t=1947&sid=4f66a28fe7a72983809a6eb0d5b7b96c
Any ideas how to fix it, or workaround it? Please help!
EDIT: ahhh, the forum post is visible to registered users only. Ok, so copy paste:
I said: “It’s in the middle fragment, which should be the end of comment (–>), however somehow got translated into entity. This could be because of wpautop (or other text processing stuff), however I disabled it and no change. When changing the entity to comment end, it displays as it should.
I’m trying to understand what happened, and apart from installing CMS like plugins no big things chagned. Perhaps it was always like that, only I didn’t notice broken footer.
I’m using WordPress 3.3.1 and latest EasyRotator. Any ideas on how to fix it?”
The shredded rotator code you’re showing results when WordPress’s default behavior is changed such that wpautop is being run after the EasyRotator shortcode is parsed. The usual culprit is some other plugin — for example, Shortcodes Ultimate. The 1.0.1 update to the plugin includes compatibility for Shortcodes Ultimate, so it is most likely a different plugin in your case.
First, try wrapping the EasyRotator shortcode in [raw]…[/raw]. If that doesn’t fix the problem, I recommend you try disabling plugins one by one until you identify the problematic plugin. Please share here what you find.
I replied: “Spot on!
I got it, it’s the Developer Formatter: http://wordpress.org/extend/plugins/devformatter/
It’s pretty useful, from my experience the only code formatting plugin in WP worth using (but I have high standards 😉 so would be nice if either of the pair would learn how to cooperate with the other.
Oh, and the [raw] tags do nothing, they’re just displayed as is. Perhaps another plugin is needed for them? Untill the situation is fixed, using [raw] could be a good workaround for the problem (if I understood that would prevent the EasyRotator code from being processed by wpautop).
I just browsed the plugin’s source code, and it doesn’t appear that there are any easy “skip” codes that cause code to be ignored. I can’t guarantee that I didn’t miss it, though, as the code’s a little less than well-organized.
The best solution would be for the plugin author to add a special code (like [raw][/raw]) that causes code to be skipped. Another solution would be for you to manually edit the plugin to do this.
Or, you could create a special plugin that forces the EasyRotator shortcode to be executed later (see: http://www.viper007bond.com/2009/11/22/wordpress-code-earlier-shortcodes/ …you would use a higher priority value instead of lower).
I don’t want to mess with such things, hopefully the author of DevFormatter can quickly spot where’s the problem and create a fix or workaround.
- The topic ‘[Plugin: Developer Formatter] DevFormatter breaks EasyRotator plugin’ is closed to new replies.