WordPress & nginx compatibility: core/upgrade plugins progress bar needed

[FractalizeR]

Hello

Many hosting providers use nginx together with Apache to speed up their shared hosting servers. And nginx is usually set up as

location / {
    proxy_read_timeout = 60
}

So, when user called /wp-admin/upgrade.php to upgrade core or plugins, wordpress actually stops sending any information to Apache (PHP buffers even those several messages which are sent out) until core or plugin is fully updated.

This operation on big plugins and especially WP core takes much more time, than 60 seconds. So, this makes hoster server effectively incompatible with WordPress. And unless hosting company is willing to help it's customer to change nginx settings (which is not always a desired move because of stability issues), customer is left out with a need to upgrade both WordPress and it's plugins manually.

My suggestion is to periodically send some information to apache at least each 10-30 seconds when upgrade is in process. It may be a javascript progress bar function calls, or just an empty tag like <div style="display: none;"></div> immediately followed by PHP call flush() (and may be, ob_flush of needed).

Also it may be required to send enough data this way (inserting, may be some string like "GGGGGGGGGGGGGGGGGGGGGGGGGGG" inside invisible <div> to make Apache modules like mod_gzip to flush their buffers to nginx also if they are enabled.

[nacin]

Related #12132. Actually, possibly a duplicate -- we now send flush output during the upgrade.

[FractalizeR]

The solution is not only to flush some output, but to periodically send AND flush it DURING ALL upgrade operation (at least once per several seconds). Otherwise, nginx throws 504 error.

[nacin]

Incorrect reference -- I meant #11232.

[FractalizeR]

Again, this is not what I mean. On my current hosting I was able to upgrade even single plugin (Recaptcha) only after tech guys tuned nginx for me. The information should be sent to backend every X seconds to prevent nginx to throw Gateway timeout 504 error.

[nacin]

I know what you mean. I was only correcting the ticket reference.

[FractalizeR]

Ok, I am sorry ;)
Hope my suggestion will be accepted. I think it will rapidly increase a number of fully-wordpress-compatible shared hostings. At least in Russia since nginx is very popular here.

[nacin]

I know of a lot of people who leverage nginx with WordPress, and no one has asked for something like this. To me it sounds like a server configuration issue, no?

[FractalizeR]

This is a constant server configuration issue if you use requests proxification. Not only nginx affected. Since this is pretty common, I think this should be solved on WP level because there is no acceptable workaround on webserver level.

[wpmuguru]

You're in a shared hosting environment and you have something in your WP install that needs more than 60 seconds to upgrade?

However, we addressed a similar issue with networks behind load balancers in #12069.

What if a flush was added after ever upgrade message or there was a constant/filter to turn on said flushing?

[FractalizeR]

Yes, I'm in shared hosting at the internet provider with cheap tariffs. If I upgrade the plugin more than 200-500Kbin size (packed), it takes sometimes more than 60 seconds. It's a single action (1 plugin upgrade) so just adding flush will not solve this I think because there would be nothing to flush.

The suggestion is to output some spaces every X ticks (every 5 files unpacked for example). Spaces does not matter in HTML so it should not be noticed. Later it can be replaced by progress bar of the installation.

Honestly, I don't understand, why upgrading some plugins take more than 60 seconds. May be, it's because my hoster has a million of websites on his servers...

[nacin]

I don't see this as a core issue.