Make WordPress Core

Opened 6 years ago

Closed 4 years ago

#8095 closed enhancement (worksforme)

Display core upgrade message earlier

Reported by: MichaelH Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.7
Component: Upgrade/Install Keywords:
Focuses: Cc:


Can some message be displayed right after the Upgrade Automatically button is clicked to advise the user that the upgrade is in progress?

Currently, after clicking the Upgrade Automatically button, it can take some time before the 'Upgrade WordPress' header is displayed. Once that message is displayed, the rest of the progress messages, from 'Downloading update from http://wordpress.org/nightly-builds/wordpress-latest.zip' to 'WordPress upgraded successfully' get displayed almost immediately.

Attachments (1)

8095.diff (332 bytes) - added by DD32 6 years ago.

Download all attachments as: .zip

Change History (15)

comment:1 DD326 years ago

This would be due to output buffering, most likely by the webserver using zlib or gzip, There is a chance that its a PHP gzip output buffer however, Would adding a few flush()'s to show_message() break any PHP output buffers?

DD326 years ago

comment:2 DD326 years ago

  • Keywords has-patch needs-testing added

attachment 8095.diff added.

  • Flushes all buffers on show_message()

There however is a warning: It needs testing with IE6; according to the PHP docs using ob_start('ob_gzhandler') along with ob_end_flush() can cause blank pages, I'm not sure if this will apply to the PHP.ini setting output_handler AFAIK they work very similar..

comment:3 MichaelH6 years ago

I don't see the blank pages in IE6, but then again, don't notice any earlier display of upgrading messages in Firefox or IE6.

comment:4 Denis-de-Bernardy5 years ago

  • Milestone changed from 2.8 to 2.9

Let's delay this to until #7875 gets approved. Or possibly merge the two.

comment:5 follow-up: Denis-de-Bernardy5 years ago

is this still current, or can we close as invalid?

comment:6 Denis-de-Bernardy5 years ago

  • Keywords needs-patch added; has-patch needs-testing removed

-1 to the current patch, too. it prevents output buffers from changing the strings returned by WP

comment:7 in reply to: ↑ 5 MichaelH5 years ago

Replying to Denis-de-Bernardy:

is this still current, or can we close as invalid?

Yes it is still valid--just did Tools->Upgrade to latest 2.8bleeding and after clicking on Upgrade Automatically, it 'clears' the main screen area (see note below), and then a 45 second 'pause' before getting any other notification.

Note; When it clears that main screen area, can't something be displayed?

comment:8 follow-up: Denis-de-Bernardy5 years ago

  • Milestone changed from 2.9 to 2.8

I *think* the mega flush should occur earlier in the process. Personally, I've a plugin that uses the core upgrade tools to upgrade a patched version of WP. It changes a few captions along the way.

As this was not pluginable at all until recently, I sorted this out by using output buffers in the feedback messages. As in, I'd flush all buffers, and then restart an ob_start(edit_captions).

That way, messages would still get displayed, but the screen would still be pluginable.

Side note: WP doesn't add any output buffers on that screen all by itself. Might your issue be server-related? (as in, it's automatically started by the host.) If so, placing the flush all at the beginning of the page (e.g. add_action(load-upgrade.php, wp_ob_end_flush_all, 0) or something like that) may do the trick as well.

comment:9 in reply to: ↑ 8 MichaelH5 years ago

Replying to Denis-de-Bernardy:

Side note: WP doesn't add any output buffers on that screen all by itself. Might your issue be server-related?

Not really qualified to answer that except to say it happens on shared linux hosting and locally installed XAMPP.

comment:11 DD325 years ago

  • Milestone changed from 2.8 to Future Release

Server-side Gziping causes this issue.

A good variety use PHP-based zlib/output buffers to achieve this, The patch here was to force the output buffer variety to flush.

When its compressed via Zlib or an Apache module (or other web server module), Its impossible to change this (AFAIK, There might be a header or something that can be used).

No. This is not a wontfix. #8992 completely irrelevant.

comment:12 Denis-de-Bernardy5 years ago

  • Type changed from defect (bug) to enhancement

comment:13 dd325 years ago

Perhaps showing a spinner of some sort on the page before the upgrade?

If a server has server side compression enabled, theres nothing WordPress can do to force the page to display earlier, the server is still going to wait for it to be completely loaded.

comment:14 johnbillion4 years ago

  • Keywords needs-patch removed
  • Milestone Future Release deleted
  • Resolution set to worksforme
  • Status changed from new to closed

worksforme as the new central 'WordPress Updates' screen displays feedback straight away on the next page after clicking 'Update Automatically' so there is no longer the delay before UI feedback is shown.

Note: See TracTickets for help on using tickets.