CLI Datenbank Zugriff - config.php falsch?

Shopware 5 Installation/Einstieg
1

Hallo liebes Forum,

ich komme leider nicht mehr weiter. Habe gefühlt schon jeden Thread zum Thema drei mal gelesen und es hat trotzdem nichts geholfen.

Ich habe das Problem, dass ich Shopware geupdatet habe und nun die Bilder nur in der alten Ordnerstruktur vorliegen. Ist ja kein Problem, es gibt ja den CLI-Befehl

sw:media:migrate

 Leider funktioniert der allerdings nicht. Es funktioniert aber auch kein anderer. Wenn ich 

bin/console sw:plugin:list --help

bekomme ich zwar die Liste angezeigt, wenn auch nicht vollständig, glaube ich. Aber ich bekomme auch verschiedenste Fehlermeldungen z.B.:

WARNING! Could not connect to database. Message from SQL Server: SQLSTATE[HY000] [2002] No such file or directory in /is/htdocs/XXXXXXX/engine/Shopware/Components/DependencyInjection/Bridge/Db.php

Nach den Fehlermeldungen habe ich nun schon einige Zeit hier im Forum gesucht und auch ansonsten im Netz gesucht. Ohne Erfolg.

Meine config.php sieht folgendermaßen aus:

        array (
            'host' => '127.0.0.1',//'wpXXXXXX.server-he.de', //80.237.XXX.29 '127.0.0.1','localhost'
            'port' => '3306',
            'username' => 'dbXXXXXX-dev1',
            'password' => 'XXXXXXXX',
            'dbname' => 'dbXXXXXX-dev1',
        ),
);

Ich habe also schon alle mir bekannten Kombinationen für den „host“ ausprobiert. Der Server liegt bei HostEurope und ich habe die Datenbanken auch so eingestellt, dass sie theoretisch von extern erreichbar sind. Dies habe ich auch schon ausprobiert, dass das klappt. Nur halt nicht über ssh und dem CLI. Der Port ist auch der richtige.

Folgende Fehlermeldungen kann ich produzieren:

 'host' =\> 'wpXXXXXX.server-he.de':

WARNING! Could not connect to database. Message from SQL Server: SQLSTATE[HY000] [2002] php_network_getaddresses: getaddrinfo failed: Name or service not known in /is/htdocs/XXXXXX/engine/Shopware/Components/DependencyInjection/Bridge/Db.php

 'host' =\> '127.0.0.1':

 'host' =\> '80.237.XXX.29':

 'host' =\> 'localhost':

WARNING! Could not connect to database. Message from SQL Server: SQLSTATE[HY000] [2002] Connection timed out in /is/htdocs/XXXXXX/engine/Shopware/Components/DependencyInjection/Bridge/Db.php

Lustiger weise funktionieren alle Host-Einstellungen für das Frontend und Backend. Die Fehlermeldungen sind auch nicht abhängig von der verwendeten Shopware-Version. Die entstehen in allen Versionen. Also würde ich denken, dass bei HostEurope was schief hängt. Ich habe denen auch schon mal wegen der Problematik geschrieben, leider aber immer noch keine Antwort erhalten.

Ich weiß hier einfach nicht mehr weiter. Vielleicht liest dies ja einer, der auch bei HostEurope ist?

Würde mich echt sehr über Hilfe freuen, da ich daran ziemlich verzweifle.

Beste Grüße

Björn

2

Hallo Björn,

hast Du auf der Console evtl. eine andere PHP-Version als über den Webserver?

$ php -v

Evtl. musst Du diese explizit aufrufen.

php5-6 bin/console

Nach Änderung der config.php solltest Du den Konfigurationscache löschen oder den kompletten über das var/cache/clear_cache.sh. Erst dann werden die Änderungen verlässlich übernommen.

 

Viele Grüße

Marc

 

MND Next GmbH

Jetzt neu im Plugin Store: Plugin MND Monitoring Basic

www.mndnext.de | MND Next auf Facebook

1 „Gefällt mir“
3

Hi Marc,

vielen Dank für deine Antwort.

Du meinst ich soll “var/cache/clear_cache.sh” in der Console ausführen, richtig? Das führt zu folgender Fehlermeldung:

WARNING! Could not connect to database. Message from SQL Server: SQLSTATE[HY000] [2002] Connection timed out in /is/htdocs/wp1093988_KUQ3VXFG9G/www/gourvino_sw_de_dev1/engine/Shopware/Components/DependencyInjection/Bridge/Db.php 

                                                                                                                  
[Symfony\Component\DependencyInjection\Exception\RuntimeException]                                              
You have requested a synthetic service ("db_connection"). The DIC does not know how to construct this service.

Was bedeutet das?

