Title: Vmwp's Replies | WordPress.org

---

# Vmwp

  [  ](https://wordpress.org/support/users/vmwp/)

 *   [Profile](https://wordpress.org/support/users/vmwp/)
 *   [Topics Started](https://wordpress.org/support/users/vmwp/topics/)
 *   [Replies Created](https://wordpress.org/support/users/vmwp/replies/)
 *   [Reviews Written](https://wordpress.org/support/users/vmwp/reviews/)
 *   [Topics Replied To](https://wordpress.org/support/users/vmwp/replied-to/)
 *   [Engagements](https://wordpress.org/support/users/vmwp/engagements/)
 *   [Favorites](https://wordpress.org/support/users/vmwp/favorites/)

 Search replies:

## Forum Replies Created

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

 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Max Mega Menu] 3rd level mobile menu issue](https://wordpress.org/support/topic/3rd-level-mobile-menu-issue/)
 *  Thread Starter [Vmwp](https://wordpress.org/support/users/vmwp/)
 * (@vmwp)
 * [9 years, 4 months ago](https://wordpress.org/support/topic/3rd-level-mobile-menu-issue/#post-8639515)
 * 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.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[WP Super Cache] 4.2.1 initial blank page load](https://wordpress.org/support/topic/421-initial-blank-page-load/)
 *  Thread Starter [Vmwp](https://wordpress.org/support/users/vmwp/)
 * (@vmwp)
 * [11 years ago](https://wordpress.org/support/topic/421-initial-blank-page-load/page/2/#post-6067376)
 * WordPress 4.2.2 + WPSC 1.4.4 (Release) w/ GZIP enabled = working
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[WP Super Cache] 4.2.1 initial blank page load](https://wordpress.org/support/topic/421-initial-blank-page-load/)
 *  Thread Starter [Vmwp](https://wordpress.org/support/users/vmwp/)
 * (@vmwp)
 * [11 years ago](https://wordpress.org/support/topic/421-initial-blank-page-load/#post-6067365)
 * Marking as resolved.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[WP Super Cache] 4.2.1 initial blank page load](https://wordpress.org/support/topic/421-initial-blank-page-load/)
 *  Thread Starter [Vmwp](https://wordpress.org/support/users/vmwp/)
 * (@vmwp)
 * [11 years ago](https://wordpress.org/support/topic/421-initial-blank-page-load/#post-6067300)
 * Donncha – I quickly tested the new devel code (w/ WPSC_MB_STRLEN constant), and
   I think that did it.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[WP Super Cache] 4.2.1 initial blank page load](https://wordpress.org/support/topic/421-initial-blank-page-load/)
 *  Thread Starter [Vmwp](https://wordpress.org/support/users/vmwp/)
 * (@vmwp)
 * [11 years ago](https://wordpress.org/support/topic/421-initial-blank-page-load/#post-6067269)
 * If your hosting situation allows, enabling the mbstring extension in php also
   corrects this mostly likely
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[WP Super Cache] 4.2.1 initial blank page load](https://wordpress.org/support/topic/421-initial-blank-page-load/)
 *  Thread Starter [Vmwp](https://wordpress.org/support/users/vmwp/)
 * (@vmwp)
 * [11 years ago](https://wordpress.org/support/topic/421-initial-blank-page-load/#post-6067264)
 * 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](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.wordpress.org/changeset/32114](https://core.trac.wordpress.org/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
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[WP Super Cache] 4.2.1 initial blank page load](https://wordpress.org/support/topic/421-initial-blank-page-load/)
 *  Thread Starter [Vmwp](https://wordpress.org/support/users/vmwp/)
 * (@vmwp)
 * [11 years ago](https://wordpress.org/support/topic/421-initial-blank-page-load/#post-6067246)
 * 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/](https://whatever/wp-admin/))
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[WP Super Cache] 4.2.1 initial blank page load](https://wordpress.org/support/topic/421-initial-blank-page-load/)
 *  Thread Starter [Vmwp](https://wordpress.org/support/users/vmwp/)
 * (@vmwp)
 * [11 years ago](https://wordpress.org/support/topic/421-initial-blank-page-load/#post-6067244)
 * 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.

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