MediaService: Migration zurück zu "plain"

Ich wollte gerade in unserem Testshop mal den Weg zurück zu „plain“ durchspielen wie hier beschreiben:
MediaService

Die config.php hab ich so ergänzt wie beschrieben.
Da muss nichts anderes mehr eingetragen werden in dem Code, oder?

),

‚cdn‘ => [
    ‚adapters‘ => [
        ‚local‘ => [
            ‚type‘ => ‚local‘,
            ‚mediaUrl‘ => ‚‘,
            ‚strategy‘ => ‚plain‘,
            ‚path‘ => realpath(__DIR__ . ‚/‘)
        ],
        ‚old_local‘ => [
            ‚type‘ => ‚local‘,
            ‚mediaUrl‘ => ‚‘,
            ‚path‘ => realpath(__DIR__ . ‚/‘)
        ]
    ]
]

);

Nach der Ausführung von 

bin/console sw:media:migrate --from=old_local --to=local

erhalte ich eine Fehlermeldung:

PHP Notice:  Undefined index: permissions in /…/engine/Shopware/Bundle/MediaBundle/Adapters/LocalAdapterFactory.php on line 40
PHP Fatal error:  Uncaught TypeError: Argument 4 passed to League\Flysystem\Adapter\Local::__construct() must be of the type array, null given, called in /…/engine/Shopware/Bundle/MediaBundle/Adapters/LocalAdapterFactory.php on line 40 and defined in /…/vendor/league/flysystem/src/Adapter/Local.php:71
Stack trace:
#0 /…/engine/Shopware/Bundle/MediaBundle/Adapters/LocalAdapterFactory.php(40): League\Flysystem\Adapter\Local->__construct(’/var/www/client…’, 2, 2, NULL)
#1 /…/engine/Shopware/Bundle/MediaBundle/MediaServiceFactory.php(122): Shopware\Bundle\MediaBundle\Adapters\LocalAdapterFactory->create(Array)
#2 /…/engine/Shopware/Bundle/MediaBundle/MediaServiceFactory.php(81): Shopware\Bundle\MediaBundle\MediaServiceFactory->getAdapter(Array)
#3 /…/engine/Shopware/Bundle/MediaBundle/Commands/ImageMigrateCommand.php in /…/vendor/league/flysystem/src/Adapter/Local.php on line 71

Hab ich irgendwas übersehen, weshalb das nicht funktioniert?
Shopversion 5.2.12

Hat niemand eine Idee, weshalb die Migration nicht startet und eine Fehlermdlung ausgibt?

Leider keine Idee, nur eine Frage: warum?

Was warum?

Warum?

Migration zurück zu „plain“

Wir haben aufgrund der geringen Anzahl an Bildern keine Vorteile, die Bilder in „hundertausend“ verschiedenen Verzeichnissen zu haben, nur Nachteile durch die ständige Sucherei von Bildern.

Alles klar, leider keine Idee was das Problem ist.

Mir fällt jedoch kein Grund ein warum man die Bilder im Filesystem überhaupt suchen und nicht die Verwaltung einfach dem MedienManager überlassen sollte.

Ich hab’s heute erneut versucht und es hat geklappt mit der Migration.
Natürlich erst mal in unserem Testshop.

Frage:
Funktioniert die Weiterleitung der Bilderpfade von vor der Migration (md5) zu den neuen Bilderpfaden (plain) dann genauso wie die Weiterleitung von plain zu md5?
Ich hab’s getestet, bekomme aber ein 404-Seite und eine URL, die unser Unterverzeichnis doppelt in der URL hat www.domain.de/xyz/xyz/

@simplybecause schrieb:

I

Frage:
Funktioniert die Weiterleitung der Bilderpfade von vor der Migration (md5) zu den neuen Bilderpfaden (plain) dann genauso wie die Weiterleitung von plain zu md5?
Ich hab’s getestet, bekomme aber ein 404-Seite und eine URL, die unser Unterverzeichnis doppelt in der URL hat www.domain.de/xyz/xyz/

Nein, das funktioniert nicht. Daher gibt es ja den 404-Error. Die Umleitungen musst Du selber erstellen und aufpassen keine Endlosredirect-Schleifen für Links zu produzieren , die sich noch im Google-Index befinden. Falls die Links im Google-Index egal sind, kann man die auch in einen 404-Error laufen lassen. Mit der Zeit entfernt Google diese dann selbst.

 

 

Hmm, das hatte ich befürchtet.
Hat jemand eine Idee, wie ich am einfachsten an alle Bilder-URLs rankomme?

@simplybecause schrieb:

Hmm, das hatte ich befürchtet.
Hat jemand eine Idee, wie ich am einfachsten an alle Bilder-URLs rankomme?

Artikelbilder etc. werden von Shopware behandelt. Redirects müssen für die Bilder in Kategorietexten, HTML-EK-Elementen etc. erstellt werden. Wenn für jedes Bild ein individueller Redirect erstellt werden soll, muss man die aus der DB selektieren oder die Seite per Skript crawlen. 

Ich stelle die Weiterleitung allerdings für unsere Kunden mit Rewrite Rules sicher. Das kann ich auch nur empfehlen.

Viele Grüße

 

Jepps, für jedes Bild soll ein idividueller Redirect erstellt werden.
Danke für den Wink mit dem Crawler. :wink:
Hab hier noch ein Tool zum Crawlen des Shops und das gibt mir alle Bilder-URLs.
Dabei ist mir aufgefallen, dass das Bild 3 und das Original nicht gecrawlt wird.
Ist im Demoshop auch so.

Schade eigentlich.
 

Die Config ist hier etwas unglücklich. Aus dem gelinkten Beispiel muss auch das Array mit den Permissions übernommen werden, da es sonst zu dem besagten Fehler kommt. Wir haben die Doku mittlerweile angepasst.

LG, Jan

Mit der aktuellen Version für die config.php hat es ja jetzt auch funktioniert. :slight_smile:

Ich hab nun den Bilderpfad geändert und für so ziemlich alle Bilder ein Redirect gemacht.
Bei fehlenden Redirects wird folgendes in core_production-xxx.log eingetragen:

[Datum Uhrzeit] core.INFO: Legacy media url detected. {“requestedUrl”:"/media/image/51/1b/e4/datei.png",“redirectedTo”:“domain.de/media/image/51/1b/e4/datei.png”} {“uid”:“1736be2”}

Warum wird da eine Weiterleitung auf sich selbst gemacht und nicht ein Fehler 404 ausgeben?
Stattdessen wird Fehler 301 mit der Browseranzeige ausgegeben:
“Die aufgerufene Website leitet die Anfrage so um, dass sie nie beendet werden kann.”

Hab ich eine Einstellung übersehen?
Kann man die automatische Weiterleitung deaktivieren?

Du kannst die .htaccess im /media/-Ordner löschen, wenn du die Weiterleitung nicht möchtest.

Klingt simpel. :wink:
Hab mal TimmeHosting angeschrieben, was wir in den Einstellungen entfernen müssen.