PHP 7.3 compatibility

[adlerweb]

When trying to set up current master (8a6380e46efc81fd52c650995ad4ab62b7cbcedf) on Arch Linux using PHP 7.3.1 the composer setup fails with the following message:

> post-install-cmd: Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::installAssets
  [Symfony\Component\Debug\Exception\ContextErrorException]                                         
  Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"?  
Script Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::installAssets handling the post-install-cmd event terminated with an exception
  [RuntimeException]                                                                                                    
  An error occurred when executing the "'assets:install --symlink --relative '\''web'\'''" command:                     
    [Symfony\Component\Debug\Exception\ContextErrorException]                                           
    Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"?    
Exception trace:
 () at /srv/http/partkeepr/vendor/sensio/distribution-bundle/Sensio/Bundle/DistributionBundle/Composer/ScriptHandler.php:327
 Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::executeCommand() at /srv/http/partkeepr/vendor/sensio/distribution-bundle/Sensio/Bundle/DistributionBundle/Composer/ScriptHandler.php:175
 Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::installAssets() at phar:///usr/bin/composer/src/Composer/EventDispatcher/EventDispatcher.php:297
 Composer\EventDispatcher\EventDispatcher->executeEventPhpScript() at phar:///usr/bin/composer/src/Composer/EventDispatcher/EventDispatcher.php:219
 Composer\EventDispatcher\EventDispatcher->doDispatch() at phar:///usr/bin/composer/src/Composer/EventDispatcher/EventDispatcher.php:96
 Composer\EventDispatcher\EventDispatcher->dispatchScript() at phar:///usr/bin/composer/src/Composer/Installer.php:324
 Composer\Installer->run() at phar:///usr/bin/composer/src/Composer/Command/InstallCommand.php:121
 Composer\Command\InstallCommand->execute() at phar:///usr/bin/composer/vendor/symfony/console/Command/Command.php:245
 Symfony\Component\Console\Command\Command->run() at phar:///usr/bin/composer/vendor/symfony/console/Application.php:835
 Symfony\Component\Console\Application->doRunCommand() at phar:///usr/bin/composer/vendor/symfony/console/Application.php:185
 Symfony\Component\Console\Application->doRun() at phar:///usr/bin/composer/src/Composer/Console/Application.php:258
 Composer\Console\Application->doRun() at phar:///usr/bin/composer/vendor/symfony/console/Application.php:117
 Symfony\Component\Console\Application->run() at phar:///usr/bin/composer/src/Composer/Console/Application.php:104
 Composer\Console\Application->run() at phar:///usr/bin/composer/bin/composer:56
 require() at /usr/bin/composer:24

This seems to be related to a syntax deprecation in PHP 7.3 affecting the version of Sensio Distribution Bundle. Also other libraries used seem to be affected (quick look showed doctrine/orm 2.5)

Until all affected dependencies have been fixed upstream and updated over here or replaced would suggest adding a note to README and state 7.3 as incompatible.

[christianlupus]

I can confirm problems with partkeepr under Archlinux with the PHP version 7.3.1. I do not know if it is essentially the incompatible version but I had partkeepr installed some time now and I get regular problems with it recently since 6th of January. I updated PHP on Jan 2nd. So it could be related.

[er1z]

