Plugin Attribute Fehler bei Update und Installation

Hallo Community, 

ich nutze seit Längerem bereits den CrudService zur Anlage von Freitextfeldern / Attributen über ein Plugin. Dabei ist es letztens bei zwei Kunden zu einem Fehler gekommen, welchen ich jedoch nicht nachvollziehen kann: 

You're trying to decode an invalid JSON String: Fatal error: [...]

(*Leider kann ich die genaue Fehlermeldung gerade nicht mehr wiedergeben. Auch ist diese von Shop zu Shop bisher unterschiedlich gewesen… Jedenfalls führt dies zu einem 500 Fehler und verweist auf irgendwelche php-Dateien im Enginge-Order wie zum Beispiel die …\engine\Shopware\Models\Customer\Billing.php)

 

Es kommt zu dem Fehler und das Plugin kann weder installiert noch deinstalliert werden, wenn:

  1. beim Installieren die Freitextfelder bereits existieren
  2. beim Update wenn die Freitextfelder bereits existieren
  3. beim D einstallieren , wenn die Freitextfelder nicht existieren

Wie kann das sein? In Fall 1 und 2 dürfte gar kein Fehler kommen, weil die Attribute geupdatet werden. Und in Fall 3 fange ich das mit try catch ab und lasse die Deinstallation weiter laufen. 
Ich konnte das bei mir in der Entwicklungsumgebung nicht nachstellen. Das Problem trat bei 5.2.2 und bei 5.3.3 zweier Kunden auf.

 

Hier der Code für die Felder:

assertMinimumVersion('5.2')) {
			$this->createAttributes();
		}

		return true;
	}

	/**
	 * The Plugin update method
	 *
	 * @param string $oldVersion
	 * @throws Exception
	 * @return array
	 */
	public function update($oldVersion)
	{

		if ($this->assertMinimumVersion('5.2')) {
			$this->createAttributes();
		}

		return [
			'success' => true,
			'invalidateCache' => $this->getInvalidateCache()
		];
	}

	/* Plugin Deinstallation */
	public function uninstall()
	{

		$this->secureUninstall();

		$this->removeAttributes();

		return ['success' => true, 'invalidateCache' => $this->getInvalidateCache()];
	}

	/**
	 * @return array
	 */
	public function secureUninstall()
	{
		return ['success' => true, 'invalidateCache' => $this->getInvalidateCache()];
	}

	/**
	 * Helper method to return all the caches, that need to be cleared after uninstalling/enabling/disabling a plugin
	 *
	 * @return array
	 */
	private function getInvalidateCache()
	{
		return ['frontend', 'backend', 'theme'];
	}

	

	private function createAttributes()
	{
		/** @var CrudService $Service */
		$service = Shopware()->Container()->get('shopware_attribute.crud_service');

		$service->update('s_articles_attributes', 'prefix_foo_attr', 'boolean', [
			'label' => 'Label',
			'supportText' => 'supportText',
			'helpText' => 'helpText',
			'translatable' => true,
			'displayInBackend' => true,
			'position' => 100
		]);

		$service->update('s_articles_attributes', 'prefix_foobar_attr', 'boolean', [
			'label' => 'Label',
			'supportText' => 'supportText',
			'helpText' => 'helpText',
			'translatable' => true,
			'displayInBackend' => true,
			'position' => 110
		]);

		$metaDataCache = Shopware()->Models()->getConfiguration()->getMetadataCacheImpl();
		$metaDataCache->deleteAll();

		Shopware()->Models()->generateAttributeModels(['s_articles_attributes']);
	}

	private function removeAttributes()
	{
		/** @var CrudService $Service */
		$service = Shopware()->Container()->get('shopware_attribute.crud_service');

		try {

			$service->delete('s_articles_attributes', 'prefix_foo_attr');
			$service->delete('s_articles_attributes', 'prefix_foobar_attr');

		} catch (Exception $e) {
			
			// ignore Exception

		}

		Shopware()->Models()->generateAttributeModels(['s_articles_attributes']);

	}
}

 

Hallo mdsw,

ich habe gerade einen ähnlichen Fall - auf meinem Entwicklungsserver mit Shopware 5.2.21 funktioniert das Plugin, in einem staging-System mit 5.2.16 nicht. Auch bei mir lässt sich der Fehler auf die Funktion 

Shopware()->Models()->generateAttributeModels([‘s_categories_attributes’]);   

zurückführen - sobald ich diese aus dem Code rausnehme, lässt sich das Plugin installieren. Sonst schmiert PHP immer ab, hier meine Fehlermeldung:

