Support » Plugin: PageSpeed Ninja » Conflict with Smart Slider 3 – output buffering

  • Hi @dryabov,
    I’m the developer of Smart Slider 3 and one of our user reported that there is a conflict between Smart Slider 3 and PageSpeed Ninja. I checked the code of your plugin and I think that the problem is that you starts the output buffer later than Smart Slider 3 and that cause the issue. Smart Slider 3 s fully compatible with the most popular caching plugins, so we do not want to change our implementation. One I wrote this part, I saw that other caching plugins place the ob_start() call inside the main call tree, so their output buffer gets started before the plugins_activated action. Here is an example from W3 Total Cache . and in WP Fastest Cache too, you can track back the ob_start calls.

    • This topic was modified 2 years, 8 months ago by Nextendweb.
Viewing 6 replies - 1 through 6 (of 6 total)
  • Plugin Author Denis Ryabov

    (@dryabov)

    Hello,
    Currently we call ob_start from template_redirect handler, and the idea behind this choice is to have a possibility to check status of other plugins as late as possible and disable PageSpeed Ninja functionality in the case of possible issues. At what point Smart Slider 3 does initiate output buffering?

    Thread Starter Nextendweb

    (@nextendweb)

    Hi @dryabov,
    Thanks for the quick reply. Sliders made with Smart Slider can be embedded into anywhere on the site with shortcode or PHP code and the related CSS and JS files will be loaded only on pages which contains one or more slider. To be able to accomplish that we can not use in-built WordPress enqueue functions and we inject our codes into the head with output buffer.

    It took a lot of time to eliminate output buffer conflict with other plugins. In the last 6 months, we haven’t had any. Here you can check my current implementation, it contains fixes for several conflicts with other plugins: https://plugins.svn.wordpress.org/smart-slider-3/trunk/nextend/wordpress/assetInjector.php

    When I worked on this, I started to collect ob_start usage in other popular plugins: https://github.com/nextend/wp-ob-plugins-themes

    PageSpeed Ninja:
    add_action('template_redirect', array($plugin_public, 'template_redirect'), 2);

    Smart Slider 3:
    add_action('template_redirect', array($plugin_public, 'template_redirect'), -100);

    So we run earlier. Maybe I will add a fix for this conflict by setting the priority to 3 when PageSpeed Ninja active. But as your plugin is a cache plugin, I still think you should always be the first who starts the output buffer, which means you should open it as early as possible.

    Plugin Author Denis Ryabov

    (@dryabov)

    I’ve found my old record with explanation of why priotity=2 has been chosen. There are two kinds of limitations on the priority:

    1. AJAX requests: some plugins (e.g. WooCommerce) process AJAX requests at priority=0, and it’s better to disable caching and optimization of such requests. Actually this point is not significant, because of AJAX may be easily detected via HTTP_X_REQUESTED_WITH.

    2. Redirects: many plugins do redirect at priority=0 or 1 (e.g. Better AMP does at priority=1), and it’s better to do nothing until we are sure the page is starting to be generated. In most cases such redirects may be detected by empty content in ob handler, but there is a possibility to have a buggy plugin that starts output buffering, prints something, and then another plugin sends redirect header (actual output is not started yet) and exit.

    More over, initially PageSpeed Ninja didn’t include own page caching, and priority was chosen to don’t conflict with other caching plugin. Later, page caching was implemented to support browser-specific optimizations, but it is optional and we have to support both cases: built-in caching and 3rd-party caching.

    I’ll try to check how priority=-150 works with other plugins, and if there will be no conflicts/issues, this priority will be default value in the next release. Otherwise I’ll try to use different priorities for caching and HTML optimization.

    Thread Starter Nextendweb

    (@nextendweb)

    Thanks @dryabov!

    W3 Total cache has the following conditions to skip caching, maybe it helps:

    /**
     * Skip if doing AJAX
     */
    if (defined('DOING_AJAX')) {
    	return false;
    }
    /**
     * Skip if doing cron
     */
    if (defined('DOING_CRON')) {
    	return false;
    }
    /**
     * Skip if APP request
     */
    if (defined('APP_REQUEST')) {
    	return false;
    }
    /**
     * Skip if XMLRPC request
     */
    if (defined('XMLRPC_REQUEST')) {
    	return false;
    }
    /**
     * Check for WPMU's and WP's 3.0 short init
     */
    if (defined('SHORTINIT') && SHORTINIT) {
    	return false;
    }

    DOING_AJAX check would allow you to skip AJAX calls. Also I do not think that starting an output buffer before a header redirect would cause any problem even if there is something in the buffer.

    • This reply was modified 2 years, 8 months ago by Nextendweb.
    Plugin Author Denis Ryabov

    (@dryabov)

    Most of those constants are taken into account, but AFAIK the DOING_CRON is defining in wp-admin/admin-ajax.php and wp-admin/async-upload.php only, and so there should be extra checks in frontend anyway.

    PS. Actually, I prefer Joomla’s way with built-in onAfterRender event and possibility to reorder plugins, but unlikely something similar will be implemented in WordPress.

    Thread Starter Nextendweb

    (@nextendweb)

    Yeah, I agree. It would be great if WordPress would have an output buffer started by default (or could be started with a switch) and at shutdown there would be an apply_filters('output', $buffer); on the content of the buffer. Everyone would be happy đŸ™‚ https://core.trac.wordpress.org/ticket/43258

Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘Conflict with Smart Slider 3 – output buffering’ is closed to new replies.