Ich möchte die Klasse sAdmin erweitern. Dazu habe ich eine Erweiterungklasse myAdmin erstellt. In dieser Klasse möchte ich einen neuen HookPoint erschaffen z.B.: eval($this-\>sSYSTEM-\>sCallHookPoint("sAdmin.php\_sGetShippingSurcharge")); Wo muss ich den Hookpoint denn noch bekannt machen, damit er auch unter erweiterte Systemeinstellungen>>>Hookpoints angezeigt wird, sodass ich dort ein kleines PHP Script verankern kann? Die Datenbank habe ich diesbezüglich schon durchforstet aber nix gefunden 
[quote=„plotterinsel“]Ich möchte die Klasse sAdmin erweitern. Dazu habe ich eine Erweiterungklasse myAdmin erstellt. In dieser Klasse möchte ich einen neuen HookPoint erschaffen z.B.: eval($this-\>sSYSTEM-\>sCallHookPoint("sAdmin.php\_sGetShippingSurcharge")); Wo muss ich den Hookpoint denn noch bekannt machen, damit er auch unter erweiterte Systemeinstellungen>>>Hookpoints angezeigt wird, sodass ich dort ein kleines PHP Script verankern kann? Die Datenbank habe ich diesbezüglich schon durchforstet aber nix gefunden [/quote] Zitat von http://www.shopware.de/wiki/Preview-3.5 … l_497.html … [quote]„Hookpoints“ (Deprecated) Die alten Hookpoints, die auf „eval“ basieren und Code aus der Datenbank an definierten Stellen im Programmcode einfügen, werden mit Shopware 4.0 entfernt. Sie sollten daher mit Release von Shopware 3.5.0 Ihre Plugins auf die neue Struktur umstellen. Die Hookpoints aus der shopware.php und den Viewports entfallen aufgrund von Umstellungen schon mit der Version 3.5.0. [/quote] Also einfach vergessen…
och schade… ich finde das es ne gute Möglichkeit ist, bestimmte Werte übers Backend zu händeln ohne dafür ein extra Modul zu basteln. Nagut dann bleibts bei mir erstmal hardcodiert 
… aber danke für den Hinweis… hatte ich selbst noch nicht gefunden :thumbup:
Naja, dann kannst du im Zweifelsfall unter engine/core/class/inherit eine myAdmin.php anlegen: [code]<?php include ("$path/sAdmin.php");
class myAdmin extends sAdmin
{
// Hier deine modifizierten Funktionen
}
?>[/code] Das ist alle Mal besser, als die Originalklassen direkt zu ändern - ansonsten darfst du ja bei jedem Patch erneut dran (Sofern die Datei neu ausgeliefert wird) - Man muss auch nicht für jede Änderung ein eigenes Plugin schreiben 
Wir machen es z.B. so, dass wir bei Individualprogrammierung alle Änderungen in einem Plugin zusammenfassen / sammeln - hat den charmanten Vorteil, dass man ALLE individuellen Anpassungen an einer zentralen Stelle hat und das bei Problemen / Fehlern auch mal schnell zentral deaktivieren kann um zu prüfen, ob es mit den eigenen Anpassungen zusammenhängt - ganz zu schweigen, von der viel einfacheren Update-Integration!
genau so hab ichs gemacht. An die Originaldateien geh ich nicht ran, und das funktioniert auch ganz fantastisch! Nur muss ich eben in der abgeleiteten Klasse ein paar feste Werte hinterlegen. Die werden sich nur ganz selten ändern, deshalb lohnt dafür allein die Entwicklung eines Plugins nicht, wenns aber noch mehr individuelle Dinge werden sollten, ist die Idee des Zusammenfassens gar nicht mal übel :happy: Ich hab nämlich mein Problem mit den Versandkostenaufschlägen gelöst, aber dazu in dem anderen Thread mehr …
Meinst du feste Werte im Sinne von Konfigurationsvariablen? Dann wäre es ideal, wenn du neue Einträge in der Tabelle s_core_config dafür anlegst und eine neue Gruppe in s_core_config_groups - dann kannst du das bequem über das Backend konfigurieren. Im Code kannst du über $this->sSYSTEM->sCONFIG[“KEY_DER_CONFIG_VARIABLE”] - auf diese Werte zugreifen
1 „Gefällt mir“
ja das meine ich! ich will die id’s der Versandarten erfassen, für die keine Aufschläge berechnet werden sollen… Mensch das ist doch die Lösung, die ich gesucht habe!!! werd da gleich mal rumexperimentieren!! Ganz fetten und herzlichen Dank für diese Info :thumbup:
[quote=“Stefan Hamann”]Man muss auch nicht für jede Änderung ein eigenes Plugin schreiben Wir machen es z.B. so, dass wir bei Individualprogrammierung alle Änderungen in einem Plugin zusammenfassen / sammeln - hat den charmanten Vorteil, dass man ALLE individuellen Anpassungen an einer zentralen Stelle hat und das bei Problemen / Fehlern auch mal schnell zentral deaktivieren kann um zu prüfen, ob es mit den eigenen Anpassungen zusammenhängt - ganz zu schweigen, von der viel einfacheren Update-Integration![/quote] Daran hatte ich ja noch gar nicht gedacht… Das ist doch ein ziemlicher Unterschied zu dem OXID-Konzept, in dem man (nur) Core-Klassen überladen kann, mit allen Nachteilen (da man ja bei x zu ändernden Core-Klassen x separate Module hat, und dabei doch leicht den Überblick verliert). Ist ja wirklich eine saucoole Sache mit den Plugins, dass man da im Grunde in einer Plugin-Datei in allen Shop-Klassen rumändern kann… Macht vieles einfacher… Ist das eine Funktionalität des Zend-Framework, oder habt ihr das erfunden? Man kann Plugins doch sicher auch direkt per SQL in der Datenbank einbauen und aktivieren??? (Ich finde das immer so lästig, das über ein GUI machen zu müssen…) So könnte man eine SQL-Datei schreiben, und alle Plugins für einen Kunden sehr einfach verteilen und aktivieren!
Moin, nein, das Plugin-System haben wir vollständig selbst entwickelt - das hat mit dem Zend-Framework nichts zu tun. Bei Zend gibt es ja für die verschiedenen Objekte verschiedene Plugin-Strukturen, bei uns gibt es ein einheitliches System für alle einbundenen Objektarten. SQL-Aktivierung ist kein Problem - es müssen halt die passenden Einträge in der Tabelle s_core_subscribers erzeugt werden, die kann man sich ja per Dump besorgen und dann in die Installations-SQL-Datei integrieren.
[quote=„Stefan Hamann“]nein, das Plugin-System haben wir vollständig selbst entwickelt - das hat mit dem Zend-Framework nichts zu tun.[/quote] Sehr cool! :thumbup:
es funktioniert!! nun ist es genauso wie ich es haben wollte und dazu wars auch noch sehr einfach… 
Du bist mein Held … und ich der meines Chefs
Na, das freut mich ja Schau dir aber bitte auch mal das Plugin-System an, das ist natürlich von der Einarbeitung her etwas komplexer, aber damit kannst du Dinge zaubern, für die dir dein Chef bestimmt ein paar Extra-Urlaubstage spendiert 