Ich habe ein paar Plugins nach der Slogan-Anleitung geschrieben. Diese haben auch super funktioniert. Seit dem Update auf SW5 geht es leider nicht mehr. Letztendlich kann ich das Plugin installieren… es wird mir auch angezeigt. Was die Funktionalität angeht habe ich wohl nur Probleme mir der Config in dem Plugin. In meinen Plugineinstellungen kann ich eine der vorhandenen Kundengruppen auswählen. Wenn ich aber das Dropdown öffnen will dann werden mir keine Kundengruppen mehr angezeigt. Hier mal der zutreffende Codeausschnitt: $ass\_array = array( "controller" =\> "Config", "action" =\> "getValues", "name" =\> "customerGroup" ) $remoteUrl = Shopware()-\>Front()-\>Router()-\>assemble($ass\_array); $form = $this-\>Form(); for ($i = 1; $i \<= $this-\>code\_count; $i++) { $form-\>setElement( 'combo', $this-\>prefix . '\_foobar\_' . $i, array( 'label' =\> 'Kundengruppe ' . $i, 'value' =\> 'Bitte wählen Sie ein Gruppe', 'valueField' =\> 'id', 'displayField' =\> 'key', 'triggerAction' =\> 'all', 'store' =\> 'new Ext.data.Store({ fields: ["id", "key"], proxy : { type : "ajax", autoLoad : true, api : { read : "' . $remoteUrl . '", }, reader : { type : "json", root : "data" } } })', 'scope' =\> Shopware\Models\Config\Element::SCOPE\_SHOP ) ); } das hat normal die Kundengruppen rein geholt… macht es aber nicht mehr… jemand ne Idee warum ?
Folgendes konnte ich bislang herausfinden… Wenn ich das hier in meinen Browser eingebe: h t t p : //localhost/shops/[color=red]sw4[/color]/backend/Config/getValues/name/customerGroup dann bekomme ich einen JSON-String zurück der wie erwartet alle Kundengruppen beinhaltet. hier: h t t p : //localhost/shops/[color=red]sw5[/color]/backend/Config/getValues/name/customerGroup macht er das eben nicht… da bekomme ich einen leeren „JSON“-String zurück. Also nur: []
Du kannst auch “store => Ext.create(‘Shopware.apps.Base.store.CustomerGroup’)” nutzen
ok, habe das mit den Kundengruppen wieder hinbekommen… wie ist das mit _SESSION, ist das in SW5 depricated ?
Hi, die globalen Variablen \_GET, _POST, $_SESSION, etc. wurden vom SW-Store schon immer abgelehnt. Die Alternative ist ja: $this->get(‘session’) Heiner
Ich meinte ja nicht die normale Session… es ging mir um: Shopware()-\>Modules()-\>System()-\>\_SESSION['myVarName'] = "hallo"; So hatte ich eine Sessionvariable erstellt die ich dann in dem Bereich in dem ich Sie brauchte nutzen konnte… Allerdings ist …System->_SESSION depricated und jetzt scheint es wohl Shopware()-\>Session() zu sein. Aber wenn ich schreibe Shopware()-\>Session['myVarName'] = "Hallo"; dann kann ich diesen Wert leider nicht in der Session sehen.
Hi, das sollte so in aktuelleren PHP-Versionen funktionieren: Shopware()->Session()[‘myVarName’] = “Hallo”; Aber im Prinzip ist das auch “deprecated” / veraltet. Besser wäre der DI-Weg: public function \_\_construct($session) { $this-\>session = $session; } /\*\* \* @param \Enlight\_Controller\_ActionEventArgs $args \*/ public function onPostDispatchCheckout($args) { if(!empty($this-\>session['myname'])) { ... } } Heiner
Also das mit der __construct function funktioniert so nicht… wenn ich die in mein plugin so einbaue dann geht garnichts mehr 
Davon abgesehen bringt mir die Session so nichts. Ich muss die Session zugreifen in der die aktuellen Kundengruppen-Informationen stehen. In dieser Session sind die Werte nicht vorhanden. Zu dem: Shopware()-\>Session()['myVarName'] = "Hallo"; Dann kommt [quote]Fatal error: Can’t use function return value in write context[/quote] Habe das versucht… protected $session; public function init($session) { $this-\>session = $session; //code here... } Leider ist die Session dann leer
Hi, naja, zur DependencyInjection gehört ja auch, dass da irgendwer die dependency injected, das machst du ja hier nicht :). Shopware()-\>Session()-\>offsetSet('name', 'wert'); Steht dir eigentlich immer zur Verfügung, auch wenn es nicht unbedingt best practice ist, immer global über das Shopware-Singleton zu arbeiten - das wollte Heiner auch nur betonen, denke ich. Daniel
Hey hiermit sollte es richtig laufen zum setzen Shopware()->Session()->offsetSet(‚name‘, ‚wert‘) Zum Abfragen Shopware()->Session()->offsetGet(‚name‘)
[quote=“Dwza”]ok, habe das mit den Kundengruppen wieder hinbekommen…[/quote] Woran lag es? Ich bekomme vereinzelt auch Probleme. In manchen Instanzen funktioniert die Abfrage, in manchen nicht, völlig schleierhaft. Bisher habe ich die Remote Combo auch mit folgender URL gefüllt: $remoteUrlPriceGroup = Shopware()-\>Front()-\>Router()-\>assemble( array("controller" =\> "Base", "action" =\> "getCustomerGroups") ); Wie gesagt, eig. funktioniet das, in seinem System in 5.0.2 nut nicht mehr. Dabei gibt die URL definitiv eine Liste der Gruppen zurück, nur die Comboboxen bleiben leer. EDIT: Jetzt habe ich das reproduzierbar: Der Shop ist von einem Unterordner in den Root gewandert. Im Logging sehe ich, dass das Plugin die URL noch von der Unterordner-Instanz aufrufen möchte (was es ja gar nicht mehr gibt). Shopware scheint nach dem Umzug noch irgendetwas altes (die URL) im Cache/System zu haben, was das Plugin verwendert. Wäre nett hier offiziell einen Fix/Hinweis zu bekommen … Schöne Grüße, Niklas
Hi Niklas, du kannst den Store auch direkt beim Element hinterlegen. Beispiel: $form-\>setElement( 'store' =\> 'base.CustomerGroup' Das alte Format mit “new Ext.data.Store(” wird aus diesem Grund nicht empfohlen noch funktioniert sie 100%ig. Sie ist nur zur Kompatibilität mit Shopware 3 enthalten. Viele Grüße Heiner
[quote=“Heiner Lohaus”]du kannst den Store auch direkt beim Element hinterlegen. Beispiel: $form-\>setElement( 'store' =\> 'base.CustomerGroup' [/quote] Okay, prinzipiell schonmal gut der Hinweis - jedenfalls für neue Versionen. Aber wir haben eben schon eine Vielzahl von installierten Plugins. Die Plugin-Konfiguration wird eben beim install gesetzt und nicht beim Update. Eine erzwungene Neu-Installation des Plugins dafür wäre jetzt nicht die beste Möglichkeit. Gibt es keinen Weg die alte URL webgzubekommen? Die Frage ist ja auch, wo die überhaupt drin sitzt, da der Unterordner in den Shop-Einstellungen defintiv nicht mehr drin ist, und ich den gesamten Cache des Shops mehrmals geleert habe. Im “Prinzip” darf der Verweis auf den alten Ordner gar nicht mehr existieren, nur im Plugin bzw. über Shopware()->Front()->Router()->assemble() scheint dieser noch zu existieren … Irgendein gecachter Bereich muss das noch drin haben, dann müsste man den doch auch irgendwie wegekommen können … Schöne Grüße! Niklas
Hi Niklas, ja, der Link wird gecached bzw. in die Datenbank geschrieben. Daher ist es auch falsch den Router dort zu verwenden. Sattdessen könnte man auch z.B. „document.location.pathname“ verwenden: https://github.com/shopwareLabs/SwagPay … p.php#L370 Oder halt einen BaseStore wie in meinen Beispiel. Viele Grüße Heiner
[quote=„Heiner Lohaus“]Daher ist es auch falsch den Router dort zu verwenden.[/quote] Hm … wieso nehmt Ihr dann in der Doku den Router um die URL zu bauen, wenn es dadurch massiv zu Problemen kommen kann? … http://community.shopware.com/Shopware-4-plugin-configuration_detail_1287.html#Selection_field_.2F_remote_combo Interessant wäre auch eine Liste mit möglichen Verweisen. „base.CustomerGroup“ entspricht ja nicht dem eig. Controller wie „Base, getCustomerGroups“ EDIT: Habe die Stelle gefunden, wo diese definiert werden: https://github.com/shopware/shopware/tree/5.0/themes/Backend/ExtJs/backend/base/store Da ist ja definitiv nicht alles möglich, was man einfach im Plugin über den Router machen könnte. Lassen die Stores sich überhaupt mit dem Plugin an- und mitgeben? … 
[quote=„Heiner Lohaus“]ja, der Link wird gecached bzw. in die Datenbank geschrieben[/quote] Ist es möglich herauszufinden wo dieser Cache genau liegt bzw. wie man diesen löschen kann? Wie gesagt, ich passe das gerne im Plugin an, aber es geht darum der bereits installierten Basis einen Fix für dieses Szenario geben zu können ohne eine neue Installation aufzuzwingen. Das wäre super! Vielen Dank und schöne Grüße, Niklas
Hi, der Fix wäre ja: public function update($oldVersion) { $form = $this-\>Form(); $form-\>setElement('combo', 'TEST', array( 'label'=\>'Backend-User','value'=\>'Please select', 'store' =\> 'base.CustomerGroup' , 'scope' =\> \Shopware\Models\Config\Element::SCOPE\_SHOP)); return true; } Das würde den Eintrag in der Datenbank (beim Plugin-Update) aktualisieren. Einen anderen Weg gibt es nicht bzw. die Plugin-Konfiguration steht extra in der Datenbank. Im Wiki-Artikel stand es wirklich falsch drin. Danke für den Hinweis. Ich werde es korrigieren. Gruß Heiner
Ja, so habe ich das nun auch drin, funktioniert. Trotzdem noch einmal: Wie sind dort eigene Verweise über die ExtJS Stores machbar? Ich hätte ein anderes Beispiel (ab SW5) wo über die Remotecombo eine Liste mit aktuellen Freitextfeldern geholt wird: $remoteUrlArticleAttributes = Shopware()-\>Front()-\>Router()-\>assemble( array("controller" =\> "Config", "action" =\> "getList", "\_repositoryClass" =\> "attribute") ); Den Bereich Config in Bezeihung mit getList und die repositoryClass finde ich nicht in den vorhandenen ExtJS Stores … jetzt ist die Frage wie das geht, wenn der Router nicht mehr verwendet werden soll. Das genannte Beispiel mit document.location.pathname erkenne ich im Button-Handler, wie würde das im Combobeispiel aussehen? Schöne Grüße, Niklas Teich
Das wäre z.B. so möglich: api: { read: document.location.pathname + ‚Config/getList?_repositoryClass=attribute‘ } Aber JavaScript in der Datenbank ist nicht so schön und wir empfehlen daher in solchen Fällen eigene Module zu schreiben. Gruß Heiner
Ah, okay. Ja, ich habe nur Tutorials für komplette Backend Plugins gesehen, da muss ich mal ausprobieren. Aber, ist ja dann mit den Backend Stores deutlichst höherer Aufwand als eig. dem dem Router zu arbeiten, mit dem das ja in ein paar Zeilen fertig ist und ziemlich unkompliziert. Würde vielleicht Sinn machen, die Backend Router-Anweisungen vielleicht nicht zu cachen. Dann würde die ganze Problematik ja gar nicht mehr bestehend … Ok, dann guck ich mal weiter. Vielen Dank und schöne Grüße, Niklas