[Tue Nov 21 12:16:53.395813 2017] [proxy_fcgi:error] [pid 35196] [client XXX.XXX.XXX.XXX:57349] AH01071: Got error ‘PHP message: PHP Fatal error:  Cannot declare class Shopware\Models\Order\Billing, because the name is already in use in /var/www/shopware/engine/Shopware/Models/Order/Billing.php on line 0\n’, referer: https://…/backend/

Interessant ist, dass die Funktion wohl nicht wirklich benötigt wird - auch ohne diese werden die Felder in die DB eingetragen und sind auch im Backend im entsprechenden Modul zu finden.

Die Frage ist nun, wozu die Funktion und woher der Fehler?

$metaDataCache = Shopware()->Models()->getConfiguration()->getMetadataCacheImpl();
$metaDataCache->deleteAll();
Shopware()->Models()->generateAttributeModels(['s_articles_attributes']);

Diese drei Zeilen braucht man mit dem CRUD Service nicht mehr. Das sind noch Relikte aus SW < 5.2.

1 „Gefällt mir“

Danke für den Hinweis, das dachte ich mir schon, da ja auch ohne alles an seinem Platze ist…

Hallo,

die drei Zeilen stören aber auch nicht und verursachen auch keine Fehler, weil Sie schlussendlich nur das entsprechende Model neu generieren sowie wie in der Freitextverwaltung und mehr auch nicht. Und auch über 5.2 ist es nicht unbedingt dumm, dies zu tun, damit man Cache - Probleme umgehen kann (beispielsweise bei Exports etc).

Beste Grüße 

Sebastian

@sschreier‍ - so ähnlich dachte ich auch, nur leider scheint das nicht in allen Konstellationen zu funktionieren. Ich vermute, es hat auch etwas mit dem PHP-Prozessor zu tun, da sich zumindest die Fehlermeldung nach Upgrade des PHP geändert hat. Primäre Ursache ist die Funktion generateAttributeModels - weiter hinein habe ich noch nicht debugged - aber mit PHP 7.0.22 hatte ich einen 503-Fehler und der PHP-Log sah so aus:

AH01067: Failed to read FastCGI header
(104)Connection reset by peer: [client XXX.XXX.XXX.XXX:3333] AH01075: Error dispatching request to : , referer: 

Nach Update auf v. 7.0.25 gibt es “nur noch” einen 500er-Fehler und die Fehlermeldung sieht so aus:

AH01071: Got error 'PHP message: PHP Fatal error:  Cannot declare class Shopware\Models\Order\Billing, because the name is already in use in /var/www/shopware/engine/Shopware/Models/Order/Billing.php on line 0\

Beide PHP-Versionen laufen als FPM in einem Apache 2.4

AH01071: Got error 'PHP message: PHP Fatal error: Cannot declare class Shopware\\Models\\Order\\Billing, because the name is already in use in /var/www/shopware/engine/Shopware/Models/Order/Billing.php on line 0\

Hatte ich so, oder so ähnlich auch, wie im Eingangsbeitrag beschrieben… Kann ich also bestätigen.

@sschreier schrieb:

Hallo,

die drei Zeilen stören aber auch nicht und verursachen auch keine Fehler, weil Sie schlussendlich nur das entsprechende Model neu generieren sowie wie in der Freitextverwaltung und mehr auch nicht. Und auch über 5.2 ist es nicht unbedingt dumm, dies zu tun, damit man Cache - Probleme umgehen kann (beispielsweise bei Exports etc).

Beste Grüße 

Sebastian 

Jut. Da hast du teilweise recht :wink: Also Zeilen 1 und 2 sind definitv überflüssig, das sie im Verlauf der generateAttributeModels() Methode sowieso auch aufgerufen werden. Und zumindest beim neuen Plugin System werden die Proxy Caches im Standard automatisch geleert. Gut, hier gehts um ein Legacy Plugin. Da wäre es schon sinnvoll.

@arnebecker‍ - scheinbar ist der Fehler, der aufgeworfen wird, aber der gleiche - egal, ob es ein Legacy oder ein neues Plugin ist - mein Plugin ist nach dem neuen 5.2er System und wirft den gleichen Fehler, wie das Legacy vom Thread-Starter.

Joah. Müsste man mal im Detail debuggen :wink:

Was wäre nun die Devise?

$metaDataCache = Shopware()->Models()->getConfiguration()->getMetadataCacheImpl();
$metaDataCache->deleteAll();
Shopware()->Models()->generateAttributeModels(['s_articles_attributes']);

