Blog - Hannes Pries - Webdeveloper Blog - Entwicklung mit Shopware, PHP, HTML5 und JavaScript

API Platform: Workflows und Resourcen erweitern

In den wenigsten Fällen, nutzt meine REST-API für einfache CRUD-Operationen. Oft muss man auf die Operationen auch reagieren. Z.B. will man, wenn eine neue Bestellung angelegt wird, auch eine Lager-Reservierung oder einen Export an das ERP anstoßen. Oder man hat Felder die übersetzt werden müssen. Auch will man bei bestimmten Resourcen wie Artikeln noch Metriken mitgeben, wie oft er verkauft wurde und ob er damit zu einem Top-Seller wird.

Für diese Anwendungsfälle stellt API Platform zwei verschiedene Konzepte zur Verfügung.

Data-Provider/Data-Persister
Wenn man wirklich Daten an der Resource ändern möchte, ist das hier der richtige Weg. Man greift hier direkt in die Persistierung ein. Der Data-Provider ist für das Laden und der Data-Persister, wie der Name schon sagt, für das Speichern zuständig. Damit man nicht die gesamte Grundlogik jedes Mal neu schreiben muss, kann man hier die vorhandenen Services dekorieren und den Ursprünglichen Service als Parent per Injektion mit rein reichen. Also klassisches Symfony. Wenn nun also Custom-Fields oder eine Sprache in der übergebenen Resource (in transient Fields) definiert sind, kann man die im Persister sich heraus picken und selber sich um die Speicherung
kümmern. Im Provider eben das selbe nur anders herum.

Nun kann man sich denken: "Ich will den Artikel mit seinen Änderungen gerne in einem ElasticSearch-Index haben, damit die Suche auch gleich aktuell ist." Aber dafür ist das der falsche Weg.

Events
Wie in Shopware sind hier Events der richtige Weg. Man greift dabei nicht in den Peristierungsvorgang ein und es kann weniger schief laufen. Jeder Subscriber arbeitet unabhängig und wenn einer fehlschlägt, sind die anderen Subscriber nicht eingeschränkt. Gerade bei den POST_WRITE-Events erhält man eine Kopie der Resource und sollte diese nicht ändern. Falls irgendwie der Entity-Manager in Zusammenhang mit der Resource verwendet wird.. sollte man zu den Persistern wechseln. Events nutzen nur die Daten und Ändern sie nicht. XML-Exports, Emails, Metriken... genau hier sind Events die ideale Lösung.

Wie in Shopware!

Shopware: kernel.environment bool Fehler mit console

Es kann dazu kommen, dass beim Aufruf der console von Shopware 5 keine kernel.environment gesetzt ist. Bei Webserver Aufrufen wird diese ja zumeist in der conf des Apache gesetzt.

Um jetzt die Environment (z.B. "production") direkt beim Aufruf der console zu setzen muss man die Option "e" setzen und schon geht alles.

./bin/console -e production

Shopware: Logger pro Plugin in 5.6

Jeder der ein Plugin verwendet, das viele Daten hin und her schaufelt und dieses auch immer protokolliert, kennt das Problem von zu großen Log-Files. Gerne hätte man schon immer Log-Files für bestimmte Anwendungsfälle geschrieben. Mit 5.6 ist es jetzt möglich wenigstens pro Plugin ein eigenes Log-File zu nutzen.

https://github.com/shopware/shopware/blob/5.6/UPGRADE-5.6.md#plugin-specific-logger

Jetzt muss ich nur noch ausprobieren, wie man dass möglichst einfach auch zu < 5.6 kompatibel hält.

Shopware 6: Plugin-Dev Schnellübersicht

Was ich zur Plugin-Entwicklung mit Shopware 6 nach dem ersten Kennen lernen bei der Shopware AG am 1.7. zu sagen habe:

