SW 5.2 - Backend Plugin / eigene Attribute in Artikeldetails

Hallo,

ich prüfe gerade einige unserer Plugins auf die Kompatibilität mit der 5.2 Beta 1 und bin über folgendes gestolpert.

In einem Backend-Plugin wird ein zusätzliches Attribut hinzugefügt (Tabelle s_articles_attributes) und in der Settings-Sektion der Artikel-Details via ExtJS dargestellt.
Unter 5.1.x läuft das alles prima. Die Darstellung klappt nach wie vor in 5.2, aber Änderungen dieses Feldes werden nicht in der Datenbank gespeichert. 

Hier das ExtJs-Model:

//{block name="backend/article/model/attribute/fields" append}
	{ name: 'netzpAnnounced', type: 'boolean', defaultValue: false },
//{/block}

und der Controller:

//{block name="backend/article/view/detail/settings" append}
Ext.override(Shopware.apps.Article.view.detail.Settings, {

   createLeftElements: function() {
        var me = this,
        fields = me.callParent(arguments);

        fields.splice(4, 0, {
            xtype: 'checkbox',
            fieldLabel: '{s namespace="netzperfekt/announcedarticle" name="label_backend"}Article announced{/s}:',
            name: 'attribute[netzpAnnounced]',
            inputValue: true,
            uncheckedValue: false,
            cls: Ext.baseCSSPrefix + 'article-announced',
        });             
 
        return fields;
    }
});
//{/block}

Hat sich an dieser Stelle, insbesondere möglicherweise der Zugriff via _name: ‚attribute[netzpAnnounced]‘, _geändert?

Vielen Dank!
Nils

Hallo Nils,

die Arrtibute wurden komplett neu gestatet und du hast jetzt im Backend die Möglichkeit für viele Sachen Attribute anzulegen , da würd ich mich nicht wundern wenn  die “Komunikation” zur Datenbank jetzt auch geändert wurde.
http://community.shopware.com/_detail_1921_441.html#Freitextfeld-Verwaltung_-_Attribute

https://developers.shopware.com/developers-guide/shopware-5-upgrade-guide-for-developers/?_ga=1.237308677.40845836.1463812834#attribute-management

Uwe 

@useg schrieb:

Hallo Nils,

die Arrtibute wurden komplett neu gestatet und du hast jetzt im Backend die Möglichkeit für viele Sachen Attribute anzulegen , da würd ich mich nicht wundern wenn  die “Komunikation” zur Datenbank jetzt auch geändert wurde.
http://community.shopware.com/_detail_1921_441.html#Freitextfeld-Verwaltung_-_Attribute

https://developers.shopware.com/developers-guide/shopware-5-upgrade-guide-for-developers/?_ga=1.237308677.40845836.1463812834#attribute-management

Uwe 

Hallo Uwe,

