[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