4.4.11: Install-Tool: Call to a member function getKernel() on null

[ghost]

Issue by @timgatzky
December 29th, 2017, 10:31 GMT

In der Zip Version auf contao.org scheint es Abweichungen zum composer Paket zu geben. Das Zip quittiert das Install-Tool mit Fehlermeldung.

https://community.contao.org/de/showthread.php?69229-4-4-11-Install-Tool-Aufruf-scheitert-Call-to-a-member-function-getKernel()-on-null&p=460368#post460368

[ghost]

Comment by @leofeyer
December 29th, 2017, 11:33 GMT

Welche PHP-Version hast Du denn auf Deinem Server?

[ghost]

Comment by @Schmidty2
December 29th, 2017, 12:34 GMT

Ich hatte den Fehler ebenfalls auf zwei verschiedenen Servern, bei beiden ist PHP 7.0.25 installiert.

[ghost]

Comment by @leofeyer
December 29th, 2017, 12:41 GMT

Das könnte schon das Problem sein, denn die Zip-Datei ist mit PHP 5.6 gebaut.

[ghost]

Comment by @mlwebworker
December 29th, 2017, 12:54 GMT

Kann man das abfangen? Oder vielleicht sogar die ganz provokante Frage: Ist es wirklich sinnvoll die zip-Version weiterhin anzubieten? Um dann auch Erweiterungen nutzen zu können braucht man eh Konsole oder Manager.

[ghost]

Comment by @timgatzky
December 29th, 2017, 13:06 GMT

80% unserer Kunden installieren manuell und per Zip. Der Manager ist ein tool im Beta status und ehrlich gesagt umständlich für eine einfache Installation - aber anderes Thema.
In wiefern ist es relevant wie das Zip erstellt wurde. Die extrahierten Daten sind relevant.

[ghost]

Comment by @mlwebworker
December 29th, 2017, 13:16 GMT

Was macht Ihr bzw. Eure Kunden, wenn Erweiterungen benötigt werden?

[ghost]

Comment by @timgatzky
December 29th, 2017, 13:19 GMT

Naja, bislang muss ja erstmal das Rückgrat installierbar sein. ;)

[ghost]

Comment by @leofeyer
December 29th, 2017, 13:27 GMT

@timgatzky Bitte prüf mal, ob das Problem mit der Zip-Datei unter PHP 5.6 auch auftritt.

[ghost]

Comment by @timgatzky
December 29th, 2017, 13:30 GMT

@leofeyer Ja
Mit der Zip selbst gibts keine Probleme. Die wird entpackt und die Dateien hochgeladen. Da scheint was in der Version zu haken.

@leofeyer Exakt gleiches Verhalten unter 4.5. Quittiert ebenfalls mit besagtem Fehler

[ghost]

Comment by @fenepedia
December 29th, 2017, 14:47 GMT

Ich kann den Fehler bestätigen.
Wenn ich app_dev.php aufrufe, dann kommt unter PHP 5.6

Warning: Unsupported declare 'strict_types' in /www/htdocs/xxx/contaoacademy/demo7/vendor/league/uri-parser/src/functions.php on line 15

Parse error: syntax error, unexpected ':', expecting '{' in /www/htdocs/xxx/contaoacademy/demo7/vendor/league/uri-parser/src/functions.php on line 29

[ghost]

Comment by @fenepedia
December 29th, 2017, 14:49 GMT

Bei PHP 7.1 kommt:

