Ein Update des Plugins setzt die angelegten Textbausteine, welche in den tpl-Dateien eines Plugins ausgegeben werden, wieder auf den Ursprung zurück. Gemachte Änderungen gehen somit verloren.
Bedinungen:
Die Snippets sind beispielsweie im Plugin unter PLUGINORDNER/Snippets/frontend/plugins/PLUGINNAME/index.ini angelegt
Die Textbausteine sind in einer ini-Datei definiert und nicht in den tpl-Dateien
Wie kann man das unterbinden? Bei dem betroffenen Plugin gibt es keine public function update().
welchen wir in der enable(), update() und uninstall() Funktion nutzen, um die Caches zu leeren und den Nutzer dazu aufzufordern, das Theme neu zu kompilieren. Dabei werden allerdings auch vom Nutzer bearbeitete Textbausteine zurückgesetzt - jedoch nur jene, welche unter obigen Bedingungen angelegt wurden.
Schreiben wir nun unseren Code Testweise um und geben bei der update-Funktion für den invalidateCache ein leeres array aus, werden die Testbausteine nicht zurückgesetzt, aber auch keine Caches geleert.
Was können wir tun, um die veränderten Textbausteine / Snippets nicht beim Update eines Plugins wieder zurückzusetzen?!
In der Datenbank wird pluginseitig praktisch gar nichts gemacht (außer Konfigfelder anlegen) ich habe hier mal ein grobes Skelett eines Plugins angefügt mit der Funktion zum Leeren der Caches. In den einzelnen Funktionen werden beispielsweise nur Konfigurationselemente angelegt - viel mehr passiert da nicht.
subscribeEvent(
'Enlight_Controller_Action_PostDispatchSecure_Widgets_Emotion',
'onFrontendPostDispatch'
);
$this->createConfig();
$this->createTranslations();
return true;
}
/**
* @return array
*/
public function enable()
{
return ['success' => true, 'invalidateCache' => $this->getInvalidateCacheArray()];
}
/* Plugin Deinstallation */
public function update($oldVersion)
{
$this->createConfig();
/* hier passiert sonst eigentlich nichts besonderes */
return ['success' => true, 'invalidateCache' => $this->getInvalidateCacheArray()];
}
/* Plugin Deinstallation */
public function uninstall()
{
return ['success' => true, 'invalidateCache' => $this->getInvalidateCacheArray()];
}
/**
* Helper method to return all the caches, that need to be cleared after installing/uninstalling/enabling/disabling a plugin
*
* @return array
*/
private function getInvalidateCacheArray()
{
return ['frontend', 'backend', 'theme'];
}
/* Plugin Configuration */
private function createConfig()
{
/* ... */
}
/* Plugin Translation */
public function createTranslations()
{
/* ... */
}
public function onFrontendPostDispatch(Enlight_Event_EventArgs $args)
{
/* ... */
}
}
Ich habe das ganze nun mit einem quelloffenen Plugin von Shopware getestet, dem SwagCookiePermission Plugin. Zum Plugin:
Das Plugin fügt über SwagCookiePermission/Snippets/frontend/swag_cookie_permission/main.ini unter anderem den Text: “Diese Seite benötigt Cookies. Sind Sie mit der Nutzung von Cookies einverstanden?” in die Snippets ein, welchen ich zu “_Diese Seite benötigt Kekse. Sind Sie mit der Nutzung von Cookies einverstanden?” _im Backend umgeschrieben habe. Nach dem Update war der Text wieder wie in der ini. Das Plugin verfügt über keine gesonderte update-Funktion.
Handelt es sich hierbei vll. um einen Bug in Shopware?
Edit: Scheinbar passiert das in der Entwicklungsumgebung (lokal, vagrant). Im Produktivshop konnte ich das nicht bestätigen. Also könnte das mit der Produktivmodus-Einstellung zu tun haben? **** Ein Kunde hatte angemerkt, dass bei ihm bei jedem Update von Plugin xy die Textbausteine zurückgesetzt werden.
Dann ist vermutlich das Plugin so programmiert worden. Testbausteine landen beim Aufruf der Templates in die DB s_core_snippets. Wenn es da Probleme gibt, dann sollte man sich den Hersteller vom Plugin wenden. Wenn du es gekauft hast, steht dir auch Support zu.
@IFF wir sind der Hersteller! Es wurde nichts extra programmiert, dass Textbausteine beim Update überschrieben werden. Ebensowenig wie im SwagCookiePermission eine solche Funktion sinnloserweise untergebacht wäre. Dagegen spricht ebenfalls, dass es in der Entwicklungsumgebung unter Vagrant passiert und im Liveshop nicht.
Achso! Ich bzw. die Firma für ich arbeite entwickeln auch Plugins, aber so ein Verhalten hatten wir noch nie. Es sei denn, bei einem Deinstall, aber nur beim Updaten fliegen keine Textbausteine raus bzw. werden zurück gesetzt.
Genau, kennen das auch nur aus der Uninstall-Funktion. Aber da es ohnehin nur in der Entwicklungsumgebung passiert und nicht im Live-Shop nehme ich mal an, dass es an irgendeiner Konfiguration liegt. Nur an welcher… dann könnte es ja sein, dass der Kunde etwas falsch konfiguriert hat.
Die ini-Datei verwenden wir, um auch gleich Übersetzungen mitgeben zu können. Bei der Anlage in den TPL-Dateien kann man keine Übersetzungen mitgeben.
Liegt das Problem evtl. auf einer anderen Ebene?
Ich \ *meine *, das Verhalten beim Update eine Plugins wird vom dirty-Flag gesteuert. Wird ein Textbaustein im Backend modifiziert, sollte das dirty-Flag gesetzt werden. Ist es nicht gesetzt, wird beim Update der Textbaustein überschrieben, weil der alte Inhalt ja „default“ war und beim „Update“ sich „default“ ja ändern könnte. Ist das Flag gesetzt, sollte der Textbaustein nicht überschrieben werden.
Also müsste man gucken, ob das Problem nicht an einer anderen Stelle im Backend liegt, und z.B. beim Ändern im Backend das Flag gar nicht gesetzt wird - sprich: Ist bei den betroffenen Textbausteinen das dirty-Flag gesetzt?
Schon komisch, ich gehe ja davon aus, dass diese eine Roh-Version von Shopware ist. Und wäre diese Entwicklungsumgebung auf einen Server - also nicht lokal - zu verlegen? Um ggf. solche Probleme generell zu vermeiden.
Der Kunde hat erklärt, dass es nicht immer, sondern nur beim Update bei einem bestimmten Versionssprung vorkommt, welchen er mehrmals nun durchgeführt habe. Das wurde vorher nicht so deutlich. Dabei war dies dann genau der Versionssprung, in welchem die Textbausteine zwecks Übersetzung in eine solche ini-Datei ausgelagert wurden. Damit erklärt sich, weshalb beim Kunden die Textbausteine einmalig zurückgesetzt wurden.
Warum die Entwicklungsumgebung unter vagrant die Textbausteine zurücksetzt bleibt zwar weiterhin ungeklärt, macht allerdings für die Entwicklung auch Sinn. Vll. ist es so, dass unter vagrant, wie @sonic dies erklärte, der Flag anders gesetzt wird.
Plugin 1 auf Version 1.1.10 und Plugin 2 auf Version 1.1.1 upgedatet - kein Theme kompiliert - Textbausteine im Backend geprüft - waren NICHT zurückgesetzt!
Das ganze habe ich in verschiedenen Abläufen und leeren der Caches und Kompilieren der Themes wiederholt und gestest - mit immer dem gleichen Ergebnis. Nebenbei habe ich die Datenbanken inspiziert und nach den dirty-flags (wird auf 1 gesetzt, wenn ein Textbaustein bearbeitet wurde) und Änderungen geschaut.
Das Ergbenis ist nun, dass zwischen Version 5.2.20 und 5.2.24 anders mit den Textbausteinen umgegangen wird - bzw. ab irgendeiner Version nach 5.2.20 ein Bug implementiert wurde. Daher habe ich nun ein Issue bei Shopware eröffnet, da wir den Fehler nicht auf den Code in den Plugins zurückführen können, sondern anhand der Tests in der Shopware Version liegen sollten. An dem Snippet-Handling hat sich in den Plugins ja nichts geändert, es waren ja die selben Plugins bei Shop 1 und Shop 2. Und die Snippets wurden so angelegt, wie Shopware dies schult.