Wenn ich nach clear-cache “php ./bin/console list” bekomme ich wieder wie gewohnt die Fehlermeldungen  Crying

“php -v” führt zu PHP 5.6.28. PHP 5.6.4 wäre wahrscheinlich besser, richtig?

Beste Grüße

Björn

4

Ansonsten sieht es so aus als würde der Cache geleert werden.

5

Ja, das clear_cache.sh ruft am Ende die shopware console auf um die proxy-Dateien neu zu generieren. Dadurch der Fehler.

Die PHP Version sollte die selbe sein, wie die vom Webserver. Du kannst im Zweifel im Shopware Backend über Einstellungen -> Systeminfo -> Tab: PHP-Info aufrufen und dort schauen. Es ist auch denkbar, dass in der PHP-Version der CLI andere Module einkompiliert sind.

Bei Host-Europe bin ich mir jetzt nicht sicher (ist das ein Webspace, Managed-Server oder Root-Server?). Meistens gibt es, wenn du php und zweimal die tab taste Drückst eine Übersicht der Programme die mit php Beginnen. Da dürfte dann etwas dabei sein wie php-56 o.ä.

Wenn der Shop vorher mit der 127.0.0.1 funktioniert hat, würde ich es auch dabei belassen. Bei localhost ist es möglich, dass versucht wird eine Socket-Verbindung aufzubauen, was in einigen chroot Umgebungen nicht funktioniert.

Ansonsten stehe ich jetzt gerade auch auf dem Schlauch. Evtl. ist in der CLI-Umgebung noch mehr eingeschränkt? Kannst Du mit mysql-Kommando eine Verbindung zur Datenbank aufbauen?

 

Viele Grüße

Marc

 

MND Next GmbH

Jetzt neu im Plugin Store: Plugin MND Monitoring Basic

www.mndnext.de | MND Next auf Facebook

1 „Gefällt mir“
6

Hi Marc,

vielen Dank für Deine Bemühungen.

„php zweimal Tab“ zeigt die Befehle an. Habs dann mit php5.6 ausprobiert. „Connection timed out“.

Die PHP-Versionen sind übrigens auch nicht gleich. einmal 5.6.28 und 5.6.31. Strange.

Es ist ein Webspace und da liegt der Hund wahrscheinlich begraben. Zufällig ist mir gerade folgendes über den Weg gelaufen:

Die folgenden Features sind ab unserem WebServer möglich:

  • …
  • Kommandozeilen Zugriff auf MySQL Datenbanken

Das scheint also bei WebSpace nicht möglich zu sein, sondern erst ab WebServer. Vollkommen Banane warum HostEurope mir das nicht schon längst geschrieben hat  Crying Aber das düfte es wohl sein, oder?
Das ist dann ziemlich unterdurchschnittlich, denn nun weiß ich nicht, wie ich die Bilder in die neue Ordnerstruktur migriert bekomme? Verstehe auch nicht warum das nicht automatisch passiert ist. Bei einem anderen Update hatte das schon mal geklappt. Aber beim gleichen Shop auf 5.3 nicht. Gibt es noch andere Möglichkeiten?

Hatte übrigens von 5.0.4 auf 5.3 geupdatet, was natürlich ein ziemlicher Sprung ist. Es wurde auch angezeigt, dass das geht und es keine Plugin-Probleme gibt. Stimmt auch, nur Bildprobleme  Undecided Bleibt mir dann nichts anderes übrig als erstmal von 5.0.4 auf 5.1.X und dann auf 5.3.1 (mittlerweile) upzudaten oder wie ist da die beste Vorgehensweise?

Beste Grüße

Björn

7

Hallo Björn,

mit Deiner Vermutung wg. Webserver hast Du vollkommen recht. Host Europe bietet für “WebHosting” zwar einen SSH-Zugang an, der ist aber über einen SSH-Proxy realisiert und alles, was auf die Datenbank zugreift, ist damit eben nicht möglich. D.h. die ganze CLI von Shopware kannst Du da vergessen.

Ich denke, dass ein WebHosting-Paket für Shopware ehrlich gesagt nicht geeignet ist. Wir machen bei HE aber sehr gute Erfahrungen bereits mit dem WebServer-Basic-Paket. MySQL-Datenbank auf SSD und APCu-Cache sind schon mal eine gute Grundlage für Shop-Performance.

Wg. Update auf 5.3 - was meinst Du denn für Bild-Probleme?

Viel Erfolg,

Geert

2 „Gefällt mir“
8

Hi Geert,

stimmt, dazu hatte ich noch gar nichts geschrieben.

Also folgendes Problem ist aufgetreten:

