Einfach mal die Meta-Description mit einem Prefix versehen, um kleinere SEO-Probleme zu beheben. Klingt einfach und führt schnell zur Verzweiflung. frontend/detail/header.tpl angepasst und es funktioniert nicht. Keywords ändern ist kein Problem nur die Meta-Description des Artikels will sich nicht ändern.
Lösung Wie man schnell vermutet wird die eigene Änderung überschrieben. Der Schuldige ist das SEO-Plugin und da muss man die index.tpl anpassen. Die Änderung kann z.B. so aussehen:
Ein Problem bei Smarty 3 ist, dass man zwar sehr schön Blöcke überschreiben oder erweitern kann, es aber keine Möglichkeit gibt, die im Block vorhanden anderen Blöcke dan unangetastet zu lassen. Man muss in so einem Fall die nested Blöcke immer mit kopieren und mit dem Parent-Template immer wieder bei Änderungen abgleichen. Wenn z.B. ein Template einen Block mit einer <form> hat und darin dann die ganzen Eingabe-Möglichkeiten auch als Blöcke ausgelegt sind, muss man wenn man die Form-Action ändern will zwingend auch das ganze Form-Content Templating mit übernehmen.
Eine Möglichkeit das zu umgehen ist den Block rendern zu lassen und dann per String-Operationen das Ergebnis anzupassen. Primitiv aber auch sehr effektiv!
Falls man Formular von Shopware in anderen Contexts als dem forms-Controller einsetzt, kann es nötig sein, dass Template so anzupassen, damit es noch auf den forms-Controller zeigt und nicht auf den Controller in desen Context man gerade arbeitet.
Im normal Fall wird die SEO-URL einer statischen Seite über den Namen/description gebildet. Ändert man nun den Namen der Seite, ändert sich auch der Link und damit könnten vorhandene eingetragene Links plötzlich nicht mehr funktionieren.
Um das zu verhindern, ist es praktisch der Namen für die SEO-URL unabhängig vom Namen erzeugen zu können. Da helfen die SEO Einstellungen im Punkt "SEO-Urls Shopseiten Template". Wir brauchen noch ein Freitextfeld mit dem DB-Spaltennamen "seourl". Nun ändern wir das Template:
Wenn also dort im neuen Feld etwas angegeben ist, wird dieses verwendet und ansonsten weiterhin der Name. Das hat den Vorteil, dass man nur die Seite anpassen muss, die man umbenennen möchte und nicht jede.
Wenn man in seinem Plugin irgendein Template erweitert, dass mit der Darstellung von Produkten zu tun hat, sollte man immer daran denken, dass diese sehr sehr oft auch als Widgets verwendet werden.
Wenn man das Template-Dir nicht beim Laden von Widgets dem System Verfügbar macht, kann es zu unschönen Fehlern kommen und einen Hannes lange nach dem Problem suchen lassen.
directory 'xxxxxxxxx/y.tpl' not allowed by security setting
Hier ist das gesamte Konzept mit Caching und Templates wirklich toll mit Beispielen beschrieben:
Da steht auch, wenn das {s}-Tag als unbekannt angesehen wird.. dann ging einfach in Smarty echt was schief und man sollte mal die Apache-Logs angucken.
Eine Lösung wird auch gleich mitgeliefert (wobei ich momentan noch mit 2 Events.. Frontend und Widgets arbeite.. und auch erst einmal dabei bleiben werde):
ABER Vorsicht: Im Backend gibt es kein Shop-Object. Wenn man beim Hinzufügen des Template-Dirs auch Smarty-Vars setzt und auf Customer- und Session-Daten zugreifen will, kann es schnell schief gehen! Bei Frontend und Widgets gibt es keine Unterschiede.
Eine wichtige Erkenntnis das Code-Element in Shopware Einkaufswelten betreffend ist, dass es Smarty unterstützt. Wer also im HTML-Teil direkt JavaScript verwenden will muss etwas mit den geschweiften Klammern aufpassen. Das gilt besonders, wenn man einfach minimized Code-Snippets von einem Anbieter in die eigene Seite integrieren möchte.
foreach ($this->getListeners($event) as $listener) {
if (null !== ($return = $listener->execute($eventArgs))) {
$eventArgs->setReturn($return);
}
}
$eventArgs->setProcessed(true);
return $eventArgs->getReturn();
}
und da sehen wir
$eventArgs->setReturn($value);
Also ist die Lösung
public function eventMailListener(\Enlight_Event_EventArgs $args){
/** @var \Enlight_Components_Mail $mail */
$mail = $args->getReturn();
echo $mail->getPlainBodyText();
die();
}
Wenn man das erst einmal verstanden hat, ist alles plötzlich ganz einfach. Ach ja, wenn man das Subject überschreiben möchte erst einmal $mail->clearSubject(); ausführen.
Zum 10. Geburtstag meines PHP-Frameworks wird sich da viel ändern und es damit dann wieder etwas mehr zu anderen Frameworks aufschließen können.
Mein eigener Class-Loader fliegt raus und es wird noch der ClassLoader vom Composer verwendet. Meiner kann zwar auch mit PSR4 umgehen, aber nach dem Umstieg muss ich dann auch alles darauf umstellen und habe keine Ausrede mehr, weil die Kompatibilität weg fällt.
Es gibt nun ein public-Verzeichnis so dass alle Config-Dateien und Classes außerhalb des Bereiches liegen, auf dem Benutzer zugreifen können. Das sorgt für mehr Sicherheit, macht das Laden von CSS und Bildern aus dem Theme-Verzeichnis aber komplizierter. Ich überlege hier auf Assetic umzusteigen. Momentan läuft meine Lösung aber sehr gut.
Und das Beste und wichtigste was aber auch am meisten Arbeit machen wird (darum habe ich ganz viele alte Module erst einmal gelöscht und lasse auch die alten PHP-Pages drin) ist, dass Module-Pages nun wirklich mit Controller und Twig-Template gerendert werden. Die Twig-Templates könenn vom Theme und von eigenes Templates in der Instance überschrieben werden und so kann man nun endlich das Aussehen der Module leicht und schnell anpassen.
Smarty war schon länger drin, wurde aber nie benutzt und ist jetzt raus geflogen.
Mein erstes Projekt damit wird sein, die Zeiterfassung für Kunden-Projekte neu zu schreiben und für alle brauchbar zu machen. Das wird wohl am Ende nur 1-2 Tage dauern. Also nichts im Vergleich zum Umbau des Frameworks.
Man kann sehr einfach mit CSS auch die Reihenfolge von Elementen ändern. Damit kann man allein schon mit CSS viel an Templates anpassen ohne gleich Twig oder Smarty bemühen zu müssen.
bezahlt von 
Blog: Blog-entries by search-pattern/Tags:
