Fehler bei lokaler Installation v6.6.10

Moin!

Wenn ich lokal ein neues Projekt mit dem Befehl erstellen möchte, erhalte ich folgenden Fehler:

composer create-project shopware/production <project-name>
  - Configuring shopware/storefront (>=6.6): From github.com/shopware/recipes:main
Executing script assets:install [KO]
 [KO]
Script assets:install returned with error code 255
!!  Warning: Failed to load plugins. Message: An exception occurred in the driver: SQLSTATE[HY000] [1045] Access denied for user 'root'@'localhost' (using password: YES)
!!  Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException {#2709
!!    #message: "You have requested a non-existent service "mailer.default_transport"."
!!    #code: 0
!!    #file: "./vendor/symfony/dependency-injection/ContainerBuilder.php"
!!    #line: 1042
!!    -id: "mailer.default_transport"
!!    -sourceId: null
!!    -alternatives: []
!!    trace: {
!!      ./vendor/symfony/dependency-injection/ContainerBuilder.php:1042 { …}
!!      ./vendor/shopware/core/Content/Mail/MailerConfigurationCompilerPass.php:20 { …}
!!      ./vendor/symfony/dependency-injection/Compiler/Compiler.php:73 { …}
!!      ./vendor/symfony/dependency-injection/ContainerBuilder.php:814 { …}
!!      ./vendor/symfony/http-kernel/Kernel.php:498 { …}
!!      ./vendor/symfony/http-kernel/Kernel.php:743 { …}
!!      ./vendor/symfony/http-kernel/Kernel.php:120 { …}
!!      ./vendor/shopware/core/Kernel.php:190 { …}
!!      ./bin/console:54 {
!!        {closure:/Users/<user>/Documents/_PROJECTS/orchideen-wichmann.de/_SOURCE/shopware-flex/bin/console:19}
!!        › $application = new Application($kernel);
!!        › $kernel->boot();
!!        › 
!!      }
!!      ./vendor/autoload_runtime.php:24 { …}
!!      ./bin/console:17 { …}
!!    }
!!  }
!!  2025-02-26T11:41:04+00:00 [info] User Deprecated: Since shopware/core : The Shopware\Core\Service\Service bundle should be added to config/bundles.php
!!  2025-02-26T11:41:04+00:00 [info] User Deprecated: Since shopware/core 6.6.10.0: The fine-grained cache "tagging" configuration is deprecated and will be removed with Shopware 6.7.0.0
!!  2025-02-26T11:41:04+00:00 [critical] Uncaught Exception: You have requested a non-existent service "mailer.default_transport".
!!  
Script @auto-scripts was called via post-update-cmd

Kennt das zufällig jemand und konnte das lösen?

LG;LA

Da will das Script, wieso auch immer, wohl schon auf die Datenbank zugreifen.

Ich habe den Befehl eben lokal auf MacOS ausgeführt, gleicher Fehler.

Habe den Post in Slack gerade gepostet. Mal sehen was als Antwort kommt.

1 „Gefällt mir“

Danke Dir!

Ich hab festgestellt, dass der Fehler beim Update auch erscheint (lokal frisch v6.6.8.0 installiert und via composer update auf die neuste Version bringen wollen):

  - Upgrading shopware/storefront (v6.6.8.0 => v6.6.10.1): Extracting archive
Generating optimized autoload files
126 packages you are using are looking for funding.
Use the `composer fund` command to find out more!

What about running composer global require symfony/thanks && composer thanks now?
This will spread some 💖  by sending a ★  to the GitHub repositories of your fellow package maintainers.

Run composer recipes at any time to see the status of your Symfony recipes.

Executing script assets:install [KO]
 [KO]