Lässt man es drin, oder produziert man einen Fehler? Ich habe es drin, weil ohne diese Zeilen die Freitextfelder im Frontend nicht auftauchen - benötige Sie daher dringend. (Noch alte Plugin-Struktur)

@mdsw schrieb:

(*Leider kann ich die genaue Fehlermeldung gerade nicht mehr wiedergeben. Auch ist diese von Shop zu Shop bisher unterschiedlich gewesen… Jedenfalls führt dies zu einem 500 Fehler und verweist auf irgendwelche php-Dateien im Enginge-Order wie zum Beispiel die …\engine\Shopware\Models\Customer\Billing.php)

Die genauen Meldungen wären doch nochmal interessant. Vor allem wenn es auch unterschiedliche sind! Da ich den Fehler nicht reproduzieren kann, kann ich es auch nicht debuggen. Und eine Diagnose aus der Ferne ist so nicht weiter möglich.

Die Zeilen 1 und 2 sind definitv überflüssig. Zeile 3 würde ich dennoch ausführen. 

1 „Gefällt mir“
$metaDataCache = Shopware()->Models()->getConfiguration()->getMetadataCacheImpl();
$metaDataCache->deleteAll();

raus - auch bei der alten Plugin-Struktur?

Ja. Wie oben schon beschrieben, werden die beiden Methoden sowieso in der generateAttributeModels() aufgerufen.

1 „Gefällt mir“

Sollte dann nicht auch in der Doku das mal aktualisiert werden? Attribute system

Klar. Sollte man. Kannst du ja gerne machen. Die Docs sind open source. Da kannst du Änderungen vornehmen und dann einen Pull Request erstellen.

Hallo,

nur weil arnebecker das so sagt, muss das aber auch nicht so stimmen - schließlich hat seine Aussage noch nicht mal jemand von Shopware bestätigt und genau diese 3 Zeilen sind wie man sieht auch so in der offiziellen Dokumentation von Shopware zum neuen Pluginsystem / Attributsystem von Shopware. Und wenn Sie dort stehen, wird das auch seine Gründe haben und auch so bei Bedarf noch nötig sein.

Die 3 Zeilen schaden auch überhaupt nicht, man kann sie also auch weiterhin im Plugin belassen - egal ob altes oder neues System.

Beste Grüße

Sebastian

@sschreier‍ - auch wenn ich hier nicht der Verteidiger von arnebecker bin, muss ich doch sagen, dass nunmal gerade bei mir die letzte der 3 Zeilen definitiv ein Problem verursacht hat - nehme ich sie raus, funktioniert alles wie es soll. Wenn sie nötig wären, würde ich doch die Backend-Erweiterungen am Model - also die Anzeige der neuen Attribute auf den jeweiligen Artikel- oder Kategorieseiten - sehen.

@WolkeSoftware‍ - ich meine mich zu erinnern, dass ohne diese drei Zeilen keine der angelegten Attribute in der s_emotions_attributes Tabelle an das Frontend weitergereicht werden, da ohne Neugenerierung der Attribute-Models diese nicht im Smarty-Template zur Verfügung standen. In anderen Tabellen wiederum funktionierte es meiner Meinung nach auch ohne unteren Code.

$metaDataCache = Shopware()->Models()->getConfiguration()->getMetadataCacheImpl();
$metaDataCache->deleteAll();
Shopware()->Models()->generateAttributeModels(['s_articles_attributes']);

Das ist aber alles schon wieder eine Weile her und nicht weiter von mir dokumentiert oder weiter geprüft. fakt ist, dass ich Probleme mit den s_emotions_attributes hatte und nach diesen drei Zeilen nicht mehr.

@arnebecker‍

Irgendwie hatte mal wieder jeder ein bisschen Recht:

  1. wenn ich die Attribute nicht im eigenen Plugin selbst auslesen möchte, sonder diese durch Shopware im Frontend mitgezogen wurden, brauche ich die “ominösen” 3 Zeilen, ohne diese kommen die Daten nicht automatisch ins Frontend.

  2. die Erweiterung für das Backend geht auch ohne die 3 Zeilen, auch die DB-Einträge wird (zumindest ab 5.2-config) automatisch erzeugt

  3. und damit (hoffentlich) abschließend : liegt der Fehler wohl im SWAG-Security -Plugin. Sobald man dies dekativiert, das eigene Plugin aktualisiert bzw. neu installiert und danach das SWAG-Security wieder aktiviert, funktioniert alles auch mit den 3 Zeilen. Danke an Netinventors, die wohl den gleichen Fehler auch in ihren Plugins haben und diesen Bug schon bei Shopware gemeldet haben.