[wp-trac] [WordPress Trac] #24713: Compression in load_styles.php does not always work, cauing inability to use Console (Control Panel)

WordPress Trac noreply at wordpress.org
Mon Jul 8 22:59:05 UTC 2013


#24713: Compression in load_styles.php does not always work, cauing inability to
use Console (Control Panel)
--------------------------+-----------------------------
 Reporter:  cfeet77       |      Owner:
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  General       |    Version:  3.5.2
 Severity:  major         |   Keywords:
--------------------------+-----------------------------
 I think this is quite important, because it sometimes prevents using wp-
 admin pages altogether.

 Server environment: Debian Linux 6.0.5, apache 2.4.2, mysql 5.5.27, php
 5.4.5.

 I have discovered that sometimes my admin Console pages are not rendered
 properly, as though a style sheet is not loaded. This does not depend on a
 browser and client operating system. I tried IE, Firefox, Chrome, Opera, I
 tried client browser in Windows XP, Windows Vista, Android 4.1.2, and the
 problem could be seen in all these cases.

 The problem is random. Through some magick and without any special
 activity on my side, wp-admin pages sometimes stop working as described,
 and after 10 minutes it randomly fixes itself (or does not), again without
 any action on my side.

 Further investigation showed that when I manually try to open a link
 containing load-styles.php as referred to from the console page (I copy
 and paste the link including all GET request variables into a new browser
 window), then sometimes garbage is shown for the load-styles.php. Encoding
 is UTF-8 (I have added .htaccess just in case to make sure this is not an
 issue). But when garbage is shown, then admin pages do not work (their
 stylesheet obviously does not get loaded). When there is no garbage in
 load-styles.php (i.e. normal stylesheet, good visible text), then all is
 good.

 I had a faint idea that this was because I mechanically moved my site from
 one URL (approx. localhost) to a "production-level" URL (copied all files
 + database), I thought this could be related (even though I changed all
 URLs in Settings/General afterwards), but this did not hold water.

 So looked into load-styles.php and noticed there is some conditional
 content encoding out there. What I did I disabled this content encoding
 altogether like this:


 {{{
 if ( $compress && ! ini_get('zlib.output_compression') && 'ob_gzhandler'
 != ini_get('output_handler') && isset($_SERVER['HTTP_ACCEPT_ENCODING']) )
 {
         header('Vary: Accept-Encoding'); // Handle proxies
         if ( false !== stripos($_SERVER['HTTP_ACCEPT_ENCODING'],
 'deflate') && function_exists('gzdeflate') && ! $force_gzip ) {
                 // header('Content-Encoding: deflate');
                 // $out = gzdeflate( $out, 3 );
         } elseif ( false !== stripos($_SERVER['HTTP_ACCEPT_ENCODING'],
 'gzip') && function_exists('gzencode') ) {
                 // header('Content-Encoding: gzip');
                 // $out = gzencode( $out, 3 );
         }
 }

 }}}

 and now everything works. All fine and all good, problem solved. No
 garbage anymore.

 Would please bother to disable this worse than useless content compression
 in load-styles.php for the time being before you find a solution that
 works for all? I believe I might be not the only one to experience these
 random issues with Console stylesheet. I expect that 99% of website admins
 have fast connections to manage their websites, and for those who do not,
 Opera Mini is still there and still working.

 And I also mean that the problem, once it shows up, is persistent, i.e. it
 does not disappear through a trivial full page reload (Ctrl-Shift-R in FF,
 for instance). If pages (stylesheet) stop working, then nothing helps: not
 clearing the browser cache, not restarting the browser, not starting a new
 instance of the browser, not starting another browser from another vendor.
 So the problem is not on the client side, it is on the server side.

--
Ticket URL: <http://core.trac.wordpress.org/ticket/24713>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list