- Varianten sind nun Produkte mit Parent
- Ids in der Datenbank sind nun UUUIDs (ramsey/uuid) die binär in der DB gespeichert werden
- Ein Plugin definiert sich allein durch eine composer.json und den darin enthaltenen Typ shopware-platform-plugin (ersetzt die plugin.xml) und PSR-4 Namespace und Plugin-Class werden darin definiert
- die Metadaten zum Plugin sind in der composer.json unter extra
- Changelog ist jetzte die CHANGELOG.md Datei und mit ISO-Lang Postfixes erhält man die verschiedenen Sprachen (soll wohl mal durch den Store ausgelesen werden können)
- ./bin/console plugin:create --create-config MySW6Plugin erstellt einen ein komplettes Plugin Skeleton mit Config-XML und passender composer.json
- src/Resources/views/ wird automatisch registriert (wenn man seine Views wo anders liegen hat kann man getViewPath überschreiben)
- in der Plugin-Config kann man card-Tags verwenden, um Blöcke zu bilden und alles besser strukturieren zu können
- man kann eigene Felder und View in die Plugin-Config einbringen, in dem man vor eine Vue-Component registriert hat und diese dort als <component name="MyComponent"/> angibt
- Plugin installieren: ./bin/console plugin:install --activate --clear-cache MySW6Plugin öfters ist ein refresh der Liste nötig und cache:clear sichert den liebgewonnen Workflow bei der Entwicklung mit Shopware :-)
- Es gibt kein Doctrine-ORM mehr sondern die eigene DAL die noch DBAL verwendet
- DAL ist so etwas wie ein halb fertiges ORM wo noch die Abstraktion wie Annotations fehlt und man deswegen die Beschreibung und Umwandlungen selbst per Hand vornehmen muss, so wie auch das Anlegen der DB-Tables
- Es gibt dort noch viel zu verbessern, aber das Grundgerüst funktioniert da schon sehr gut. Zu verbessern wäre z.B.: new IdField('id', 'id') auch als new IdField('id') schreiben zu können wenn DB-Column und Class-Field gleich bezeichnet sind
- die Field-Definition-Methode wird nur selten aufgerufen, deswegen kann man hier sonst auch eigene Lösungen wie CamelCase-Converter oder Annotion-Parser selbst integrieren
- Es gibt momentan immer 3 Klassen: Definition, Plain Old PHP Object und Collection (über @Method der eigenen Collection wird so etwas wie Generics versucht abzubilden... in Java wäre es nur List<MyEntity> list = ....)
- Es wir automatisch ein Repository für jede Entity erzeugt, das man mit Hilfe der service.xml injecten kann
- CLI, Subscriber, etc werden weiterhin über die service.xml verwaltet und implementieren nur andere Interfaces (sonst hat sich dort kaum was verändert)
- Es gibt keine Hooks mehr sondern nur noch Service-Decoration (wie die meisten wohl schon jetzt lieber verwendet haben) und eben die Events
- Es gibt mit der DAL ein Versions-Feld
- Änderungen an der Datenbank sollten über das Migration-System (Timestamp basiert) erledigt werden und nicht über die Lifecycle-Methoden des Plugins
- Es gibt Updates und destructive Update, die die Kompatibilität der DB zu älteren Plugin-Versionen zerstören. Beides kann getrennt ausgeführt werden (2 Phasen Update für Cluster-nodes)
- Die DAL unterstützt native Translated-Fields
- Extensions von Entities werden serialisiert in der DB gespeichert (ALTER TABLE, Extension, Serializer-Klasse, etc). Es gibt keine Attributes mehr.
- Gespeichert wird immer per Array (von Entity-Arrays) und es wird nicht das Object zum Speichern übergeben
- upsert (update or insert) ist da das neue merge
- Der Cart hat nun LineItems, die wiederum Children haben können
- LineItems sind nun vollkommen unabhängig von Produkten, es gibt nur noch ein Type und Enrichment-Handler, die Namen und Preise für diesen Type an das Item ran dekorieren
- ... damit kann man verschiedene Bestell-Modi wie "kaufen" und "ausleihen" pro Produkt zusammen in einem Warenkorb abbilden
- Die API stellt automatisch generierte Swagger-Beschreibungen bereit
- Es gibt mehrere APIs so dass nicht nur Datenspflege bestrieben werden kann, sondern auch komplette Bestellprozesse damit abgebildet werden können (damit kann man Shopware als Backend-Lösung für In-App-Käufe oder POS-Systeme verwenden)
- Dadurch kann man Shopware auch headless verwenden (ohne Storefron und Admin, oder nur mit einem davon)
- ein Product aht ein SalesChannelProduct... man kann dort bestimmt auch eine Stock-Quantity hinzufügen und so einen Sales-Channel abhängigen Lagerbestand implementieren (Jeder POS auf einen Event oder in Disco könnte ein eigener Sales-Channel werden und dann kann man genau
monitoren wo Getränke oder Verbrauchsmaterial zu neige geht und reagieren bevor die Mitarbeiter überhaupt merkten, dass in 15min wohl die Strohhalme ausgehen werden)

