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.
Oft will man irgendwelche Aufgaben erledigen, nach dem ein Artikel gespeichert wurde. Z.B. kann es sein, dass man diesen Artikel prüfen und zu irgendwas hinzufügen möchte oder auch einfach mit dem Artikel verknüpfte andere Artikel mit updaten muss.
Es gibt ein entsprechendes Event, um auf das Speichern eines Artikel im Backend zu reagieren. Dabei wird ein allgemeines Controller-Event verwendet, wie es für jeden Controller erzeugt wird und gegen die dort aufgerufene Action geprüft.
public static function getSubscribedEvents(){
return [
'Enlight_Controller_Action_PostDispatch_Backend_Article' => 'articleRefresh',
];
}
public function articleRefresh(\Enlight_Event_EventArgs $args){
/** @var $subject \Enlight_Controller_Action */
$subject = $args->getSubject();
$request = $subject->Request();
if ($request->getActionName() === 'save') {
$params = $request->getParams();
//TODO do something
}
}
Nun fehlt noch, dass wir auch Änderungen mit bekommen, wenn ein Artikel über die REST-API geändert wird.
Der Controller ist "Articles" und das Module ist "Api". Also ist unser Event "Enlight_Controller_Action_PostDispatch_Api_Articles". Die Action ändern sich natürlich auch, weil wir bei der REST-API Actions wie PUT und POST haben.
public static function getSubscribedEvents(){
return [
'Enlight_Controller_Action_PostDispatch_Backend_Article' => 'articleRefresh',
'Enlight_Controller_Action_PostDispatch_Api_Articles' => 'articleRefresh',
];
}
public function articleRefresh(\Enlight_Event_EventArgs $args){
/** @var $subject \Enlight_Controller_Action */
$subject = $args->getSubject();
$request = $subject->Request();
if (in_array($request->getActionName(), ['save', 'put', 'post'])) {
$params = $request->getParams();
//TODO do something
}
}
Damit sollte man jede Änderung an einem Artikel mitbekommen.
Das gleiche Prinzip sollte entsprechend auch für alle anderen Controller funktionieren.
Möchtest Du AdSense-Werbung erlauben und mir damit helfen die laufenden Kosten des Blogs tragen zu können?