Inxmail / inx_magento1

Inxmail Professional Email Marketing für Magento CE und EE (1.x)
0 stars 0 forks source link

Flush von Magento-Cache führt zu Verlust von Produkt-Bildern [INX-30] #1

Closed falco-knapp closed 8 years ago

falco-knapp commented 9 years ago

Infos zu Magento - poduct feeds - Bilder in Mailings:

Bilder in Produkt-Feeds aus Magento, die über das Template in Mailings eingebunden werden können, sind im Image Cache von Magento abgelegt. Magento skaliert jedes Produktbild und legt es im Images Cache-Verzeichnis ab. Dadurch können über den Produkt-Feed Bilder in geeigneter Größe bereitgestellt werden. Die Bild-URLs enthalten einen dynamischen Teil, der jeweils beim Speichern des Bilds im Cache erzeugt wird.

Die Bilder sind dort vorhanden, solange nicht aktiv ein Refresh des Caches im Magento-Backend angestoßen wird. Das ist offensichtlich bei einem Kunden erfolgt, dort wurden Bilder nicht mehr angezeigt.

Gelöst werden kann das nur durch Aktualisierung des Product Feed im Mailing, so dass wieder gültige Bild-URLs verwendet werden. Das ist ja aber nicht möglich, wenn das Mailing bereits versendet wurde.

Vielleicht ist das Ganze kein Problem, weil kein Magento-Admin auf den Button zum Flush Images Cache klickt (unter System > Cache Management). Vielleicht gehört es aber auch zur Pflege eines Magento-Shops, ab und an einen Refresh des Caches auszulösen. Dann wäre diese Lösung für E-Mail-Marketing nicht wirklich geeignet.

falco-knapp commented 9 years ago

Flagbit: normalerweise werden Cache-Flushes verboten. Allerdings muss dies bei Deployments meist durchgeführt werden.

Lösung wahrscheinlich: "Cache" für Inxmail Bilder müssen separat ausgespielt werden. ca. 5 Tage

falco-knapp commented 8 years ago

Hallo Björn,

ein weiterer Kunde hat sich an uns gewendet um auf das Problem aufmerksam zu machen und hat folgenden Lösungsvorschlag genannt:

ich habe bei uns jetzt folgenden Workaround eingesetzt, evtl. lässt sich dies ja nachprogrammieren:

Das Plugin forder bei Magento eine Datei an, welche für den Newsletter abgelegt werden soll.

Magento organisiert diese Anforderungen alle in einem Ordner, da die Bildgrößen konstant gleich sind.

Ich habe nun ein Cronscript auf unserem Webserver eingerichtet, welches diese erzeugten Bilddaten in einen eigenen Ordner kopiert.

Dabei bleibt die Struktur nach unten erhalten und nur der Ordnername „cache“ wird durch den Ordnernamen „inxmail“ ersetzt.

Beispiel: http://inxmail-kunden-shop.de//shop/media/catalog/product/cache/1/image/500x710/9df78eab33525d08d6e5fb8d27136e95/5/6/562351_cover.jpg

http://inxmail-kunden-shop.de/shop/media/catalog/product/inxmail/1/image/500x710/9df78eab33525d08d6e5fb8d27136e95/5/6/562351_cover.jpg

Wäre es möglich, dass sie, in dem übergebenen Pfad von Magento den Ordnernamen ersetzen?

Wir würden das Script jede Minute laufen lassen, so dass Bilder spätestens nach 60sekunden in Inxmail sichtbar sein sollten.

Der Vorteil wäre, dass bei einem Abschlöschen des Caches die Bilder von Inxmail unberührt bleiben und eine dauerhafte funktionsweise garantiert ist.

Danke für eine Einschätzung und viele Grüße

Der Nachteil dieser Lösung ist, dass der E-Mail Marketing Redakteur mit der Verzögerung von bis zu 60 Sekunden rechnen muss bis die Bilder überhaupt dargestellt werden - nach kurzer interner Abstimmungen scheint uns dies als nicht akzeptabel. Daher wäre meine Lösungsidee

  1. Request auf Product-Feed wird durchgeführt.
  2. Bild wird mit Bordmitteln erstellt (also mit dem Cache-Mechanismus)
  3. Die Verarbeitungslogik kopiert nun aber (zum Request-Zeitpunkt) das Bild in ein separates Verzeichnis (ähnlich wie oben - nur beim erstmaligen anlegen des Bildes)
  4. Die Verarbeitungslogik liefert nun als ImageUrl den Pfad des kopierten Bildes statt des Bildes im Cache Verzeichnis.

