Vmwp

Hi Tom,
Thank you for the reply and checking into it. At this point I’m thinking it’s a theme issue (CSS). Sorry, I should have looked into it a bit further first. I tested the settings w/ a clean install w/ the twentysixteen theme and everything seems to function properly. I was seeing behavior where the 2nd/3rd level mobile menu was overlaying over the top level menu content, rather than pushing it below (which I saw w/ the clean install). Given the overlay behavior, I can see why closing the children menus w/ js helped the situation, but clearly something external was interfering. I appreciate your time and thanks for developing a great responsive menu plugin.

WordPress 4.2.2 + WPSC 1.4.4 (Release) w/ GZIP enabled = working

Marking as resolved.

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

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

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 (https://github.com/Automattic/wp-super-cache/blob/master/wp-cache-phase2.php#L559) 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 (https://core.trac.www.ads-software.com/changeset/32114)… 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…

-Bret

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/)

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.