Insgesamt macht Shopware 6 einen wirklich sauberen und durch dachten Eindruck. Nur die Migrations brauchen noch etwas und die DAL könnte gut einen weiteren Layer drum herum gebrauchen (ich wäre für Annotations an der Entity-Klasse)

Shopware: Legacy-Plugin Service dekorieren

Gehen wir mal davon aus wir hätten noch ein Legacy-Plugin mit einer Bootstrap-php, die einen Service registriert, den wir dekorieren wollen. Über die services.xml geht so etwas nicht.

class HprTest extends Plugin{
public static function getSubscribedEvents(){
return [
'Enlight_Bootstrap_AfterInitResource_hpr_legacy.the_service' => 'decorateService',
];
}

public function decorateService()
{
$coreService = Shopware()->Container()->get('hpr_legacy.the_service');
$refl = new \ReflectionClass(get_class($coreService));

$field = $refl->getProperty('config');
$field->setAccessible(true);
$config = $field->getValue($coreService);

$service = new TheNewService($config);
Shopware()->Container()->set('hpr_legacy.the_service', $service;
}
}

Sehr sehr unschön.. aber es funktioniert so. Der Weg über die XML ist natürlich sehr viel schöner, gerade weil die Injection der Constructor Arguments vom ursprünglichen Service übernommen werden man nicht diese per Reflections erst einmal wieder aus dem ursprünglichen Service heraus gepult werden müssen.

Rewrite meines PHP-Frameworks

Zum 10. Geburtstag meines PHP-Frameworks wird sich da viel ändern und es damit dann wieder etwas mehr zu anderen Frameworks aufschließen können.

Mein eigener Class-Loader fliegt raus und es wird noch der ClassLoader vom Composer verwendet. Meiner kann zwar auch mit PSR4 umgehen, aber nach dem Umstieg muss ich dann auch alles darauf umstellen und habe keine Ausrede mehr, weil die Kompatibilität weg fällt.

Es gibt nun ein public-Verzeichnis so dass alle Config-Dateien und Classes außerhalb des Bereiches liegen, auf dem Benutzer zugreifen können. Das sorgt für mehr Sicherheit, macht das Laden von CSS und Bildern aus dem Theme-Verzeichnis aber komplizierter. Ich überlege hier auf Assetic umzusteigen. Momentan läuft meine Lösung aber sehr gut.

Und das Beste und wichtigste was aber auch am meisten Arbeit machen wird (darum habe ich ganz viele alte Module erst einmal gelöscht und lasse auch die alten PHP-Pages drin) ist, dass Module-Pages nun wirklich mit Controller und Twig-Template gerendert werden. Die Twig-Templates könenn vom Theme und von eigenes Templates in der Instance überschrieben werden und so kann man nun endlich das Aussehen der Module leicht und schnell anpassen.
Smarty war schon länger drin, wurde aber nie benutzt und ist jetzt raus geflogen.

Mein erstes Projekt damit wird sein, die Zeiterfassung für Kunden-Projekte neu zu schreiben und für alle brauchbar zu machen. Das wird wohl am Ende nur 1-2 Tage dauern. Also nichts im Vergleich zum Umbau des Frameworks.

404 Fehler bei erster Methode in Symfony

Wer auch das Problem hat, dass nur / also Routing bei einer der indexAction-Methode funktioniert und jede Änderung oder weiter Methode führt zu einem 404 Fehler, dem kann Helfen in der AppKernel.php das appBundle noch mal auf true zu setzen.

Das wird hier gut erklärt http://stackoverflow.com/questions/11932756

$kernel = new AppKernel('prod', true);

User	annonyme	Date	2019-08-06 19:10
Tags	hannes pries, logger, monolog, plugin, shopware, symfony

User	annonyme	Date	2019-07-02 19:32
Tags	components, DAL, dbal, hannes pries, orm, plugin, shopware, shopware 6, symfony, vuejs

User	annonyme	Date	2016-09-15 19:22
Tags	404, action, controller, hannes pries, php, route, symfony

Hannes Pries - Web/Shopware/JavaScript-Developer BlogWeil es immer eine simple Lösung gibt!

Hannes Pries - Web/Shopware/JavaScript-Developer Blog
Weil es immer eine simple Lösung gibt!