Symfony 2.x is simply unmantained, so keep fingers crossed on porting to 3.x (someone told in another issue that it's in the progress).

[adlerweb]

(ref https://github.com/partkeepr/PartKeepr/issues/1021#issuecomment-462385087)

[ZupoLlask]

Hi @adlerweb!

How's your attempt to upgrade PartKeepr to Symphony 4 is folding out?

I noticed you have merged several pending PR and you solved some issues... :-)

[adlerweb]

I only copied the patches already written by others into a merged repo to get a baseline, no code added by me so far.

I guess you are referring to my tweets about PartKeepr, so just let me clarify: I don't have enough knowledge of Symfony 4 or the techniques used here to port PK itself - I never worked with Symfony before, a large chunk of the libraries used seem to be abandoned and PK is far from a simple to understand project. I started "working" on some code for my personal use about a month ago since it's getting harder to keep systems with older PHP-versions running and the current GUI never really worked for me (ancient MDE barcode terminals). For now I got S4 to play somewhat nicely with the existing database structure and added a basic, independent GUI to get a basic subset of PKs features working. There are still some bugs due to changes inside Symfony which tend to corrupt the DB (thus no code online yet), but I think that should be solvable. But as said: No full S4 upgrade here, sorry.

[christianlupus]

This issue addresses two distinguished but related topics:

• The bug report that PHP 7.3 is causing trouble due to incompatible symphony framework
• The info that @adlerweb is thinking about symphony 4.

The afforetement is duplicated in #1065. Regadring the latter topic, I ask you @adlerweb to provide up-to-date information: Are you still working on it? Would it not be better to share resources with the main project here to avoid code duplication? If you are really thinking about collaborating/participating (in any way), would you please make a new issue?

I will close this issue as a duplicate.

[christianlupus]

Duplicate of #1065

[matthijskooijman]

@christianlupus, you closed this as a duplicate of #1065, which talks about the monolog-bundle package being out of date, but I can't quite see how this particular warning about continue is related to the monolog-bundle package?

I found a backtrace for the actual error (by adding debug_print_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS); in the ContextErrorException constructor, there were probably better ways), and found the error is triggered by the ArrayObject class in the zend framework. That indeed has a continue inside a switch that is probably affected by this warning: https://github.com/zendframework/zend-stdlib/blob/8ac0c77ff567fcf49b58689ee3bfa7595be102bc/src/ArrayObject.php#L426 This was first changed to continue 2 in https://github.com/zendframework/zend-stdlib/commit/88b2f2b0c1bea1b116378ab7f6839fdc61551b6c (changing behaviour) and then to break in https://github.com/zendframework/zend-stdlib/commit/d0cd1d043ba70feb503fb1015fbc94a6ca414056 (probably because they realized they the behaviour change was not correct).

These fixes are included in zend-stdlib 3.2.1, which is a new major version, so I'm fearful that updating to that version might bring incompatible changes rather than just this fix. Also, zend does not seem to be a direct dependency, but pulled in by guzzlehttp/guzzle, fr3d/ldap-bundle, ocramius/proxy-manager (via doctrine/migrations) (and sensio/framework-extra-bundle lists zendframework/zend-diactoros but that's dev-only and does not seem to be in the lock file). All of those seem to dictate zend < 3.0, so upgrading zend will need to upgrade all of those.

I tried fixing just this one error in ArrayObject, but then ran into further problems in zend-code, so I gave up that path.

I then tried updating some dependencies, to the latest versions (within limits specified in composer.json), hoping that this would pull in a new enough zend version. I ran:

composer update guzzlehttp/guzzle fr3d/ldap-bundle doctrine/*

But then ran into out-of-memory errors on my server (it's a bit of an old one) and gave up... In case anyone does manage to fix this, I'm happy to get my partkeepr working again :-)

[christianlupus]

I hope you are having a backup of your data... Otherwise now would be a very good point in time to think of such things as backups.

The problem is that we are completely outdated and it does not make sense to update a single dependency. In fact, this is our most pressing issue at the moment. Unfortunately, there is no easy way to do this magically. but we are on our way.

What message did you get regarding the memory problem? Did your servers OOM (out-of-memory-killer) kill PHP or was it simply the message of php that only 1.5GB (?) are exhausted? The latter can be overcome on the command line by setting the env variable COMPOSER_MEMORY_LIMIT=-1.

[matthijskooijman]

The problem is that we are completely outdated and it does not make sense to update a single dependency. In fact, this is our most pressing issue at the moment. Unfortunately, there is no easy way to do this magically. but we are on our way.

Yeah, I guess. Wanted to share my experience in case it was useful, but probably is not :-P

What message did you get regarding the memory problem? Did your servers OOM (out-of-memory-killer) kill PHP or was it simply the message of php that only 1.5GB (?) are exhausted? The latter can be overcome on the command line by setting the env variable COMPOSER_MEMORY_LIMIT=-1.

I think it was a friendly message, but I don't recall exactly. I'll keep that variable in mind, but won't be trying this again (since, as you said, it's probably not going to be sufficient anyway).