Welche Konsequenzen sehe ich:

  1. Wir das Produktbild geändert, müsste sich auch der Cache-Wert ändern, also ein neues Bild existieren. Dies wiederum bedeutet dass es dann 2 oder mehr Versionen eines Produkt-Bildes geben könnte. Ist dies Problematisch? Nein, denn das Mailing sollte sich wie zum Redaktionszeitpunkt verhalten und nicht dynamisch unterschiedliche Bilder anzeigen. Es könnte ja auch sein, dass die Formatierung des Mailings sich ändert und damit die Größe der Bilder. Auch in diesem Fall sollte das Bild sich in einem alten Newsletter nicht ändern (denn gerade dann könnte das Aussehen überhaupt nicht mehr im Sinne des Redakteurs sein).
  2. Solange der Cache-Wert also existiert, wird auch die kopierte Bild-URL zurückgeliefert werden. D.h. es wird auch immer das gleiche Bild referenziert solange eben keine Änderungen existieren. Nur bei Änderungen (Cache Flush, neues Bild oder neue Bildformatierung) wird ein neues Bild generiert und damit auch die "aktuelle" URL.

Meine Fragen nun an Dich @bjoern-flagbit:

  1. Ist diese Lösung aus Eurer Sicht überhaupt die richtige im Magento-Umfeld?
  2. Ist diese Lösung einfacher umzusetzen als die ursprünglich angedachte Lösung (5 PT)? Wenn ja, was wäre die (neue) Aufwandschätzung?
  3. Seht Ihr weitere Konsequenzen die ich nicht beachtet habe?

Vielen Dank!

Gruß,

Falco

BrocksiNet commented 8 years ago

Hallo Falco,

wir haben uns deine Problemschilderung durchgelesen und intern besprochen.

Grundsätzlich stellen wir uns unsere Lösung so vor:

  1. Wir liefern euch wie bisher die URL's zu den Images.
  2. Sobald wir einen Request auf eine dieser URL's erhalten verschieben wir dieses Bild in einen separaten Folder.
  3. Bei jedem weiteren Request liefern wir immer die URL's von unserem "inxmail" Ordner zurück.

Im Prinzip machen wir es dann so wie euer Kunde aber nur mit den Bildern welche auch wirklich gebraucht werden. Wir vermeiden also Datenmüll im Inxmail Bilder Ordner.

Aufwand schätzen wir auf max. 1 PT.

Grüße Björn

falco-knapp commented 8 years ago

Hi @bjoern-flagbit ,

danke für die Einschätzung. Ich habe zu Eurem Lösungsvorschlag folgende Rückfragen:

So wie ich Eure Lösung verstehe wäre der Ablauf:

  1. GET .../inxmail_datasource/source/product/id/123 -> Bild wird erzeugt
  2. XML beinhaltet .../cache/..../123.jpg
  3. GET .../cache/.../123.jpg (HTTP 200)
  4. Bild wird von /cache/.../123.jpg -> /inxmail/.../123.jpg kopiert
  5. GET .../cache/.../123.jpg (Redirect auf /inxmail/.../123.jpg)?

Irgendwie scheint mir das falsch zu sein oder ich fürchte ich missverstehe es

Ich glaube der Ablauf muss sein:

  1. GET .../inxmail_datasource/source/product/id/123 -> Bild wird erzeugt (wenn nicht schon vorhanden)
  2. Bild wird von /cache/.../123.jpg -> /inxmail/.../123.jpg kopiert (wenn nicht schon kopiert)
  3. XML Resultat des GET Aufrufs beinhaltet ImageUrl: /inxmail/.../123.jpg

Könnt Ihr das bitte nochmal prüfen?

Danke und Gruß,

Falco

BrocksiNet commented 8 years ago

Hallo Falco,

der Ablauf ist so wie du es im Punkt "Ich glaube der Ablauf muss sein" geschrieben hast. Kann sein das ich mich da schlecht ausgedrückt habe. Sorry.

Grüße Björn

falco-knapp commented 8 years ago

Hi Björn,

super. Erstmal vielen Dank für die Einschätzung.

Gruß,

Falco

falco-knapp commented 8 years ago

Hi Björn,

Aufwandfreigabe: max 8h. Ihr könnt die Implementierung einplanen.

Danke und Gruß,

Falco

falco-knapp commented 8 years ago

Works as expected. Thanks.