Support » Plugin: WordPress Share Buttons Plugin – AddThis » WP Super Cache issue when AddThis 2.4.x is active

  • Resolved KZeni

    (@kzeni)


    – The Issue –
    WP Super Cache isn’t generating the static cache file if AddThis 2.4.0 or 2.4.1 are active. The timestamp is output normally (so it’s easy for this issue to go unnoticed at first), but it actually ends up re-generating the page on every pageview.

    – Diagnosis –
    WP Super Cache’s debug message was that a GET variable was present so supercache was being disabled (WP Cache was still being utilized). Specifically, !empty( $_GET ) within WP Super Cache’s wp-cache-phase2.php was causing “Supercache disabled: GET or feed detected or disabled by config.” to be shown.

    – A Temporary Fix –
    I reverted back to AddThis 2.3.2, and WP Super Cache went back to functioning properly. I’m guessing there’s quite a few people out there that use both AddThis & WP Super Cache, but I haven’t yet found what’s causing the issue myself.

    Any help would be greatly appreciated as I’d like to use the latest & greatest AddThis in combination with WP Super Cache. Thanks!

    http://wordpress.org/extend/plugins/addthis/

Viewing 15 replies - 1 through 15 (of 15 total)
  • Thread Starter KZeni

    (@kzeni)

    I updated the AddThis plugin to 2.4.3 to see if this issue was resolved, but it was not. I decided to look into this problem.

    The cause seemed to be to the “attest” variable that was being added via the check_for_footer() function in includes/addthis_addjs.php. I ended up making the following modification & it fixed the problem…

    Line 124 changed from:

    $url = add_query_arg( array( 'attest' => 'true') , home_url() );

    to

    $url = home_url();

    Lines 135-138 changed from:

    if ( $_GET['attest'] = 'true' )
    {
        add_action( 'wp_footer', array($this, 'test_footer' ), 99999 ); // Some obscene priority, make sure we run last
    }

    to

    add_action( 'wp_footer', array($this, 'test_footer' ), 99999 ); // Some obscene priority, make sure we run last

    Everything seems to be working now as far as I can tell. I saw that check_for_footer() really isn’t called anytime other than first time visiting the site admin (by way of the update_wpfooter() function) & on the switch_theme action. I added a switch_theme action that echoed some test text in a separate plugin to see if switch_theme was being called on every page load erroneously, and it wasn’t (and yet attest was being added to every page [confirmed by using print_r($_GET) on the theme]).

    Not sure if this is the best way to go about this (please tell me if you see any issues/recommendations), but I figured it was worth mentioning what I ended up going with at the very least if others encounter this same issue & need a quick fix (also point it out so this issue might be resolved in future versions of this plugin).

    Thanks KZeni for the fix.
    Let me try to reproduce the scenario and update here if anything breaks by this fix. If everything works well, I will add it to the future release.

    Oh I was wondering why the supercache files weren’t being generated.
    Has this fix and issue been resolved in this latest v3.0 release?

    Thread Starter KZeni

    (@kzeni)

    @martin Seems that this is yet unfixed as of version 3.0 (at least the troublesome code mentioned above hasn’t been changed).

    Oh snap!
    This is a great find to get SuperCache working as it should and sad this hasn’t been investigated and fixed, after a month of reporting and your solid work for them to prove the case.

    I’ve changed it myself and supercache files are now being generated – great and thank you @kzeni

    Hey guys,

    Sorry for missing this one! We had some major changes to plugin framework with the recent releases and didn’t want to mess things up with more changes. Have this in queue and for sure it will be updated in upcoming release.

    Thread Starter KZeni

    (@kzeni)

    Ah, okay. Thanks!

    That’s great. I posted this fix in the SuperCache forum as well, since I spotted another user having the same issue.
    Good to get it sorted.

    Now to figure out why Subscribe to Comments Reloaded is acting weird with SuperCache 🙂

    Thanks for your excellent work on this, KZeni and Martin. Our site The Aquila Report is now running better than ever thanks to the WordPress community.

    THANKS SO MUCH FOR THIS!!!!!!!!

    A new update and still you forget to include this fix.
    Can you please AddThis?

    @martin: We are on it!

    With all your valuable suggestions, the conflict is now resolved in 3.0.2. Let me know if there is any issues. Thanks again for the contribution!

    Martin

    (@rastarr)

    And 3.03 just broken it again! Aghhhhh
    Can you please have a look at getting a fix out again please. This obviously isn’t good for site speed and google when your plugin breaks a popular caching plugin.

    Srijith V

    (@srijithv)

    @martin: Sorry for that. We had to move around addthis_addjs.php to avoid conflict with other AddThis plugins. The fixed version is in the development version ( http://wordpress.org/extend/plugins/addthis/developers/ / http://downloads.wordpress.org/plugin/addthis.zip )

    This version is under our QA and will be released later this week. Meanwhile, please use the above linked version.

Viewing 15 replies - 1 through 15 (of 15 total)
  • The topic ‘WP Super Cache issue when AddThis 2.4.x is active’ is closed to new replies.