Script assets:install returned with error code 255
!!  Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException {#2704
!!    #message: "You have requested a non-existent service "mailer.default_transport"."
!!    #code: 0
!!    #file: "./vendor/symfony/dependency-injection/ContainerBuilder.php"
!!    #line: 1042
!!    -id: "mailer.default_transport"
!!    -sourceId: null
!!    -alternatives: []
!!    trace: {
!!      ./vendor/symfony/dependency-injection/ContainerBuilder.php:1042 { …}
!!      ./vendor/shopware/core/Content/Mail/MailerConfigurationCompilerPass.php:20 { …}
!!      ./vendor/symfony/dependency-injection/Compiler/Compiler.php:73 { …}
!!      ./vendor/symfony/dependency-injection/ContainerBuilder.php:814 { …}
!!      ./vendor/symfony/http-kernel/Kernel.php:498 { …}
!!      ./vendor/symfony/http-kernel/Kernel.php:743 { …}
!!      ./vendor/symfony/http-kernel/Kernel.php:120 { …}
!!      ./vendor/shopware/core/Kernel.php:190 { …}
!!      ./bin/console:54 {
!!        {closure}
!!        › $application = new Application($kernel);
!!        › $kernel->boot();
!!        › 
!!      }
!!      ./vendor/autoload_runtime.php:24 { …}
!!      ./bin/console:17 { …}
!!    }
!!  }
!!  2025-02-26T12:12:43+00:00 [info] User Deprecated: Since shopware/core : The Shopware\Core\Service\Service bundle should be added to config/bundles.php
!!  2025-02-26T12:12:43+00:00 [info] User Deprecated: Since shopware/core 6.6.10.0: The fine-grained cache "tagging" configuration is deprecated and will be removed with Shopware 6.7.0.0
!!  2025-02-26T12:12:43+00:00 [critical] Uncaught Exception: You have requested a non-existent service "mailer.default_transport".
!!  
Script @auto-scripts was called via post-update-cmd

… Ich will zwar keinen Fehler auf meinem Client ausschließen, es ist aber eigentlich alles up-to-date :sweat_smile:

LG;LA

Sind anscheinend schon dran. Scheint ein Problem von/mit Symfony zu sein.

Ich frage mich, warum dieses Update (nicht lokal) am Montag ohne Probleme durchgelaufen ist und jetzt mit der Fehlermeldung " You have requested a non-existent service „mailer.default_transport“." den kompletten Shop abschiesst ?

Wird da an den Update-Scripten auch nach der Veröffentlichung noch gebastelt?

Nur im Update Fall notwendig. Installation funktioniert wieder wie gewohnt.

composer cc
rm -rf vendor
composer update

rm ist ein Löschbefehl. Darauf achten in welchem Verzeichnis man sich befindet.

1 „Gefällt mir“

composer zieht sich die von den vendor die Skripte. Nicht alle vendor sind mit einer fixen Version versehen, soviel ich weiß. Sprich Minor Updates können variieren.

Danke für die Info.
Leider bricht jetzt das Update über „shopware-installer.phar.php/update“ selbst in einer komplett neu erstellten Staging-Umgebung (im Unterordner, erstellt mittels Plugin) ab.

Was ist zu tun?

In deinen Temp ordner vom System müsste ein composer ordner existieren. Kannst du den mal löschen?

1 „Gefällt mir“

@shyim
bei einer lokalen Installation von 6.5 kommt der Fehler:

Der Fehler scheint in 6.5.8.16 in der Tat noch immer aufzutreten. Wird sicherlich gleich auch noch behoben werden.

EDIT: ist inzwischen auch behoben.

@shyim

das Löschen des Ordnerns „Composer“ auf Serverebene unter „tmp“ hat leider nichts gebracht. Es kann immer noch kein Update durchgeführt werden.

Jetzt erscheint folgender Fehler:
"
Run Update preparations
The „php-http/discovery“ plugin was not loaded as it is not listed in allow-plugins and is not required by the root package anymore.

pre-update-cmd: Symfony\Flex\Flex->configureInstaller
Loading composer repositories with package information
pre-pool-create: Symfony\Flex\Flex->truncatePackages
Updating dependencies
Dependency resolution completed in 0.000 seconds
Your requirements could not be resolved to an installable set of packages.

Problem 1
- Root composer.json requires shopware/core 6.6.10.1 → satisfiable by shopware/core[v6.6.10.1].
- shopware/core v6.6.10.1 requires shopware/conflicts 0.4.0 → found shopware/conflicts[0.4.0] but it conflicts with your root composer.json require (>=0.4.1).
Problem 2
- Root composer.json requires shopware/storefront 6.6.10.1 → satisfiable by shopware/storefront[v6.6.10.1].
- shopware/core v6.6.10.1 requires shopware/conflicts 0.4.0 → found shopware/conflicts[0.4.0] but it conflicts with your root composer.json require (>=0.4.1).
- shopware/storefront v6.6.10.1 requires shopware/core v6.6.10.1 → satisfiable by shopware/core[v6.6.10.1].

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.
"

Steht in deiner composer.json etwas hierzu?

Ich habe eben von 6.5 auf 6.6 per composer update ohne Fehler Update können.

magst du nochmal den ordner in tmp löschen und erneut probieren? müsste jetzt entgültig behoben sein

Jetzt hat das Update wieder geklappt.
Ausschlaggebend war bei uns aber das Löschen des Cache-Ordners unter „var/cache“

Dieses Thema wurde automatisch 30 Tage nach der letzten Antwort geschlossen. Es sind keine neuen Antworten mehr erlaubt.