Beim Update auf 5.3 sind die Bildpfade zwar in die neue “gehashte” Ordnerstruktur umgewandelt worden, die Bilder liegen aber physisch noch in der alten Struktur. D.h. das sie in der Datenbank in der neuen Struktur abgelegt worden sind und der Server sie nun nicht an der neuen Stelle finden kann. Weder im Backend noch im Frontend. Kann also auch keine Thumbnails neu generieren oder so…
Ich hatte nun angenommen, dass dies durch Ausführung von “sw:media:migrate” lösen zu können. Da ich das CLI aber nun nicht verwenden kann, frage ich mich wie ich das sonst lösen soll / kann? Gibt es noch andere Möglichkeiten und warum ist das überhaupt schief gelaufen? Kann ja so nicht gewollt sein? 

Beste Grüße

Björn

9

Hi Björn,

guter Punkt. Ich kann mich nicht erinnern, dass wir bei den Bildern mit 5.0 -> 5.1 Probleme hatten. Ich dachte bis jetzt, dass die Umstellung der Bilder dynamisch bei erster Verwendung im FE passiert (http://community.shopware.com/Medienverwaltung\_detail\_781.html)

Ab Shopware 5.1

 

Ordnerstruktur

Medien werden nicht mehr in einem einzigen Ordner abgelegt, sondern es wird ein Hash genutzt, aus dem sich die Ordnerstruktur ergibt, zum Beispiel /media/image/1d/4a/8c/meinBild.jpg. Nach dem Update auf Shopware 5.1 werden alle Bilder bei Aufruf im Frontend einmalig in die neue Struktur importiert. Alternativ geht das auch über einen Konsolenbefehl, den Du im Bereich der Konsolentools findest.

Das würde erklären, warum Du nach dem Update erstmal keine Änderung in der Directory-Struktur siehst. Hast Du mal probiert, ein paar Bilder im Frontend zu laden (z.B. über die Listings oder Detailseite) und geschaut, ob was passiert?

Bleibt die Frage [@Shopware Developer](http://forum.shopware.com/profile/18563/Shopware Developer „Shopware Developer“)‍ , ob diese „Dynamik“ vielleicht in 5.3 nicht mehr drin ist?

Viel Erfolg!

Geert

1 „Gefällt mir“
10

Hi Geert,

ich habe jetzt auf die alte Ordnerstruktur umgestellt:

https://developers.shopware.com/developers-guide/shopware-5-media-service/

'cdn' => [
        'adapters' => [
            'local' => [
                'type' => 'local',
                'mediaUrl' => '',
                'strategy' => 'plain',
                'path' => realpath( __DIR__. '/'),
                'permissions' => [
                    'file' => [
                        'public' => 0666 & ~umask(),
                        'private' => 0600 & ~umask(),
                    ],
                    'dir' => [
                        'public' => 0777 & ~umask(),
                        'private' => 0700 & ~umask(),
                    ]
                ],
            ],
            'old_local' => [
                'type' => 'local',
                'mediaUrl' => '',
                'path' => realpath( __DIR__. '/'),
                'permissions' => [
                    'file' => [
                        'public' => 0666 & ~umask(),
                        'private' => 0600 & ~umask(),
                    ],
                    'dir' => [
                        'public' => 0777 & ~umask(),
                        'private' => 0700 & ~umask(),
                    ]
                ],
            ]
        ]
    ]

Dann werden die Bilder im Frontend wie im Backend auch wieder geladen. Beim ersten Aufruf usw. hat jedenfalls nichts gebracht. Ich könnte mir auch vorstellen, dass da irgendwas verloren gegangen ist zwischen 5.1 und 5.3. Wobei mir bestätigt wurde, dass es den Consolen-Befehl zum umwandeln noch gibt, der aber bei mir ja nun mal nicht funktioniert.

Ich werde weiter probieren und forschen und hier berichten. Vielleicht hilft es ja irgendwann einmal wem…

Vielen Dank noch mal an Geert und Marc 

Beste Grüße

Björn

11

Du kannst die Live-Migration auch wieder aktivieren, diese ist ab 5.3 Standardmäßig deaktiviert.

'cdn' => [
    'liveMigration' => true,
]

Dann werden die Bilder bei Aufruf migriert.

1 „Gefällt mir“
12

Verdammte Axt, das geht  Grin

Ist das irgendwo dokumentiert?  Wink Habe mir tagelang nen Wolf gesucht und nichts gefunden. Drei Zeilen Code und alles ist heile  Thumb-Up

Es scheint noch nicht alles “in trockenen Tüchern” zu sein, aber das hilft schon mal stark weiter. Vielen Dank!

Denke, mein Problem ist hiermit behoben  Thumb-Up Hoffe, es hilft irgendwann mal jemandem!

Beste Grüße

Björn