• Resolved Daan van den Bergh

    (@daanvandenbergh)


    Hi!

    We have a mutual client who is experiencing a compatibility issue between your plugin and OMGF (my plugin).

    The issue lies in the usage of output buffering. Speed Optimizer and OMGF both start output buffers with a callback, but since Speed Optimizer flushes all output buffers, OMGF’s callback never runs.

    A fix I found would be to add a filter to your output HTML, e.g. at the end of SiteGround_Optimizer\Parser\Parser::run():

    	/**
    * Run the parser.
    *
    * @since 5.5.2
    *
    * @param string $html The page html.
    *
    * @return string $html The modified html.
    */
    public function run( $html ) {
    if ( ! preg_match( '/<\/html>/i', $html ) ) {
    return $html;
    }

    // Replace unsecure links if the option is enabled.
    if ( Options::is_enabled( 'siteground_optimizer_fix_insecure_content' ) ) {
    $html = Ssl::get_instance()->replace_insecure_links( $html );
    }

    // Do not run optimizations if amp is active, the page is an xml or feed.
    if (
    $this->is_amp_enabled( $html ) ||
    Helper::is_xml( $html ) ||
    is_feed()
    ) {
    return $html;
    }

    // If the user is logged in and the filebased caching is disabled.
    if ( is_user_logged_in() ) {
    // Return the original html if the filebased caching is disabled.
    if ( ! Options::is_enabled( 'siteground_optimizer_file_caching' ) ) {
    return $html;
    }

    // Return the original html if loggedin filebased caching is disabled.
    if ( ! Options::is_enabled( 'siteground_optimizer_logged_in_cache' ) ) {
    return $html;
    }
    }

    $optimized_html = $this->optimize_for_visitors( $html );

    if ( Options::is_enabled( 'siteground_optimizer_file_caching' ) ) {
    File_Cacher::get_instance()->process( $optimized_html );
    }

    return apply_filters( 'sgo_optimized_html', $optimized_html );
    }

    With this filter in place, OMGF would hook into that, so it could still apply its optimizations, e.g.:

    		if ( defined( 'SiteGround_Optimizer\PLUGIN_SLUG' ) ) {
    remove_filter( 'omgf_buffer_output', [ $this, 'process' ] );
    add_filter( 'sgo_optimized_html', [ $this, 'process' ] );
    }

    Hopefully you’d be willing to add this filter short term to help out our mutual client.

    Looking forward to your reply!

    Kind regards,

    Daan van den Bergh (developer of OMGF)

    The page I need help with: [log in to see the link]

Viewing 6 replies - 1 through 6 (of 6 total)
  • Plugin Support Daniela Ivanova

    (@daniellaivanova)

    Hello @daanvandenbergh,

    Your suggestion and the proposed code snippet have been reported directly to our development team for review. They will evaluate adding the sgo_optimized_html filter to a future release of the Speed Optimizer plugin. You can follow our plugin’s changelog to check if it has been added.

    Best regards,
    Daniela Ivanova

    Thread Starter Daan van den Bergh

    (@daanvandenbergh)

    Thanks. Will do! Any approx. ETA on when the evaluation is done?

    Plugin Support Daniela Ivanova

    (@daniellaivanova)

    We do not have an approximate ETA at this stage, as the request needs to be scheduled and evaluated alongside our current development roadmap.

    However, we will keep a close eye on it and update you here as soon as we receive feedback from the team.

    Best Regards,
    Daniela Ivanova

    Thread Starter Daan van den Bergh

    (@daanvandenbergh)

    Thanks! Much appreciated!

    Plugin Support Daniela Ivanova

    (@daniellaivanova)

    Hello @daanvandenbergh,

    Our developers thoroughly tested the output buffering flow between both plugins, and they were unable to reproduce a scenario where Speed Optimizer interrupts or prevents the OMGF buffer callback from executing.

    Currently, Speed Optimizer starts its buffer on the init hook (priority 10), while OMGF starts its front-end buffer on template_redirect (priority 3). Because template_redirect runs after init, the OMGF buffer opens after ours. In this default setup, the OMGF callback actually executes first, and our parser executes afterward without interrupting your ob_end_flush() call.

    Our team also tested the reverse scenario to see how OMGF could process the final HTML after Speed Optimizer has finished its optimizations (which matches the goal of your proposed filter). They found this can already be achieved by adjusting the initialization order and priorities within OMGF, rather than adding a new filter:

    1. Buffer Timing: The OMGF output buffer would need to start before ours (e.g., on the init hook with a priority lower than 10). This ensures your callback executes last, receiving the HTML after Speed Optimizer has processed it.
    2. Class Initialization: Currently, the OMGF\Frontend\Process class (which registers the output buffer) initializes on init at priority 50. Because this happens after our parser is already registered, the entire class would need to be initialized earlier (for example, on init with priority 1) to allow the output buffer to start with an earlier priority.

    Based on these findings, the two plugins can safely coexist and achieve the desired execution order by adjusting the buffer initialization priorities on the OMGF side.

    Best Regards,
    Daniela Ivanova

    Thread Starter Daan van den Bergh

    (@daanvandenbergh)

    Okay! Thanks for that. I’ll reach out to the user and give that a shot, instead. Thanks!

Viewing 6 replies - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.