SW 5.2 - Backend Plugin / eigene Attribute in Artikeldetails

Hi,

wir haben die API vom Crud Service noch einmal überarbeitet. Es gibt hier jetzt nur noch die update Funktion. Siehe dazu: Attribute system

Wenn das Plugin auch unter 5.2 kompatibel sein soll, musst du einen Versions switch einbauen. Also genau so wie du es beschrieben hast.

 

1 Like

Hallo Oliver,

das ist natürlich super, wenn man nur noch die update()-Funktion nutzen muss, egal ob man das Feld anlegen oder nur aktualisieren will. Danke Smile.

Muss ich das Update nur für die Einblenden, die Shopware Version 5.2.0 nutzen, oder kann ich das auch für alle freigeben („bereite“ ich mit $this->get(‚shopware_attribute.crud_service‘)->update() das Feld nur „vor“, oder zerhaut es mir dadurch auch das Verhalten der Felder bei eine Shopware Version unter 5.2.0) [@Oliver Skroblin](http://forum.shopware.com/profile/1871/Oliver Skroblin „Oliver Skroblin“)‍ ?

Kann ich auch weiterhin von " extends Shopware_Components_Plugin_Bootstrap"  ableiten oder muss ich das Plugin umbauen, das es von „Plugin“ ableitet (um die Services nutzen zu können)?

Danke für die (ausführlichere) Dokumentation Halo.

Beste Grüße

Sebastian

 

Unter 5.2 kannst du nicht auf den Service  ‘shopware_attribute.crud_service’ zugreifen da dieser erst mit 5.2 eingefügt wurde. Daher hier der Versions check.

Die update Methode erstellt/aktualisiert zunächst nur ein Element in der Datenbank. Um es im Backend anzuzeigen musst du entsprechend die Konfiguration mit übergeben (siehe doku dazu).

Der Service selbst (sprich der crud_service) kannst du im alten und im neuen Plugin system verwenden. Dieser hat darauf keine Abhängigkeit.

@Oliver Skroblin schrieb:

Unter 5.2 kannst du nicht auf den Service  ‘shopware_attribute.crud_service’ zugreifen da dieser erst mit 5.2 eingefügt wurde. Daher hier der Versions check.

Die update Methode erstellt/aktualisiert zunächst nur ein Element in der Datenbank. Um es im Backend anzuzeigen musst du entsprechend die Konfiguration mit übergeben (siehe doku dazu).

Der Service selbst (sprich der crud_service) kannst du im alten und im neuen Plugin system verwenden. Dieser hat darauf keine Abhängigkeit.

Hallo,

also kann ich weiterhin:

class SwagAttribute extends Shopware_Components_Plugin_Bootstrap {
     ...
}

verwenden und muss nicht unbedingt auf:

class SwagAttribute extends Plugin {
     ...
}

wechseln?

Sollte man am besten das Update nur für 5.2.0 freigeben?

Beste Grüße

Sebastian

Also… entweder baust du ein Plugin auf dem neuen System, was dann auch nur mit 5.2 lauffähig ist, da es erst ab dann das neue System gibt. 

Wenn du jedoch auch die 5.1 z.B. mit supporten willst musst du das ganze auf dem alten System bauen. Dann darfst du auch nicht von der 

Shopware\Components\Plugin; Klasse ableiten, da es diese erst ab 5.2 gibt.

Genauso wie der CrudService vom AttributeBundle, dieser wurde erst mit 5.2 eingebaut, sprich den kannst du nur mit einem vorherigen Versionscheck  verwenden. 

1 Like

Hallo,

ich habe wohl den Fehler bei mir gefunden: scheinbar darf man seit Shopware Version 5.2.0 keine Großbuchstaben mehr in den Spaltennamen verwenden - nenne ich das Feld nämlich einfach attr_myfield, klappt alles (da selbst attr_MyField2 nicht funktioniert hat, kann es nur an der Großschreibung liegen). Das macht es natürlich nicht besser, da mein Spaltenname nunmal einen Großbuchstaben im Namen hat.

Mit diesem Code funktioniert es leider nicht (obwohl ja in shopware/README.md at 5.2 · shopware/shopware · GitHub so beschrieben), den Spaltennamen komplett in Kleinbuchstaben umzuwandeln:

$this->get('shopware_attribute.crud_service')->update(
     's_articles_attributes',
     'attr_MyField',
     'attr_myfield',
     'html',
     [
          'label' => 'MyField',
          'translatable' => true,
          'displayInBackend' => true,
          'position' => 1,
          'custom' => false
     ]
);

Bei dem Code kommt folgende Fehlermeldung:

Unable to update, got exception: An exception occurred while executing 'INSERT INTO s_attribute_configuration (table_name, column_name, column_type, entity, label, help_text, support_text, translatable, display_in_backend, custom, position, array_store) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)' with params [null, null, null, null, null, null, null, 0, 0, 0, 0, null]: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'table_name' cannot be null 

Ich gehe davon aus, dass das deshalb nicht funktioniert, da der alte und der neue Spaltenname (in dem Sinne) ja gleich sind - sich eben nur durch zwei Großbuchstaben unterscheiden und er deshalb die Spalte nicht neu erstellt.

Beste Grüße

Sebastian

Als Entwickler und Shop-Betreiber bin ich von der neuen Attributverwaltung sehr hin- und hergerissen. Einerseits finde ich es sehr positiv, dass das Thema mal eine solide Basis bekommt und man in Zukunft (hoffentlich) einfacher mit den Attributen arbeiten kann.

Anderseits bin ich wie viele andere hier auch sehr unzufrieden mit dem neuen Ansatz, dass die Attribute quasi nun standardmäßig auf den Bereich „Freitextfelder“ beschränkt werden sollen und nur (wieder) durch Rumgefrickel dort herausgenommen werden können, ohne dass es dafür einen standardisierten Weg geben soll. Wo ist denn da letztendlich der Vorteil für den Shopbetreiber, für den letztendlich Shopware doch entwickelt wird?

Welcher Shopbetreiber möchte denn seine verschiedenen Anpassungen thematisch durcheinandergewürfelt am Ende einer Detailseite versteckt haben? Meiner Meinung nach für ein so modernes System wie Shopware ein vollkommen falscher Ansatz und ein großer Schritt rückwärts in der Flexibilität. Für Plugin-Entwickler, die einfach nur Geld machen wollen und denen Usability unwichtig ist, mag das zwar ein willkommender Weg sein, aber ich kann mir nicht vorstellen, dass das im allgemeinen Interesse der Community entwickelt wurde.

Ich hoffe, an dem Konzept wird noch gearbeitet und Fre itextfelder können in Shopware auch wirklich frei verwendet werden und nicht müssen nicht aufgrund der Codebasis so eingeschränkt werden. :frowning:

@carl schrieb:

Als Entwickler und Shop-Betreiber bin ich von der neuen Attributverwaltung sehr hin- und hergerissen. Einerseits finde ich es sehr positiv, dass das Thema mal eine solide Basis bekommt und man in Zukunft (hoffentlich) einfacher mit den Attributen arbeiten kann.

Anderseits bin ich wie viele andere hier auch sehr unzufrieden mit dem neuen Ansatz, dass die Attribute quasi nun standardmäßig auf den Bereich “Freitextfelder” beschränkt werden sollen und nur (wieder) durch Rumgefrickel dort herausgenommen werden können, ohne dass es dafür einen standardisierten Weg geben soll. Wo ist denn da letztendlich der Vorteil für den Shopbetreiber, für den letztendlich Shopware doch entwickelt wird?

Welcher Shopbetreiber möchte denn seine verschiedenen Anpassungen thematisch durcheinandergewürfelt am Ende einer Detailseite versteckt haben? Meiner Meinung nach für ein so modernes System wie Shopware ein vollkommen falscher Ansatz und ein großer Schritt rückwärts in der Flexibilität. Für Plugin-Entwickler, die einfach nur Geld machen wollen und denen Usability unwichtig ist, mag das zwar ein willkommender Weg sein, aber ich kann mir nicht vorstellen, dass das im allgemeinen Interesse der Community entwickelt wurde.

Ich hoffe, an dem Konzept wird noch gearbeitet und Fre itextfelder können in Shopware auch wirklich frei verwendet werden und nicht müssen nicht aufgrund der Codebasis so eingeschränkt werden. :(

Hallo,

ich würde auch eher dazu neigen zu sagen, dass es von Shopware auch nicht mehr gewünscht ist, dass man eigene Freitextfelder außerhalb des Freitextfeld-Fieldsets platziert - sonst gäbe es dafür ja einen Workaround oder zumindestens eine Doku, wo es mit einem Beispiel erklärt ist. Und man muss sich auch immer die Frage stellen: selbst wenn es durch irgendein “rumgefrickel” möglich wäre, die eigenen Freitextfelder außerhalb des Fieldsets zu platzieren - wie lange noch? Es ist ja nicht der Weg, den Shopware selbst wünscht - man soll ja schließlich das Freitextfeld-Fieldset von Shopware nutzen. Hier wäre dann also auch wieder zu bedenken, ob der “Workaround” dann überhaupt noch lange funktioniert und auch das platzieren außerhalb irgendwann ganz entfallen muss. Ich würde also nicht sagen, das ein Hersteller da “nur das große Geld machen will”, sondern einfach nur die Shopware - Regeln einhalten möchte und zukunftsorientiert entwickelt. Zumal es dafür ja nicht mal eine (shopware-konforme) Dokumentation gibt, wie es außerhalb vom Fieldset weiterhin (gut) funktionieren kann - nicht jeder Onlineshop hat schließlich das beste Hosting im Hintergrund.

Da Shopware 5.2.0 laut Aussage von Shopware noch diesen Monat erscheinen wird, wird auch die neue Freitextfeld-Verwaltung so bestehen bleiben.

Beste Grüße

Sebastian

 

Aus Sicht der Usability und eines Shopbetreiber der nicht über eine WAWI arbeitet, sondern im Backend selber die Daten pflegt, ist es ein Unding bei Eingaben die eigentlich zusammen gehören runter und rauf zu scrollen. Auch macht es das Ganze unübersichtlicher!

Auch verstehe ich nicht so ganz was es für einen Vorteil für Shopbetreiber haben soll, wenn Sie jetzt einfach per Klick überall ein Freitextfeld erzeugen können. Die entsprechenden Ausgaben/Logiken müssen ja trotzdem im Frontend selber eingebaut werden!?

Hallo zusammen,

ich habe das Ganze noch einmal etwas in den DevDocs dokumentiert, wie man die Felder außerhalb des Fieldsets positionieren und verarbeiten kann. Falls dieser noch ergänzt werden sollte, lasst es mich wissen.

Den Guide findet ihr unter Attribute system

LG, Jan

4 Likes

@Jan Bücker schrieb:

Hallo zusammen,

ich habe das Ganze noch einmal etwas in den DevDocs dokumentiert, wie man die Felder außerhalb des Fieldsets positionieren und verarbeiten kann. Falls dieser noch ergänzt werden sollte, lasst es mich wissen.

Den Guide findet ihr unter https://developers.shopware.com/developers-guide/attribute-system/#move-attribute-fields-into-anoth

LG, Jan

Hallo Jan,

danke für deine Mühe.

Ich konnte das soweit für mich adaptieren. Ich erzeuge ein eigenes Fieldset mit eigenem Feld durch:

//{block name="backend/article/view/detail/window" append}

Ext.define('Shopware.apps.Article.view.detail.MyWindow', {
	/**
     * Defines an override applied to a class.
     * @string
     */
    override: 'Shopware.apps.Article.view.detail.Window',

	createBaseTab: function() {
		var me = this;
 
        /* Call the original method and store its result */
        var panelTab = me.callParent(arguments);
 
		me.field = Ext.create('Ext.form.field.Text', {
			name: 'attribute[attrField]',
			fieldLabel: 'Mein Feld',
            allowBlank: false,
            anchor:'100%',
            labelWidth:150,
			translatable: true,
			translationName: 'attrField',
        });
		
		/* Create new FieldSet with the new panel inside */
		fieldset = Ext.create('Ext.form.FieldSet', {
            layout: 'anchor',
            title: 'Fieldset',
            items: [
                me.field 
			]
		});	
 
        /* After the overridden createBaseTab method was called, save to access the detailForm attribute */
        me.detailForm.insert(1, fieldset);
 
        /* Return original method's result */
        return panelTab;
    },
    onStoresLoaded: function() {
        var me = this;

        me.callParent(arguments);

        Ext.Ajax.request({
            url: '{url controller=AttributeData action=loadData}',
            params: {
                _foreignKey: me.article.get('mainDetailId'),
                _table: 's_articles_attributes'
            },
            success: function(responseData, request) {
                var response = Ext.JSON.decode(responseData.responseText);

                me.field.setValue(response.data['__attribute_attr_field']);
            }
        });
    }
});
//{/block}

Das Laden klappt somit problemlos.

Nur beim Speichern komme ich nicht weiter, da ich nicht genau weiss, beim welchem “Einstiegspunkt” ich einsetze könnte, da sich mein Feld ja nicht im Base-Fieldset befindet:

__attribute_attr_field: me.getBaseFieldSet().attrField.getValue()

Hast du eine Idee, wie ich da ansetzen müsste?

Beste Grüße

Sebastian

1 Like

Schau dir mal in themes/Backend/ExtJs/backend/article/controller/detail.js die Property refs an. Dort findest du Referenzen, die du z.B. per me.getBaseFieldSet() respektive me.getMainWindow() aufrufen kannst. Das sind im Prinzip fertige Selektoren für die einzelnen Windows, Fieldsets usw.

LG, Jan

@Jan Bücker schrieb:

Schau dir mal in themes/Backend/ExtJs/backend/article/controller/detail.js die Property refs an. Dort findest du Referenzen, die du z.B. per me.getBaseFieldSet() respektive me.getMainWindow() aufrufen kannst. Das sind im Prinzip fertige Selektoren für die einzelnen Windows, Fieldsets usw.

LG, Jan

Hallo Jan,

ich habe gestern noch eine Lösung gefunden, die so auch funktioniert:

me.getDetailForm().getForm().getFieldValues()['attribute[attrField]']

Wäre diese Lösung Best Practise?

 

Kann es sein, dass deine Lösung (Attribute system) nicht für Varianten möglich ist? Wenn ich onStoresLoaded bei meiner Varianten-Datei analog der window-Datei hinschreibe, wird die Funktion nicht ausgeführt und der Inhalt nicht in das Feld geladen (habe auch einfach mal einen console-Log-Befehl hinzugefügt, der wird nicht ausgegeben, also wird bei Varianten scheinbar onStoresLoaded nicht genutzt). Das wird sicher auch daran liegen, das es in der detail.js nicht wie in der window.js in der initComponent() keinen Einstiegspunkt gibt, oder? Diesen hier gibt es nur in der window.js:

me.on('storesLoaded', me.onStoresLoaded, me);

Somit kann man sich bei Varianten nirgends einklicken, um den Inhalt reinzuladen, oder? Zum Speichern könnte man sich ja maximal bei saveVariant dranhängen.

Die Lösung ist ja somit für Variantenartikel-Freitextfelder nicht einsetzbar, oder?

Beste Grüße

Sebastian

Hallo(http://forum.shopware.com/profile/21387/Jan Bücker „Jan Bücker“)[@Jan Bücker](http://forum.shopware.com/profile/21387/Jan Bücker „Jan Bücker“)‍,

ich würde gerne noch einmal bei dem Thema nachhaken. Die Lösung von dir (und somit aus der Dokumentation) funktioniert ja nur bei eigenen (Freitext-)Feldern, die nicht variantenfähig sind (also nur bei Hauptartikeln). Oder wo müsste man da ansetzen, um dies auch bei Varianten zu ermöglichen (siehe mein Kommentar)?

Das heisst also auch im Umkehrschluss, da ja der Final Release von Shopware Version 5.2 schon vollzogen wurde, sollte man die eigenen Freitextfeldern (mit Variantenfähigkeit) nun erstmal im Freitextfeld-Fieldset von Shopware platzieren, damit die Käufer das Plugin auch gleich zum Release nutzen können?

 

Alternativ könnte man ja später auch über einen Update - Befehl auf die s_attribute_configuration - Tabelle und dem entsprechenden Feldnamen die Anzeige im Backend im Nachhinein wieder deaktivieren und die Platzierung außerhalb (sofern das Laden und Speichern für die Varianten auch möglich sein wird) implementieren?

Beste Grüße

Sebastian

Das Beispiel aus der Dokumentation veranschaulicht lediglich wie man allgemein die Felder benutzen kann. Das soll nicht als real-world Beispiel dienen, sondern die generelle Vorgehensweise voranschaulichen. Wenn du dieses Beispiel variantenfähig machen möchtest, musst du dort selbst nochmal nach suchen und es dementsprechend anpassen.

Wenn du es umgesetzt hast, können wir den Code auch gerne mit in die Dokumentation übernehmen. :slight_smile:

Hallo [@Jan Bücker](http://forum.shopware.com/profile/21387/Jan Bücker „Jan Bücker“)‍,

ich habe dein Beispiel getestet und komme damit auch zu guten Ergebnissen. Leider harpert es noch bei „ComboBox“-Felder mit einem Ajax-Store. Hierbei gibt die „ComboBox“ immer die Id aus nicht nicht den dazugehörigen Datensatz. Gibt es eine Dokumentation wie man den Wert korrekt setzen muss?

Grüße
Ingo Walther

1 Like

Ich muss mich auch kurz einhaken, eigene Attribute in der DB erweitern ist aber mit …

        $this->Application()->Models()->addAttribute(
            's_categories_attributes',
            'foo',
            'foo_column',
            'varchar(100)',
            true,
            null
        );

        Shopware()->Models()->generateAttributeModels(
            array(
                's_categories_attributes'
            )
        );

… weiterhin so gedacht, korrekt? Weil, das klappt in allen Shop-Versionen bisher so getestet - ich würde aber natürlich gerne sicher gehen, dass das auch so gedacht ist :slight_smile:

Nachtrag : Ok, habe jetzt die passende Antwort gelesen. Versionscheck machen, ab 5.2 den Crud-Service verwenden und gut. Pribiere ich aus :wink:

Schöne Grüße,
Niklas

@TeichDatensysteme schrieb:

Ich muss mich auch kurz einhaken, eigene Attribute in der DB erweitern ist aber mit …

$this->Application()->Models()->addAttribute(
‘s_categories_attributes’,
‘foo’,
‘foo_column’,
‘varchar(100)’,
true,
null
);

Shopware()->Models()->generateAttributeModels(
array(
‘s_categories_attributes’
)
);

… weiterhin so gedacht, korrekt? Weil, das klappt in allen Shop-Versionen bisher so getestet - ich würde aber natürlich gerne sicher gehen, dass das auch so gedacht ist :)

EDIT: Ok, habe jetzt die passende Antwort gelesen. Versionscheck machen, ab 5.2 den Crud-Service verwenden und gut. Pribiere ich aus ;)

Schöne Grüße,
Niklas

Hallo,

ja bei Versionen unterhalb von Shopware Version 5.2 ist das weiterhin so gedacht, eigene Felder anzulegen. Der crud service steht erst ab Shopware Version 5.2 zur Verfügung und muss ab da verwendet werden.

Beste Grüße

Sebastian

Danke für den Hinweis, Sebastian - klappt.

Weiteres:  Bis 5.2 habe ich das Attribut im create/update einfach mitgegeben, im key - attributes mit dem weiteren key der eigenen Attributs- Spalte:

$category = array(
            'parentId' => $parentId,
            'name' => $name,
            'active' => true,
            'attribute' => array(
                'fooColumn' => $fooValue
            )
        );

Ist das immer noch “valide” oder “muss” man ab 5.2 DataPersister nutzen? Mein Beispiel würde so aussehen:

/**
* @var \Shopware\Bundle\AttributeBundle\Service\DataPersister $service
*/

$service = Shopware()->Container()->get('shopware_attribute.data_persister');

$service->persist(
	array(
		'foo_column' => $fooValue
	),
	's_categories_attributes',
	$categoryId
);

So wie ich das der Doku entnehmen kann (da kein gesonderter Hinweis existiert) ist das setzen über das ‘attribute’ Array im normalen update/create für Standard-Attribute attr1 - attr20 weiterhin kein Problem?

Bezüglich Selektion, ist es noch OK per attributes zu selektieren, oder “muss” man das ab 5.2 ausschließlich per DataLoader machen?
Ich habe z.B. eine Hilfsfunktion zum selektieren spezieller Kategorien über ein eigenes Attribut

protected function getCategoryByUniqueId($uniqueId)
    {

        $filters = array(array('property' => 'attributes.fooColumn', 'expression' => '=', 'value' => $uniqueId));

        $query = $this->getCategoryResource()->getRepository()->getListQuery($filters, array(), 1);

        return $query->getOneOrNullResult($this->getCategoryResource()->getResultMode());

    }

Das funktioniert immer noch wie gewünscht, über Shopware\Models\Category\Repository::getListQueryBuilder::after erweitere ich den QueryBuilder mit meinem eigenen Attribut, welches ich wie oben dann gewünscht selektieren kann. Wie gesagt jetzt Frage, ob es da andere “bevorzugtere” Wege gibt - freue mich über Feedback!

Schöne Grüße!
Niklas

@em_iw schrieb:

Hallo [@Jan Bücker](http://forum.shopware.com/profile/21387/Jan Bücker „Jan Bücker“)‍,

ich habe dein Beispiel getestet und komme damit auch zu guten Ergebnissen. Leider harpert es noch bei „ComboBox“-Felder mit einem Ajax-Store. Hierbei gibt die „ComboBox“ immer die Id aus nicht nicht den dazugehörigen Datensatz. Gibt es eine Dokumentation wie man den Wert korrekt setzen muss?

Grüße
Ingo Walther

Hallo Zusammen,

gibt es bereis eine Lösung für das ComboBox-Problem wie oben beschrieben. Habe nähmlich auch das Problem.

Beste Grüße,

Denis