WP-Super-Cache: bug fixing and PHP object destruction

If you use the WPTouch mobile plugin, or the preload function in my caching plugin, or noticed that annoying but random and (thankfully) rare “front page isn’t showing my front page” bug then you might like to try the development version of WP-Super-Cache located on this page.

Mobile plugins need to tell WP Super Cache what user agents they support. I documented the filters you can use (“cached_mobile_browsers” and others) to do this but I don’t think they’ve been used by any plugin. It’s not hard to do and I added code that checks for WPTouch so when you visit the WP Super Cache settings page it updates the mobile user agents. So far it works for me but please feel free to view this site on your mobile phone and tell me if it looks ok! I also added support for the theme switcher in WPTouch based on code posted on the wporg forum.

It appears that the “random post on the front page” problem is a side effect of how PHP works. WordPress incorrectly reported that the current page wasn’t a search page, even though it was. I put an extra bit of code in checking if $_GET is non empty and that fixed it, so far.

Just in case anyone else is interested, this is why is_search() fails randomly when run during PHP shutdown. When a PHP process shuts down it starts by killing off objects. Unfortunately this happens before PHP stops executing your code, something that changed after PHP4.

Anything that runs when the output buffer finishes or that is registered by register_shutdown_function() better not depend on objects or classes. That means no using $wpdb, the object cache may disappear or to be completely paranoid don’t expect $wp_query to be around either! The functions is_search(), is_feed() and other related WordPress functions depend on $wp_query so you should cache the values of those functions earlier in the process. I’m thinking of hooking into wp_head but that depends on the theme unfortunately. Not every theme uses that action.

Many years ago I changed the format of the cache “meta file” from an object to an array because of the way the PHP desctruction process works. More recently, but still two years ago I had to remove all calls to get_option() and update_option() in the output buffer handler because occasionally people saw the error, “Call to a member function get() on a non-object in cache.php” in their error log. The object cache object had been destroyed by PHP! That was a right pain to figure out as the code looked perfect yet didn’t work right some of the time.

To help figure out problems I’ve added a lot more debugging to the plugin too. If $wp_query disappears it’ll appear in your debug log, and preloading will generate a lot more messages now.

Next up is caching is_search(), is_feed(), is_single() etc. Where should those be cached? The “init” action is too early for is_search and probably others but I don’t want to depend on actions that may not be in a theme.

14 thoughts on “WP-Super-Cache: bug fixing and PHP object destruction

  1. ? i have quite a few sites using the “WP Super Cache” plug-in.
    and yes, I continue to get the “infamous” front page error
    will the new plug-in update cure what ails me?i keep going back to sites thinking i entered something wrong but other sites, set up the same way do NOT give me the error…please straighten ME out

  2. Would like your opinion on my .htaccess SuperCache changes. I’ve seen quite a bit of performance improvement on my site with this: Check it out at http://www.r3now.com

    P.S. I would like your opinion or critique of this. Let me know what you think…

    # BEGIN R3Now supercache

    ForceType text/html
    FileETag None

    AddEncoding gzip .gz
    AddType text/html .gz

    SetEnvIfNoCase Request_URI \.gz$ no-gzip

    BrowserMatch ^Mozilla/4 gzip-only-text/html
    BrowserMatch ^Mozilla/4\.0[678] no-gzip
    BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
    BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html

    AddOutputFilterByType DEFLATE text/css application/x-javascript text/html text/richtext text/plain image/x-icon

    # 12/09/2011 Change standard supercache settings for performance
    # supercache header cookie rules are below under FilesMatch directive
    Header append Vary User-Agent env=!dont-vary
    # Header set Vary “Accept-Encoding, Cookie”
    # Header set Cache-Control ‘max-age=3, must-revalidate’

    # Force expiration dates on various site objects to reduce checking.

    ExpiresActive On
    ExpiresByType text/html A43200
    ExpiresByType text/css A86400
    ExpiresByType application/x-javascript A86400
    ExpiresByType image/gif A31536000
    ExpiresByType image/jpeg A31536000
    ExpiresByType image/png A31536000
    ExpiresByType image/x-icon A31536000
    ExpiresByType application/pdf A31536000
    ExpiresByType text/plain A86400
    ExpiresByType application/x-gzip A43200
    # ExpiresByType application/zip A43200

    # Set cache settings for unchanged objects

    # Revalidate every 180 days
    Header set Cache-Control “max-age=15552000, public”
    FileETag MTime Size

    # Revalidate every 7 days
    Header set Cache-Control “max-age=604800, must-revalidate”

    # Revalidate every day
    Header set Vary “Accept-Encoding, Cookie”
    Header set Cache-Control “max-age=86400, must-revalidate”
    FileETag MTime Size

    # END R3Now supercache

  3. Next up is caching is_search(), is_feed(), is_single() etc. Where should those be cached? The “init” action is too early for is_search and probably others but I don’t want to depend on actions that may not be in a theme.

    You should use the ‘wp’ hook for this.

  4. get this error, tried update, tried debug, can’t get rid of the error Warning! WP Super Cache caching broken! The script advanced-cache.php could not load wp-cache-phase1.php.

    Please edit /home/xxxx/public_html/xxxx.com/wp-content/advanced-cache.php and make sure the path to /home/xxxx/public_html/xxxx.com/wp-content/plugins/wp-super-cache/wp-cache-phase1.php is correct.

    1. Outbackjack – Edit your advanced-cache.php and make sure the path in the code to wp-cache-phase1.php is correct! The correct path is in the error message. Make sure that file exists too in case something went wrong during the update.

  5. Not sure where this should go but I have a suggestion for a dramatic enhancement and improvement for WP Super Cache.

    Why not work directly with the developers who maintain some of the supplemental plugins so that you can manage them all from your WP Super Cache interface?

    You could add the settings into your plugins tab for:

    DB Cache Reloaded
    WP Minify
    WP Widget Cache

    This would provide you a comprehensive and overall caching solution while allowing those other developers to continue to maintain their own plugins. In other words, let them focus on their specialties but work together to create a powerful overall caching solution.

    It would be a great to have a selection button for the others such as

    Install — Activate — Settings

    You could also add a set of selection buttons on your Contents tab to clear each of the cache plugin info… Then when troubleshooting, updating, developing, etc., all of the different plugins could be cleared with one button while still keeping their own separate settings through an iFrame window or some other integrated mechanism on your Plugins tab.

    Just a thought to take this to the next level and create a great direct competitor to W3 Total Cache which I do not believe is as efficient as all of these plugins together.

  6. Bill – that’s a great idea and could be implemented easily. The tabs in the plugin are run through a filter (AFAIR) and the external plugin could show a simplified interface perhaps. Or I could try supporting them if I detected they were installed..

    Thanks for the complement too!

  7. I just installed the dev version and was glad, that it has a native support of wptouch now. But together with the support of wptoch I found out, that Super Cache supports only the fee version and not the pro version of Wptouch.
    It would be great, also to support the pro version. I can’t imagine, that there are many differences between the versions and the way they work with Super Cache and maybe it might be just the different pathname of the pro-plugin which is “wptouch-pro” instead of “wptouch”.

Leave a Reply

%d bloggers like this:

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.