Symfony\Component\Debug\Exception\FatalThrowableError:
Call to a member function getKernel() on null

  at vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Command/AssetsInstallCommand.php:106
  at Symfony\Bundle\FrameworkBundle\Command\AssetsInstallCommand->execute(object(ArgvInput), object(BufferedOutput))
     (vendor/symfony/symfony/src/Symfony/Component/Console/Command/Command.php:252)
  at Symfony\Component\Console\Command\Command->run(object(ArgvInput), object(BufferedOutput))
     (vendor/contao/installation-bundle/src/EventListener/InitializeApplicationListener.php:122)
  at Contao\InstallationBundle\EventListener\InitializeApplicationListener->runCommand(object(AssetsInstallCommand), object(ArgvInput))
     (vendor/contao/installation-bundle/src/EventListener/InitializeApplicationListener.php:58)
  at Contao\InstallationBundle\EventListener\InitializeApplicationListener->installAssets(object(InitializeApplicationEvent))
     (vendor/contao/installation-bundle/src/EventListener/InitializeApplicationListener.php:38)
  at Contao\InstallationBundle\EventListener\InitializeApplicationListener->onInitialize(object(InitializeApplicationEvent), 'contao_installation.initialize_application', object(TraceableEventDispatcher))
  at call_user_func(array(object(InitializeApplicationListener), 'onInitialize'), object(InitializeApplicationEvent), 'contao_installation.initialize_application', object(TraceableEventDispatcher))
     (vendor/symfony/symfony/src/Symfony/Component/EventDispatcher/Debug/WrappedListener.php:104)
  at Symfony\Component\EventDispatcher\Debug\WrappedListener->__invoke(object(InitializeApplicationEvent), 'contao_installation.initialize_application', object(ContainerAwareEventDispatcher))
     (vendor/symfony/symfony/src/Symfony/Component/EventDispatcher/EventDispatcher.php:212)
  at Symfony\Component\EventDispatcher\EventDispatcher->doDispatch(array(object(WrappedListener), object(WrappedListener)), 'contao_installation.initialize_application', object(InitializeApplicationEvent))
     (vendor/symfony/symfony/src/Symfony/Component/EventDispatcher/EventDispatcher.php:44)
  at Symfony\Component\EventDispatcher\EventDispatcher->dispatch('contao_installation.initialize_application', object(InitializeApplicationEvent))
     (vendor/symfony/symfony/src/Symfony/Component/EventDispatcher/Debug/TraceableEventDispatcher.php:139)
  at Symfony\Component\EventDispatcher\Debug\TraceableEventDispatcher->dispatch('contao_installation.initialize_application', object(InitializeApplicationEvent))
     (vendor/contao/installation-bundle/src/Controller/InstallationController.php:123)
  at Contao\InstallationBundle\Controller\InstallationController->initializeApplication()
     (vendor/contao/installation-bundle/src/Controller/InstallationController.php:55)
  at Contao\InstallationBundle\Controller\InstallationController->installAction()
     (vendor/symfony/symfony/src/Symfony/Component/HttpKernel/HttpKernel.php:151)
  at Symfony\Component\HttpKernel\HttpKernel->handleRaw(object(Request), 1)
     (vendor/symfony/symfony/src/Symfony/Component/HttpKernel/HttpKernel.php:68)
  at Symfony\Component\HttpKernel\HttpKernel->handle(object(Request), 1, true)
     (vendor/symfony/symfony/src/Symfony/Component/HttpKernel/Kernel.php:202)
  at Symfony\Component\HttpKernel\Kernel->handle(object(Request))
     (web/app_dev.php:65)

[ghost]

Comment by @timgatzky
December 29th, 2017, 16:03 GMT

Der Fehler entsteht durch eine geänderte Symphony Version in 4.4.11 z.B. gegenüber 4.4.8 mit dem ich getestet habe.

4.4.11: vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Command/AssetsInstallCommand.php, Zeile 107 definiert die Variable $kernel über ->getApplication()
Das scheitert, weil Contao vorab $this->application nicht definiert.

in 4.4.8 wird $kernel quasi noch über $this->getContainer()->get('kernel'); angesprochen.

Das ist der Unterschied. Gilt ebenfalls für 4.5

Frage: Warum ändert Contao in einem Bugfix-Release die Symphony-Version. Symphony ist zum Rückgrat Contaos geworden. Sollte dies nicht durch ein Minor-Release klassifiziert werden? (wäre damit für 4.5 ok, aber nicht für 4.4.11)
Im changelog findet sich ebenfalls keine Information dazu.

[ghost]

Comment by @mlwebworker
December 29th, 2017, 23:48 GMT

Ich möchte hier noch auf einen zweiten Thread im Forum hinweisen https://community.contao.org/de/showthread.php?69237-Installation-Contao-4-5-scheitert. Auch dort geht es um eine Installation mit der zip-Version, die diesen Fehler zeigt. Alle Tester die über Manager oder Konsole gearbeitet haben, haben diesen Fehler nicht und @planepix hat es sogar eindeutig reproduzieren können.

[ghost]

Comment by @fritzmg
December 31st, 2017, 10:31 GMT

Frage: Warum ändert Contao in einem Bugfix-Release die Symphony-Version.

Symfony wird mit ^3.3 required. Theoretisch sollten da keine Änderungen kommen, die nicht rückwärtskompatibel sind.

[ghost]

Comment by @timgatzky
January 2nd, 2018, 12:51 GMT