danke - das ist mir schon klar und die Dokumente hatte ich auch schon überflogen. Die Frage ist halt, wie das Plugin angepasst werden muss und das dürfte eine Menge solcher Plugins betreffen (und auch den Beispielcode unter http://community.shopware.com/Schuhgrößen-Erweiterung_detail_1052.html#Erweiterung_der_Kundendetails). Aber vielleicht ist das alles noch ein bischen früh, ist ja die allererste Beta.

 

Darüber bin ich auch gerade gestolpert. Ich denke bzw. hoffe das es da in den kommenden Tagen mehr Infos gibt.

Durchs überfliegen der Änderungen hab ich festgestellt,

die assoicationen in den Extjs-Models wurden, deshalb gibt es den prefix “attribute[” nicht mehr und das dazugehörigen Doctrine Zeug zum speichern.

Ích meine auf dem in den Talks am Community Day gehört zu haben, dass man beides machen kann via Backend definieren oder die “alte” Methode. Sieht bisher jedoch nicht so aus -,-

Wenn dein Feld nicht komplex ist, kannst du auch via Service im AttributeBundle beim Plugin Installieren das Feld im neuen Attribute System anlegen.

Moin zusammen,

die Attribute können nicht mehr geladen und gespeichert werden wie früher. Die neuen Attribute laden und Speichern sich selbst automatisch. Für einfache Datentypen sowie Verknüpfung von Entities könnt ihr einfach einen Eintrag in der s_attribute_configuration schreiben und das Attribute lädt und speichert sich automatisch ohne das Ihr im Backend was anpassen müsst.

Wenn Ihr spezielle Anpassungen machen möchtet um die Darstellung zu modifizieren, könnt ihr die ExtJS-Klasse Shopware.attribute.Form erweitern und dort die Funktion „createFields“ überschreiben.

Hoffe damit kommt ihr erstmal zurecht. 

 

 

2 Likes

@Oliver Skroblin schrieb:

Moin zusammen,

die Attribute können nicht mehr geladen und gespeichert werden wie früher. Die neuen Attribute laden und Speichern sich selbst automatisch. Für einfache Datentypen sowie Verknüpfung von Entities könnt ihr einfach einen Eintrag in der s_attribute_configuration schreiben und das Attribute lädt und speichert sich automatisch ohne das Ihr im Backend was anpassen müsst.

Wenn Ihr spezielle Anpassungen machen möchtet um die Darstellung zu modifizieren, könnt ihr die ExtJS-Klasse Shopware.attribute.Form erweitern und dort die Funktion „createFields“ überschreiben.

Hoffe damit kommt ihr erstmal zurecht. 

Danke ersteinmal dafür, eigentlich sind die neuen Attribute ja eine prima Sache.

In der Tat möchte/muss ich aber Attribute an bestimmten Stellen im Detailformular darstellen, und nicht gesammelt am Ende. Gibt es (oder wird es geben) einen Boilerplate-Code oder ein kurzes Snippet für das Überschreiben von Shopware.attribute.Form? 

Und insgesamt erhöht das die Komplexität der Plugins und erschwert die Wartbarkeit, da ja die neue Methode nicht in Versionen < 5.2 zur Verfügung steht, und umgekehrt, es muss also doppelter Code rein, oder es müssen zwei Plugin-Versionen gepflegt werden (erfahrungsgemäß wird es immer Shopbetreiber geben, die nicht sofort updaten), so ganz glücklich bin ich daher nicht damit.

Grüße
Nils
netzperfekt.de

Hallo,

gibt es hierzu schon etwas neues, [@Oliver Skroblin](http://forum.shopware.com/profile/1871/Oliver Skroblin “Oliver Skroblin”)‍ , [@Daniel Nögel](http://forum.shopware.com/profile/4010/Daniel Nögel “Daniel Nögel”)‍ , [@Stephan Pohl](http://forum.shopware.com/profile/2/Stephan Pohl “Stephan Pohl”)‍ , [@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski “Moritz Naczenski”)‍ ? Ein kleines Beispiel, wie das ganze ab Version 5.2.0 aussehen muss, wäre wirklich toll. Vor allem wenn man beispielsweise ein eigenes Fieldset in die Artikel-Bearbeitungsmaske eingefügt hat, das viele Attributfelder beinhaltet, die man im Frontend anzeigt (Selectfelder, Eingabefelder, TinyMCE-Felder, etc).

Sonst wird der “Aufschrei” zum Release von 5.2.0 groß sein, wenn viele Drittanbieter-Plugins nicht kompatibel dazu sind.

Der entsprechende “Snippet” zu dem Thema ist aus meiner Sicht schon arg kurz gefasst: Shopware 5 upgrade guide . Den genannten Pfad "All components regarding attributes can be found in themes/backend/base/attribute" gibt es bei mir auch nicht, maximal “themes/Backend/ExtJs/backend/base”, aber auch keinen Ordner attribute.

Angezeigt werden die Attributfelder alle in der Artikel-Bearbeitungsmaske im Backend - nur eben ohne Inhalt, da sich das Laden und Speichern ja in Shopware Version 5.2.0 komplett geändert hat. Hier wäre es super nett, wenn es ein kleines Beispielplugin geben könnte, damit man auch nicht an Shopware vorbei entwickelt. Beispielsweise wie das ganze an einem eigenen Attributfeld wie “netzpAnnounced” aussehen soll, da sich ja bei der Darstellung scheinbar gar nichts geändert hat, sondern nur beim Laden und Speichern des Feldes.

Beste Grüße

Sebastian

hier meine erste test für Bootstrap.php install method (ist nicht für artikel, aber sollte eindeutig sein was zu ändern ist):

if ($this->assertMinimumVersion('5.2')) {
    $this->get('shopware_attribute.crud_service')->update(
        's_categories_attributes',
        'attribute1',
        'attribute1',
        'integer',
        [
            'label' => 'foo bar',
            'helpText' => 'hello world',
            'displayInBackend' => true,
            'pluginId' => $this->getId()
        ]
    );
}

scheint zu funktionieren. aber wie man diese in backend außerhalb der “Freitextfelder” fieldset bewegt, oder min/max werte definiert, weiss ich nicht (wahrscheinlich weiterhin über extjs). und ich hoffe es ist eine feature das wir crudservice update auch benutzen können wenn diese eintrag noch nicht existiert! (ich möchte nicht prüfen müssen ob es existert und dann extra create benutzen ;P)

nützliche referenzen:
shopware/README.md at 5.2 · shopware/shopware · GitHub
shopware/Configuration.php at 5.2 · shopware/shopware · GitHub
shopware/TypeMapping.php at 5.2 · shopware/shopware · GitHub

ps. für was wird die pluginId benutzt? ist $this->getId() überhaupt die richtige id?

Hallo wontfix,

du hast also auch noch keine direkte Lösung oder ein Code-Schnipsel gefunden, dass das Auslesen und Speichern eigener Felder innerhalb von eigenen Fieldsets zeigt und realisiert (beispielsweise in der Artikel-Bearbeitungsmaske des Shopware Backends)?

Ich versteh auch nicht, wieso dazu nicht einfach mal eine kleine Doku seitens Shopware geschrieben wird, wo beispielhaft ein eigenes, neues Feld hinzugefügt und im Shopware Backend ausgelesen und gespeichert wird. Es geht hier ja schließlich nicht nur um eine kleine Änderung. Schließlich möchte Shopware doch sicher auch, das Fremdanbieter - Plugins auch für die Shopware Version 5.2.0 kompatibel gemacht werden?

Dein Code-Schnipsel wird ja sicher nur für das Erstellen des zusätzlichen Feldes (in der install-Methode) nützlich sein oder? Danke erst einmal, dass du diesen mit uns teilst.

Beste Grüße

Sebastian

wenn es noch keine eintrag in s_*_attributes tabelle existiert, muss man anscheinend dies benutzen:

class Shopware_Plugins_Frontend_FoobaerArtikelAttribute_Bootstrap
extends Shopware_Components_Plugin_Bootstrap
{
    public function install ()
    {
        if ($this->assertMinimumVersion('5.2')) {
            $this->get('shopware_attribute.crud_service')->create(
                's_articles_attributes',
                'foobaer_1',
                'integer',
                [
                    'label' => 'Foobaer 1',
                    'displayInBackend' => true
                ]
            );
        }
        return true;
    }
}

diese erstellt die nötigen einträge in s_articles_attributes und s_attribute_configuration. laden/speichern in backend geht auch automagically. pretty cool!

und nein, mit extjs habe ich noch nicht rumgespielt…

ps. das crudservice update geht anscheinend nur wenn in s_*_attributes schon die eintrag existiert

pps. achso-ja, falls nicht klar, diese zeigt das feld „Foobaer 1“ in artikeldetails backend maske, unter „Freitextfelder“.

2 Likes

Wäre echt klasse wenn es hier Infos von Shopware dazu geben würde. Im Grunde funktioniert ja alles wie vorher (von der geänderten Install über den Crud Service mal abgesehen). Selbst das Auslesen der hinterlegten Daten funktioniert außerhalb des Fieldset der Freitextfelder. Nur werden keine Daten außerhalb mehr gespeichert.

@Creatixx schrieb:

Wäre echt klasse wenn es hier Infos von Shopware dazu geben würde. Im Grunde funktioniert ja alles wie vorher (von der geänderten Install über den Crud Service mal abgesehen). Selbst das Auslesen der hinterlegten Daten funktioniert außerhalb des Fieldset der Freitextfelder. Nur werden keine Daten außerhalb mehr gespeichert.

Hallo,

ja genau, wenn man Freitextfelder außerhalb des Fieldsets hat, werden diese weder ausgelesen noch gespeichert. Hier wäre wirklich mal eine Antwort von nöten, ob man jetzt das Plugin so umbauen soll, das alle zusätzlichen Felder im Freitextfeld-Fieldset aufgelisteten werden sollen oder ob es eine Möglichkeit gibt, weiterhin eigene Fieldsets etc. zu hinterlegen. Vor allem wäre hier auch ein Beispiel notwendig, wenn es auch weiterhin in einem eigenen Fieldset geht - oder wie soll sonst die Kompatibilität von (Fremdanbieter-)Plugins zu Shopware Version 5.2.0 hergestellt werden? Wenn die finale Version im Juni erscheinen soll, ist ja nicht wirklich viel Zeit mehr…

Wie funktioniert bei dir das Auslesen der Daten außerhalb des Artikel-Freitextfelder-Fieldsets @Creatixx‍ ?

Beste Grüße

Sebastian

@sschreier schrieb:

Hallo,

ja genau, wenn man Freitextfelder außerhalb des Fieldsets hat, werden diese weder ausgelesen noch gespeichert.

Sebastian

hmm… also bei mir werden sie außerhalb ausgelesen. nur speichern geht nicht!? 

@Creatixx schrieb:

@sschreier schrieb:

Hallo,

ja genau, wenn man Freitextfelder außerhalb des Fieldsets hat, werden diese weder ausgelesen noch gespeichert.

Sebastian

hmm… also bei mir werden sie außerhalb ausgelesen. nur speichern geht nicht!? 

Hallo,

meinst du damit das Auslesen im Shopware Frontend oder das die Daten der zusätzlichen Felder in das (Eingabe-)Feld im eigenen Fieldset übertragen werden?

Beste Grüße

Sebastian

@sschreier‍

Hi,

beides geht! Wie gesagt, nur speichern geht nicht außerhalb?! 

PS: Es könnte eventuell aber auch sein, dass sich die beiden Felder einfach überschreiben wenn in der Konfiguration des Freitextfeldes die Option im Backend anzeigen aktiv ist.

Das wird bei uns auch zum Problem werden. Wir nutzen zum Teil sehr viele Custom Attribute und die sollen auch nicht mit den regulären Freitextfeldern vermengt werden oder gar vom Kunden bearbeitet werden können. Ich finde die Attribute Verwaltung ideal für Shop-Betreiber, die selbst ihre Freitextfelder pflegen möchten. Für Agenturen ist es jedoch unabdingbar, dass Felder zu Attributen frei in den extjs Views platziert werden können.

Ich mein man könnte sich natürlich auch an den Backend Controller hängen und wie gehabt das attribute Array an die View übergeben bzw aus den Post Parametern via fromArray methode ans ORM übergeben. Das wäre allerdings keine schöne Lösung.

3 Likes

Da kann ich mich nur zustimmend anschließen. Ich hatte heute genaue die selbe Problematik auf dem Tisch.

Wir sind aktuell an der Dokumtation für das neue Attribute System dran. Nebenbei haben wir auch bereits ein kleines Beispiel Plugin geschrieben, welches neue Attribute hinzufügt, eigene Types implementiert, spalten hinzufügt welche der Benutzer ändern darf oder auch nicht.

Eine vorab Version des Beispiel Plugins könnt ihr hier einsehen:

https://github.com/shopware/devdocs/tree/attribute-system-developers-guide/exampleplugins/Frontend/SwagAttribute

Das Plugin ist auf Basis des neuen Plugin Systems und dem aktuell 5.2-Branch auf Github geschrieben, daher bitte manuel ins Dateisystem hochladen und eure Systeme aktualisieren da sich die API des CrudServices geändert hat

Zu euren Fragen / Problemen:

  • Wie füge ich ein Attribute hinzu und kann eigene Validierungen hinterlegen:
    • Hierfür könnt ihr euch das Attribute my_own_validation anschauen
  • Wie kann ich die Darstellung meines Attributes ändern/selbst definieren
    • Dafür haben wir im Plugin das Attribute my_own_type erstellt, welches aus 3x ExtJS-Textfeldern besteht aber nur eine Spalte in der Datenbank besitzt

Zuletzt noch die schwierigste Frage:

Wie kann ich ein Attribute ausserhalb des Freitext-Fieldsets darstellen:

Dies müsst ihr individuell lösen, da das Fieldset (Shopware.attribute.Form) in sich geschlossen ist. Ihr müsstet dementsprechend auch das Laden und Speichern komplett selbst steuern da bei den Haupt-Requests (z.B. beim Artikel) die Attribute nicht mehr mit geladen werden dürfen da sich sonst das Shopware.attribute.Form und das Module immer wieder gegenseitig überschreiben würden. Das Shopware.attribute.Form speichert jedoch auch nur die Daten, welche angezeigt werden, sprich wenn euer Attribute zwar in der Datenbank existiert jedoch nicht im Form angezeigt wird, so überschreibt das Form diese Daten beim Speichern nicht. Wichtig ist nur das Ihr eure Attribute auf NULLABLE=true stellt oder einen SQL Default definiert. Die neue Attribute Verwaltung arbeitet nicht mit den Doctrine Models sondern persistiert und lädt die Daten direkt über die Datenbank Connection.

 

 

Danke erstmal, aber die untenstehende Anmerkunge dürfte für erheblichen Unmut bei Plugin-Anbietern sorgen (nicht nur bei mir), hier müssen die Plugins teilweise neu entwickelt werden, für mich ist das kaum darstellbar, zumal der Weg für Attribute ausserhalb der Freitext-Sets immer noch nicht klar beschrieben ist.

@shopware: Bitte überdenkt das nochmal und bietet hier eine Abwärtskompatibilität an! Wurde nicht auf dem Community Day auch so etwas erzählt?

 

Zuletzt noch die schwierigste Frage:

Wie kann ich ein Attribute ausserhalb des Freitext-Fieldsets darstellen:

Dies müsst ihr individuell lösen, da das Fieldset (Shopware.attribute.Form) in sich geschlossen ist.

1 Like