[Fehler][6.6.3.0] Media-URL in Zwischenablage kopieren

Hallo,

In einem Shop besteht das Problem, dass der URL-Link des gewählten Bildes nicht Kopiert werden kann.
Leider finde ich hierzu keinen Lösungsansatz.
Es gibt keinen anderen Hinweis außer die im Bild zu sehende Fehlermeldung. (Logs/Konsole/Netzwerkanalyse bereits geprüft…)
grafik

Kennt hier jemand die Problematik und hat eventuell eine Lösung?
(Es muss nicht gleich ein Update sein)

Hm, mir völlig unbekannt dieses Verhalten. Betrifft das alle Bilder oder nur bestimmte? Sind denn die Bilder korrekt in der Übersicht zu sehen? Haben die Bildnamen ggf. Umlaute oder Sonderzeichen?

Es betrifft alle Bilder (*Normale Formatierung und Sichtbar)
der Link sollte also richtig hinterlegt sein, nur der Knopf geht nicht.

Mir ist zusätzlich aufgefallen, das bei anderen Kunden der selbe Fehler besteht.
Hier ist wichtig zu erwähnen, das der Fehler Versionsunabhängig ist.
Bis jetzt nutzen allerdings alle Kunden den selben Hoster.
Einer der getesteten Kunden nutzt einen anderene Hoster, allerdings auch SW Version 6.5.8.8
Hier geht es, bringt allerdings nur wenig Klarheit.

Ich telefoniere jetzt gleich mal mit dem Hosting-Provider, vielleicht weiß ich danach mehr.

Neue informationen:
Bis zur Shopware Version 6.5.8.8 funktioniert noch alles, darüber keine Chance.

Ich konnte zumindest einen Fehler identifizieren.
Wenn ich auf einen Media-Files-Ordner in Sektion Medien klicke, erhalte ich folgenden Fehler in der Console:

XHR POST
http://MeineDomain.de/api/search/media-default-folder
[HTTP/1.1 400 Bad Request 200ms]

Uncaught (in promise) 
Object { message: "Request failed with status code 400", name: "AxiosError", code: "ERR_BAD_REQUEST", config: {…}, request: XMLHttpRequest, response: {…}, stack: "" }
​
code: "ERR_BAD_REQUEST"
​
config: Object { timeout: 0, xsrfCookieName: "XSRF-TOKEN", xsrfHeaderName: "X-XSRF-TOKEN", … }
​
message: "Request failed with status code 400"
​
name: "AxiosError"
​
request: XMLHttpRequest { readyState: 4, timeout: 0, withCredentials: false, … }
​
response: Object { data: {…}, status: 400, statusText: "Bad Request", … }
​
stack: ""
​
<prototype>: Object { constructor: r(e, t, n, i, r), toJSON: toJSON(), stack: "", … }

Kann ich bestätigen, das funktionierte mal aber ist jetzt irgendwie kaputt.

Hat hierzu jemand eine Lösung?

Habe dasselbe Problem, habe nun ein Bug submitted. Bitte VOTED damit es auch mal gefixt wird

NEXT-37356

Kann mich nur anschließen.
Das Ticket wurde als Duplikat geschlossen.
Bitte diesen hochdrücken :slight_smile:
NEXT-37355

Habe das Problem ebenfalls in Version 6.6.8.2.

Hat jemand bereits eine Lösung dafür ?

Das ist kein allgemeines Shopware-Problem. Bei uns hat das immer einwandfrei funktioniert.
Das ist entweder eine Wechselwirkung mit einem Plugin oder ein anderer JS-Fehler im Backend, der die Ausführung blockiert.

Kann ich bestätigen, in einem 6.6.8.2 Testshop probiert, läuft.

Eventuell Browserproblem, mal anderen Browser probiert?

6.5.8.2 und 6.6.7.1 keine Probleme in Firefox und Chrome.

Habe es mit Chrome und FIrefox getestet. Leider bei beiden der gleiche Fehler.
Wie kann ich herausfinden woran es liegt?

Zeigt denn die Browser-Console was an (Entwickler-Tools)?

Hi, bei uns ist heute der gleiche fehler aufgetreten (shopware6.6.6.1)
Komischerweise nicht beim kopieren der medien-url (das funktioniert problemlos) sondern beim laden einer Bilddatei in der config für ein neues custom cms element.
Da öffnet sich zwar das modal, aber die dateien im ordner werden nicht geladen.
Habe nach vergeblicher fehersuche dann mal den watch-admin gestartet, um mir die source-maps anzeigen zu lassen.
Da lässt sich der fehler zumindest ein bisschen besser nahvollziehen. Kommt wohl aus der datei /src/app/asyncComponent/media/sw-media-folder-item/index.js also einer shopware-datei.
Da sollten wohl eigentlich die ordner-IDs bearbeitet werden, funktioniert aber nicht richtig (außer scheinbar im standard-ordner, wenn man in der session bisher noch keinen anderen ordner geöffnet hat, da funktioniert das ganze).
Daher bleibt dann bei dem request, der den eigentlichen fehler auslöst, das feld „ids“ leer → bad request.
Wenn niemand weiß wie man das umgeht (und davon gehe ich mal aus) müssen wir wohl auf einen offiziellen fix warten.