Du beschreibst die alte Plugin Struktur. Die würde ich auf keinen Fall für neue Plugins benutzen. Entwickle neue Plugins am besten immer nach dem 5.2 Plugin System.
Aber generell muss ich wohl etwas revedieren. Ganz so leicht ist es dann doch nicht. Du hast ein sehr unglückliches Beispiel gewählt für “Controller überschreiben”. Direkt überschreiben kannst Du das soviel ich weiß nicht, aber es gibt jeweils zu jeder Controller Action ein pre- und postDispatch Event. Also pre logischerweise vor und post nach der jerweiligen Action.
Mit Hooks habe ich mich bisher auch noch nicht näher beschäftigt, weil es immer keine gute Idee ist, irgendeine Funktionalität zu überschreiben. Man muss dann nämlich dafür sorgen tragen, wenn Updates kommen seitens Shopware, dass das Plugin dann immer noch läuft. Wesentlich besser ist es, so etwas über Events abzubilden. Darin kann man nämlich auch mehr als genug das Standard Verhalten beeinflussen und man läuft vorallem dabei nicht Gefahr, dass es in der nächsten Shopware Version nicht mehr geht.
Ich kam bisher recht gut ohne Hooks aus, da es eigentlich für fast alles Events oder etwas vergleichbares gibt. Man braucht eigentlich kaum eine Methode zu überschreiben. Wie gesagt, das bringt nur mehr Nachteile als Vorteile mit sich.
Aber generell kannst Du nach dem 5.2er Plugin System wie folgt Dich auf solche Events abonnieren (am Beispiel von der Artikel Detail Seite):
'onPostDispatchDetail'
];
}
public function install(InstallContext $context)
{
// prepare plugin, e. g. create own db tables
}
public function uninstall(UninstallContext $context)
{
// clean up, e. g. drop plugin db tables
}
public function onPostDispatchDetail(\Enlight_Event_EventArgs $arguments)
{
/**
* @var $controller \Shopware_Controllers_Frontend_Index
*/
$controller = $arguments->getSubject();
/**
* @var $request \Zend_Controller_Request_Http
*/
$request = $controller->Request();
/**
* @var $response \Zend_Controller_Response_Http
*/
$response = $controller->Response();
/**
* @var $view \Enlight_View_Default
*/
$view = $controller->View();
// do your database article check here, in sArticles you will find the most article data you may need that are already fetched from the database by shopware itself (you are in after action event)
$sArticle = $view->getAssign('sArticle');
// add your own plugin template here, that it overrides the themes' template:
$view->Engine()->addTemplateDir(
$this->getPath() . DIRECTORY_SEPARATOR . 'Resources' . DIRECTORY_SEPARATOR . 'Themes' . DIRECTORY_SEPARATOR
);
$sArticle['someCustomVar'] = 'hello article detail page!';
$view->assign('someCustomVar', $sArticle);
}
}
Nach der neuen Plugin Struktur müssen Plugins auch unter custom/plugins liegen. Dort entsrpricht dann jeder Unterordner einem Plugin. Die Bootstrap.php wird zu einer genamespacten Klasse, die genauso heißen muss, wie der Plugin Ordner, bzw. wie das Plugin selbst. Denn danach sucht Shopware. Und diese würde beispielhaft wie oben aussehen, wenn wir davon ausgehen, dass Dein Plugin “CompanyPlugin” heißt.
MFG
derwunner