[wp-hackers] Plugin conflicts with latest version of Jetpack

[Ian Dunn]

Er, my bad. I'll change it to check $post directly. Thanks for the 
detailed explanation.

The reason I'm checking if the shortcode is called is to avoid loading 
CSS and JavaScript files on pages where the shortcode isn't used 
<http://wordpress.stackexchange.com/questions/20854/conditionally-loading-javascript-css-for-shortcodes>. 
I didn't realize that we can use wp_enqueue_script() directly within the 
shortcode callback 
<http://scribu.net/wordpress/conditional-script-loading-revisited.html> 
now, but I originally wrote that method about 6 months before 3.3 came 
out. I could start doing that now for the JavaScript, but the CSS still 
needs to be enqueued inside the head tag, so it wouldn't really save me 
anything.


On 01/01/2013 03:59 PM, Otto wrote:
> Ian, the bug is actually in your plugin, and how you're using shortcodes.
>
> In http://plugins.svn.wordpress.org/basic-google-maps-placemarks/trunk/core.php
> you have a function called mapShortcodeCalled() which says it is
> supposed to "Checks the current posts to see if they contain the map
> shortcode."
>
> However, what it's actually doing is to set up the post data and then
> call get_the_content(). This would be fine if you wanted to get the
> resulting HTML output, because what you're actually doing with that
> call is to have it process the shortcodes.
>
> Instead, you should examine the post->post_content directly to
> determine if the shortcode is contained in it. Although honestly, I'm
> not sure why you'd go to all that trouble. You can enqueue things like
> scripts and such in shortcode functions directly now, they'll get
> included in the footer instead of the header, so you don't need to
> pre-process the content to determine that sort of thing.
>
> But basically, shortcodes and filters need to have a specific
> behaviorism that you're not really adhering to very well, and that is
> this: No side effects. A filter should filter some input in a certain
> way, and do it every time, because it can be called more than once. A
> shortcode is really just a special case of filter, it should take the
> shortcode as input and return the resulting HTML to be put into the
> post. By making filters or shortcodes have dependencies outside of
> their inputs, then you introduce strange cases like this.
>
> Jetpack is doing it right here. They want to get the_content, so they
> run it through the the_content filter. This is not unusual or
> unexpected. What is unexpected is the way your plugin behaves oddly
> when some other piece of code is filtering something with the_content
> filter. Your plugin is making assumptions about the ordering of
> filters and when the_content runs that are not always true, basically.
> Moreso since any theme can call the_content any number of times, and
> in any place.
>
> -Otto
>
>
> On Tue, Jan 1, 2013 at 4:42 PM, Ian Dunn <ian at iandunn.name> wrote:
>> I just spent a couple hours tracking down a problem that was reported with
>> one of my plugins, and it turns out that the latest version of Jetpack is
>> causing problems with a lot of different plugins. I've seen reports of at
>> least half a dozen different ones, so I thought I'd pass these links along
>> in case it might save anyone else some time:
>>
>> http://wordpress.org/support/topic/jetpack-204-breaks-nextgen-galleries
>> http://wordpress.org/support/topic/jetpack-204-upgrade-breaks-several-plugins
>> _______________________________________________
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers