0

I have a perplexing problem with Wordpress. When pages under /admin/ loads "load-scripts.php" with "plupload" as one of the arguments, it hangs for ever. The "Add New Post" page is one such page. For example, this URL hangs for ever:

http://example.com/wp-admin/load-scripts.php?c=0&load%5B%5D=jquery-core,jquery-migrate,utils,plupload,json2&ver=3.9.1

While this returns successfully immediately:

http://example.com/wp-admin/load-scripts.php?c=0&load%5B%5D=jquery-core,jquery-migrate,utils,json2&ver=3.9.1

When I say "hang for ever", I mean that it hangs for several minutes and finally just returns a partial result without error. By partial result, I mean minified Javascript that just ends abruptly in the middle of an expression.

I have run Wordpress versions 3.9.1 and 3.8 on Apache with libapache2-mod-php5, Nginx with php5-fpm and just using the plain php built-in development server. In all cases this problem still occurs.

I have downgraded to version 3.0 and the issue disappeared. In this version, "load-scripts.php" doesn't try to fetch plupload. Since I haven't managed to find any solutions to this issue using Google I'm assuming this is an issue with my server rather than a Wordpress bug.

Using set_time_limit has no effect, the script still hangs for ever. I'm getting no errors in any logs, nor in the console when using the php development server.

For some reason, replacing this (the very bottom lines of load-scripts.php):

header('Content-Type: application/x-javascript; charset=UTF-8');
header('Expires: ' . gmdate( "D, d M Y H:i:s", time() + $expires_offset ) . ' GMT');
header("Cache-Control: public, max-age=$expires_offset");

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 );
     }
}

echo $out;
exit;

With this:

header('Content-Type: application/x-javascript; charset=UTF-8');
header('Expires: ' . gmdate( "D, d M Y H:i:s", time() + $expires_offset ) . ' GMT');
header("Cache-Control: public, max-age=$expires_offset");

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

echo "SUCCESS";
exit;

echo $out;
exit;

Causes the script to return "SUCCESS" instantly. If I don't comment out the compression block, junk data is returned. Apparently the script hangs on echo $out. I'm guessing this bug has to do with compression, but I have no clue what to do with that information.

I realize this question is hardly easy to just answer, but I'm certain there is a simple solution once I figure out what's wrong.

Thanks in advance for any suggestions.


Edit: I have examined the script further using CURL. I have tried requesting "load-scripts.php" with "Accept-Encoding" set to gzip, deflate and nothing. It made no difference. In all cases the script instantly returns a bunch of data then freezes in the middle of a Javascript statement. It appears to stop at a random location in the output Javascript for every request. I have enabled all error reporting and set allowed memory to 2048M, which has also made absolutely no difference. I'm starting to think there's some low-level PHP issue here that I'm not going to be able to figure out.


New edit: I have experimented further. It turns out that if I simply var_dump($out); and exit; just after $out is constructed, the script still hangs. This must have something to do with the size of the printed string (216459 characters.) Part of the string is sent to the browser, then the request simply hangs (in one case for as long as 6 minutes) before just dying without outputting the rest of the string. No errors are reported anywhere.


Yet another edit: I have put this in the top of the script:

header('Content-Type: application/x-javascript; charset=UTF-8');
header('Expires: ' . gmdate( "D, d M Y H:i:s", time() + $expires_offset ) . ' GMT');
header("Cache-Control: public, max-age=$expires_offset");
var_dump(str_repeat("foo", 350000));
exit;

And 1 050 000 character str is quickly and successfully sent to the browser without issue. This doesn't have anything to do with output size.

  • Are you running this locally (judging by array of servers tried)? Do you have firewall or antivirus running? Can you replicate it from different server or at different client? – Rarst Jul 29 '14 at 14:38
  • @Rarst: I'm running this on a Debian "wheezy" server that has firewall and possibly antivirus running. I have now downloaded and compiled PHP 5.5 on the server and hosted the fresh Wordpress install from its test server, and the problem still occurs. This does seem like it could be an issue with the firewall, I'll test that hypothesis. – Hubro Jul 29 '14 at 21:49
  • @Rarst: I have tried requesting the URL locally on the server through 127.0.0.1 and it doesn't hang. This apparently does have something to do with a firewall. I'll investigate further – Hubro Jul 29 '14 at 23:36
2

Short and anticlimactic answer: the big fancy corporate firewall protecting the server was set to HTTP "application" mode. We switched it over to simply allowing all traffic on port "80" and the issue was solved. Rarst♦ was right!

  • I know this is old, but this answer solved the same problem I was having with Wordpress 4.3.3 and I thought I would add some additional info in case anyone else came along. The issue is that the plupload javascript is used for multi file uploads and has some code for both Flash and Silverlight. If you have an application aware firewall (like Palo Alto or other "next-gen" firewall) it will block access to Flash and Silverlight traffic if you have only allowed web-browsing traffic through. To fix it, allow Flash and Silverlight traffic through the firewall. – Caynadian Feb 8 '16 at 17:39
0

I know you said you had this problem with Apache too, but I can only speak for Nginx. I found this while googling to solve what seems to be this exact problem. I fixed by running sudo chown -R www-data:www-data /var/lib/nginx.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.