Support » Plugin: WP Super Cache » 4.2.1 initial blank page load

Viewing 15 replies - 1 through 15 (of 21 total)
  • We also experienced the same issue… we had to switch to W3TC temporarily but would prefer sticking with Super Cache.

    Any ideas when this will be fixed?

    Plugin Author Brandon Kraft


    Happiness Engineer

    I couldn’t duplicate this on any of my sites. WPSC’s debug option provides a lot of information; it may help to enable that and see if anything of note is present in the log when you duplicate this.

    With a blank screen, did you check the PHP error log if anything was written to it?

    We haven’t seen any PHP errors in the server logs.

    The WPSC debug log looks OK (to me), meaning it generates the same output on the working working WP 4.1.2 installation and the 4.1.2->4.2.1 upgraded site. Nothing seems to stand out.

    It seems like the output buffer doesn’t get flushed for some reason. Where exactly in the WP pipeline the hangup is [core/theme/plugin/the perfect storm], I don’t know. (FWIW, we did not test on WP 4.2)

    If I explicitly flush the buffer by adding either a ob_end_flush(); or ob_flush(); to the last line of wp-content/plugins/wp-super-cache/wp-cache-phase1.php everything works as expected.

    i should clarify, while adding the ob_flush() does seem to load the page on initial view and cause the expected behavior, it does seem to adversely affect some other things (like the redirect to wp-login.php from https://whatever/wp-admin/)

    Same with VMWP – nothing in logs.

    WP-Supercache works as expected on our dev servers, but doesn’t on our prod. Exact same server & config settings. Only difference is a MUCH bigger amount of posts / traffic on prod.

    I want to chime in and say that we’re having the same issue. Got a call from a client who told me that every time he loaded a page on his site, it came up blank. It wasn’t happening to me but I was logged in to WP with the caching option off for logged in users.

    I was able to duplicate the problem and was getting blank pages. I turned off WP Super Cache and everything works fine.

    And finally, I had only updated to WP 4.2.1 a day ago or so. So it looks as if the issue is a conflict between WP 4.2.1 and WP Super Cache.

    Just my two cents.

    After some further testing, it seems like it only happens when gzip compression is enabled. The blank page’s header would list the content encoding as gzipped but the content-length would be 0.

    Looking into it a bit more, line 559 in wp-cache-phase2.php ( was returning 0 in our environment:

    $gzsize = function_exists( ‘mb_strlen’ ) ? mb_strlen( $gzdata, ‘8bit’ ) : strlen( $gzdata );

    If i replace the above line w/ just $gzsize = strlen($gzdata);
    a non zero value is returned and everything works.

    I think this may be the reason (… WP added a mb_strlen compatibility function. So, in my case wp_super_cache is now detecting that function is available and using it, but getting back 0. It says it’s only utf8 aware.

    If you look at the implementation of that function, it doesn’t seem to take the encoding parameter into account… So, in the case of wp super admin, ‘8bit’ is supplied. The func seems to ignore it entirely, and use a more global variable [ $charset = get_option( ‘blog_charset’ ) ] to determine if the data is utf8 or not and make it’s decision on whether to use strlen or not to return a value.

    WP’s comment in the function is “the solution below works only for UTF-8, so in case of a different charset just use built-in strlen()”.

    I guess a plugin will either have to abide by that or they (WP) can make it a bit more robust and honor the $encoding charset and have the function return the strlen of the data…


    If your hosting situation allows, enabling the mbstring extension in php also corrects this mostly likely

    Thanks for the info, Bret. We actually have a dedicated server so I enabled mbstring using EasyApache and then turned WP Super Cache back on. Tested the site opening different pages and didn’t have the blank page issue anymore. So it worked!


    Plugin Author Brandon Kraft


    Happiness Engineer

    Thanks for the research. I’ll bounce around the options and see what we can come up with.

    To restate, there’s an issue when:
    * WPSC is set to used gzip compression
    * The server does not have mb_strlen available
    * Using WP 4.2 (which added a mb_strlen function when the server doesn’t have it)

    Plugin Author Donncha O Caoimh


    I just updated the development version with a possible fix. It checks if mb_strlen() exists before WordPress is loaded.

    I can’t test it as my web server has mb_strlen compiled in so I’d appreciate if any of you having this problem test this fix.

    The development version is at this page, as I just updated the code it might take 20 minutes for it to be rebuilt.

    Donncha – I quickly tested the new devel code (w/ WPSC_MB_STRLEN constant), and I think that did it.

    Also just tested the devel code and works on both our multi-site and single sites.

    Thank you!

    Noticed I was having this problem after turning on gzip for the first time today, glad it’s only a recent issue and not just me.

    Any idea how long before we will see an official update to the plugin to patch this problem, rather than having to use the development version?

    Marking as resolved.

Viewing 15 replies - 1 through 15 (of 21 total)
  • The topic ‘4.2.1 initial blank page load’ is closed to new replies.