Backend system update to v3.6.30 not work?

Has anyone experienced problem when update OC using backend?

For me it has started with v3.6.30.

Update to this version from any previous (or even force update existing v3.6.30 installation) breaks OC.

No error in system.log and visually looks like PHP timeout - stuck on Finishing installation modal window (but I have unlimited execution time).

After backend page refresh I have an error:

Warning: require( ... /vendor/composer/../symfony/polyfill-php72/bootstrap.php): 
Failed to open stream: No such file or directory in ... /vendor/composer/autoload_real.php on line 41

Only solution is to recover from backup.

Using october:update through artisan works OK, but is unusable on shared hosting where is no access to cli.

Hi @jan-vince,

I encountered the same issue with the backend. I now use CLI for updates.

If CLI isn’t an option, you can create a route or use the onStart function (for a page) to run:

\Artisan::call('october:update');

Try running

composer update -vvv

This will give verbose output and can show any bottlenecks

Hi and thanks to both, I probably have a cause of this:

  1. Running locally valet php artisan --env=local october:update works fine.

  2. Running update from backend (even force update on v3.6.30 updated several days before) ends with “Finishing update” modal window.

  3. After backend page refresh, there is an error with missing polyfill-php72 (as stated in my first post).
    And the folder /vendor/symfony/polyfill-php72 is really missing.

  4. When I copy back this folder from backup and refresh backend page, OC works OK.

  5. When I force update from backend again, it works and finishes OK.


So as a workaround for this failed backend update, it is enough to upload /vendor/symfony/polyfill-php72 folder to shared hosting and force backend update again.


@daft

Sam, it looks like backend update has a problem with updating composer dependencies.

When I update locally through october:update I can see that composer removed polyfill-php72 as a part of this specific update, but my guess is that backend update has a problem doing the same and stuck with dependency on removed polyfill-php72.

1 Like

This might be related

Hi @daft, this is not the case - locally I have no time limit and shared hosting has limit 300s.

This must be related to removed composer dependency (polyfill-php72).

I will dig deeper and let you know if I find something.

Thanks @jan-vince

It looks like then it might be coming from a change in the symfony stack. symfony/mailer and symfony/mime both bring in that package and perhaps they’ve dropped it.

Not sure why it would crash the web composer instance though…

Hi Sam,

I can confirm, that web installer now works OK and successfully installs v3.6.30.

Updating from v3.6.29 to v3.6.30 on shared hosting fails with an error (missing polyfill-php72), but once I upload this missing folder and run update from backend again, if finishes successfully.

As far as I know the solution I am OK with that :slight_smile:

But unfortunately I have no clue why composer packages are not updated correctly in first pass/update on shared hostings.

1 Like

A patch has been included in october/rain (v3.6.0) that should fix this moving forward. It was a very specific problem that took days to uncover.

Basically, composer via CLI does not halt for warnings, and file_get_contents() has a quirk that either returns false or throws an exception… so in the web installer, instead of following its usual behavior, it unnecessarily halts.

1 Like