Re-install not progressing as expected on upgraded site

[anon71687268]

Expected behavior

When clicking to re-install ClassicPress, the process should complete and redirect me to the Welcome screen.

Current behavior

If the site is brand new, the re-install process works as expected: the successive texts display one-by-one and then I am whisked away to the Welcome page upon completion. Verified in both Chrome and Firefox.

If I do a re-install on an existing site that was upgraded (RC1 > RC2 > 1.0.0) the display never gets beyond this:

…the page eventually stops working (ie, seems to complete the page load) and the update seems to have gone through (ie, the site isn’t stuck in maintenance mode) in the background.

Similarly, I’ve found a near-identical behavior when installing a plugin via zip file on an upgraded site. The process initiates (and seems to complete quickly given the single-line, single-file plugin I’m testing with) but I’m left here:

The (text) steps weren’t listed and I wasn’t prompted for plugin activation. If I look at the plugin admin after that, I see the new plugin; it is installed and waiting to be activated.

Note: I have disabled all plugins and am using the default ClassicPress TwentySeventeen theme on the upgraded site where this behavior exists and tried in both Chrome and Firefox. The results are identical.

Note: I’m doing all these tests today on localhost (new install + clone of my production site), however, this behavior was also seen on my live http server, so, I don’t believe that is relevant.

Note: My php.ini is set as follows:

max_execution_time = 300
max_input_time = 300
memory_limit = 128M
post_max_size = 0
upload_max_filesize = 32M

More

Apache/2.4.37 (Win32) OpenSSL/1.1.1a PHP/7.2.9 
PHP Version 7.2.9
Modules: core, mod_win32, mpm_winnt, http_core, mod_so, mod_access_compat, mod_actions, mod_alias, mod_allowmethods, mod_asis, mod_auth_basic, mod_authn_core, mod_authn_file, mod_authz_core, mod_authz_groupfile, mod_authz_host, mod_authz_user, mod_autoindex, mod_cgi, mod_dav_lock, mod_dir, mod_env, mod_headers, mod_include, mod_info, mod_isapi, mod_log_config, mod_cache_disk, mod_mime, mod_negotiation, mod_proxy, mod_proxy_ajp, mod_rewrite, mod_setenvif, mod_socache_shmcb, mod_ssl, mod_status, mod_php7 
cURL: enabled (7.59.0)
cURL protocols: dict, file, ftp, ftps, gopher, http, https, imap, imaps, ldap, pop3, pop3s, rtsp, scp, sftp, smb, smbs, smtp, smtps, telnet, tftp
Registered Transports: tcp, udp, ssl, tls, tlsv1.0, tlsv1.1, tlsv1.2

Apache/PHP error logs are empty. I’m at a loss for what to check next.

[invisnet]

Anything in the PHP log if you enable WP_DEBUG?

[anon71687268]

Even with WP_DEBUG enabled, error logs are clean as a whistle. However, your question did lead me to the culprit.

When running performance tests (ie, gtMetrix) on a ClassicPress install… it was showing that everything was compressed, except for the domain (ie, /). This nicks points off the score. To solve the issue, I placed the following at the head of my config file:

ob_start("ob_gzhandler");

This line compresses the TLD…but, it’s also what caused the issue laid out above. I think a suitable workaround will be to simply wrap that line in a check to ensure I’m not in a backend view.

---

Update: Just confirming that wrapping the line in a condition solves the issue. It won’t run on the admin side, but, will run on the front end (for users and performance tests). So, for example:

if (!strstr($_SERVER['REQUEST_URI'], '/wp-admin/')) {
	ob_start("ob_gzhandler");
}

[james]

To be clear, you have a site where you see this issue every time? That, and the site being on localhost, would be enough to rule out issues with intermittent connectivity.

I do not see the same issue on either a fresh site or a reinstall.

@anon71687268

Apache/PHP error logs are empty. I’m at a loss for what to check next.

Does the network inspector panel in your browser provide any clues?

For example: Was the response HTML partially loaded indicating a broken connection? I would expect this to happen occasionally/intermittently depending on how long the upgrade takes and what’s in the network path between you and the site, but if you have a site where this happens every time on localhost, then that’s probably not the right answer.

https://xdebug.org/ (PHP debugger) is another option that could be helpful. It may require some setup, depending on how you have your sites configured, but since it’s on localhost this could be a good option to gather more information. You might be able use this to determine where exactly the update process stops sending data.

[anon71687268]

Sorry, @james … it looks like we were cross-posting. My previous reply lays the issue bare.

[james]

That solves it, but to me it would be interesting to know why this causes the issue.

When you do an update with ob_gzhandler does the page eventually redirect somewhere else? Or does it just stop loading entirely?

I also found a similar case from many years ago: PHP: ob_end_flush - Manual

[anon71687268]

The load continues for a short spell (as noted by the working icon on browser tab) but eventually it completes (working icon gone). There is no redirect; it remains on that same initial view of Downloading...

I took a look at the issue you referenced and can confirm that I’m not using ob_end_flush() anywhere.

[james]

Yes, I haven’t had time to look or test yet, but if I recall correctly, the update process calls ob_end_flush when it sends a new progress message.

If supported by the server, this will ensure that each line of output from the update process is sent to the browser when it is echoed.

Apparently this particular configuration doesn’t support “working correctly throughout the entire page load” much less “flushing new output”.