Der Fehler ist glasklar durch die Änderung in den Symphony Dateien aufzeigbar. Mag sein, dass der composer inzwischen andere Dateien saugt als das zu der Zeit als das Zip gepresst wurde. In diesem Fall muss das Zip frisch gepresst werden und neu bereitgestellt werden. Dies betrifft beide genannten Contao Versionen, da das installer-bundle quasi identisch ist.

[ghost]

Comment by @fritzmg
January 2nd, 2018, 12:54 GMT

@timgatzky schon klar. Ich wollte nur erwähnen, dass sich bei einem neuen Contao minor oder bugfix release zwar durchaus die Symfony Version ändern kann - aber wenn dann nur die minor Version.

[ghost]

Comment by @dmolineus
January 2nd, 2018, 13:00 GMT

Auch wenn es optimaler Weise keine BC Breaks geben sollte in minor Versionen, so ist symfony 3.4 ja gerade ein Beispiel davon, dass es vorkommt. Allein die Umstellung auf private Services per Default ist bei der Verwendung des Containers als Service Locator mittels importStatic() in Contao problematisch. Daher ist es ggf. zu diskutieren, ob man Container nicht auf eine Bugfix Version von symfony festpinnen sollte.

[ghost]

Comment by @timgatzky
January 2nd, 2018, 13:02 GMT

@fritzmg Das Contao durch seinen vorgeplanten Release-Plan seinem eigenen Kredo was ein Bugfix-Release und was ein Minor-Release ist, nicht gerecht werden kann, wissen wir ja schon. Seit Contao 4 ist Symphony Contaos Rückgrat geworden ist, kann Contao keine Bugfix-Releases mehr herausgeben, wenn sich die Symphony-Version selbst nicht in einem Bugfix-Release Stadium befindet (vorausgesetzt, die gehen konsequenter an die Sache)

@dmolineus Jup, wie David sagt. Contao schützt sich selbst, wenn es bei einer bestätigten und geprüften Symphony-Version bleibt. Falls nicht, muss seitens Contao höher geprüft werden.

Auch sollte das gesamte fixe Release-Plan-Konzept eingestampft werden. Wie man sieht kann man nicht vorher absehen wie lange man Bugfixes schiebt. Sobald innerhalb eines "Bugfix" Releases keine Kompatibilität mehr herrscht, kann es nur noch ein neues Minor werden. Das bezieht sich auch auf die Datenbankstruktur, da in diesem Fall z.B. Installations-Templates nicht mehr kompatibel wären oder externe Erweiterungen.

[ghost]

Comment by @fritzmg
January 2nd, 2018, 13:04 GMT

@fritzmg Das Contao durch seinen vorgeplanten Release-Plan seinem eigenen Kredo was ein Bugfix-Release und was ein Minor-Release ist, nicht gerecht werden kann, wissen wir ja schon.

In wie fern?

[ghost]

Comment by @timgatzky
January 2nd, 2018, 13:10 GMT

@fritzmg Das Contao durch seinen vorgeplanten Release-Plan seinem eigenen Kredo was ein Bugfix-Release und was ein Minor-Release ist, nicht gerecht werden kann, wissen wir ja schon.
In wie fern?

Auch sollte das gesamte fixe Release-Plan-Konzept eingestampft werden. Wie man sieht kann man nicht vorher absehen wie lange man Bugfixes schiebt. Sobald innerhalb eines "Bugfix" Releases keine Kompatibilität mehr herrscht, kann es nur noch ein neues Minor werden. Das bezieht sich auch auf die Datenbankstruktur, da in diesem Fall z.B. Installations-Templates nicht mehr kompatibel wären oder externe Erweiterungen. Ich erninnere an ein Bugfix-Release 3.5.8, dort wurden Änderungen an der tl_search getätigt, die zum Ausfall von Installations-Templates etc. geführt haben. Dies wäre ein Minor-Release und hätte Contao auf 3.6.0 gehoben, da das 3.5er Material nicht mehr kompatibel wäre. Weitere Minor-Releaes sind aber im Release-Plan nicht vorgesehen?! -> das ist ein großes Problem.
Auch würde der Druck abfallen zu fixen Zeiten fixe Versionen zu feuern.

[ghost]

Comment by @fritzmg
January 2nd, 2018, 13:18 GMT

Ich kann das Problem ebenfalls mit dem herunterladbarem Archiv von contao.org lokal unter PHP 7.1 reproduzieren.

[leofeyer]

Behoben in dd4006b.

[timgatzky]

Wie sieht es aus? Wird Contao die Symphony Version festpinnen, wie es von David vorgeschlagen wurde?