Mein 2. Shopware Plugin (also.. das 2. das in den Community-Store soll..) ist jetzt so gut wie fertig. Es fehlen nur noch ein paar Test und Dokumentation.
Das Plugin stellt einen Export der Orders bereit. Im Gegensatz zu den eingebauten Export hat man hier ein paar mehr Möglichkeiten das Aufgabeformat (so lange es XML ist) anzupassen und alles zu automatisieren.
Features:
- XML Formate: nativ, openTRANS 1.0 (eher experimentell), openTRANS 2.1
- automatischer Export direkt nach der Bestellung als Datei in ein lokales Verzeichnis
- automatischer Export als XML in einem JSON Container per Push (getestet mit einem Wildfly 11 und einem RestEasy Endpoint)
- Export bestimmter Orders in ein Verzeichnis per CLI
- Abfrage über die REST-API
- REST-API: Als XML in einem JSON-Container (Liste und einzelnd)
- REST-API: Als XML (einzelnd)
- XSLT-TRansformation, damit ist man im Ausgabeformat nicht eingeschränkt (egal ob mit Automatisch, CLI oder REST-API)
- Für die openTRANS-Formate gibt es verschiedene Einstellung für Buyer-Definition und die Party-Ids
Es ist also ein Plugin was rein auf die Integration von Shopware in vorhandene Bestell-Prozesse mit ERP-Systemen wie SAP ausgelegt ist. Arbeit wirklich gut mit Java Application Servern wie Wirldfly zusammen und auch zum Debuggen ist es sehr praktisch die Bestellungen als XML zu dumpen.
Ein relativ alter Fork des Plugin wird bei https://www.notebookswieneu.de genutzt, um die Bestellungen als openTRANS 1.0 an das SAP-System
zu übermitteln.
Diese Woche werden die letzten Dinge erledigt und dann wird es hoffentlich Anfang nächster Woche für den Store eingereicht.
if(dateFuture.isAfter(now)){
days = Duration.between(now.toLocalDate().atStartOfDay(), dateFuture.toLocalDate().atStartOfDay()).toDays();
}
An sich ganz einfach und hat alles was man sich sonst selbst gebaut hat. Gerade in PHP erinnere ich mich noch sehr daran startOfDay implementiert zu haben.
Mit dieser build.xml kann man eine Zip-Datei bauen, die von Shopware für Plugins akzeptiert wird. Wenn man Phing und nicht Ant verwendet, muss man ${basedir} durch ${project.basedir} ersetzen.
Falls man mal wie in der REST-API ein Bild per URL importieren möchte. Das kann der Fall sein, wenn man sich einen eigenen Importer für ein Format wie BMECat oder so geschrieben hat.
/** @var $media Media */
$media = $this->getMediaResource()->internalCreateMediaByFileLink(
$imageData['imgUrl']
);
$image->setMain(1); //1 is primary image, 2 is the rest
$image->setMedia($media);
$image->setArticle($article);
$image->setPath($media->getName());
$image->setExtension($media->getExtension());
$image->setDescription($media->getDescription());
Ich hatte es schon fertig und dachte ich könnte es später auch mal im Community Store anbieten.. aber dann kam mir schon jemand zu vor und dann auch noch kosten los.
Also hier einfach mein Plugin als Code für jeden:
<?php
namespace HPrExportAttrExtend;
use Doctrine\DBAL\Connection;
use Shopware\Components\Plugin;
Um unseren Shopware-Server aufzusetzen brauchen wir
- Apache (mit php7.0-mod)
- PHP7 (common,mysql,gd,xml,json,xsl,intl,gettext,mbstring,zip)
- MySQL Server
- OpenSSH Server
- PHPMyAdmin (wichtig hier Apache2 auszuwählen.. also mit Sternchen sichtbar nicht nur makiert)
Dann folgt die conf für den Apache und der Eintrag in die Host-Datei.
Jetzt können wir Shopware downloaden und installieren
Nun folgt die Netzwerk Konfiguration mit VirtualBox und die Anpassungen der hosts-Datei unter Windows.
Am Ende können wir mit dem Browser auf Shopware und mit WinSCP auf das System und das Shopware-Verzeichnis zugreifen.
So können wir unser lokalen Plugin-Verzeichnis mit dem auf dem Server synchron halten und Änderungen werden automatisch auf den Server gepusht.
Toll fand ich, dass man während des Freigabeprozesses wirklich mit Menschen zu tun hatte und einem auch wirklich von sich aus geholfen wurde.
Meine Erfahrungen beim Mozilla Store für Firefox OS waren da ganz anders. Da erhielt man eine Email mit sehr allgemeinen Punkten gegen was man verstoßen hätte und Hilfe was man noch müssen für die Freigabe gab es so gar nicht.
Deswegen werde ich mich dann jetzt daran machen weitere Plugins zu schreiben und zu veröffentlichen.
Erstmal Shopware mit Vagrant auf meiner Windows Workstation zum Laufen bekommen. Dann geht es sicher alles noch schneller und einfacher.
Oder ich richtige mir doch eine eigene Ubuntu VM ein... mal gucken.
Auch wenn die erste Version noch nicht wirklich weiter ist, was die Freigabe betrifft, habe ich hier schon mal die ersten Test mit der 2.0 Version.
Wenn man einen öffentlich erreichbaren Shop hat, den jeder ohne Umwege von zu hause aus erreichen kann, aber sich nur bestimmte Kunden, wie eigene Mitarbeiter oder Mitarbeiter von Partner Firmen, registrieren dürfen, kann man nun Black- und Whitelists verwenden.
Darin kann man Email-Adressen oder Domains (z.B. "*@hannespries.de") angeben und invalide Email-Adressen, werden erst gar nicht zum Anmelden zugelassen und der Kunde mit einer Nachricht darüber informiert, dass seine Email-Adresse nicht den Anforderungen entspricht.
Wer also einen Mitarbeitershop hat, kann nun nur Anmeldungen mit der Firmen-Email-Adresse zulassen und muss keine Konten per Hand oder auf Verdacht per Job anlegen lassen.
.. hoffentlich :-) Hat jetzt doch ein paar Monate länger gedauert, bis alles so weit war. Die nächste Version mit White- und Blacklists, die bestimmen, mit welchen Email-Adressen und Domains sich Kunden registrieren dürfen, ist auch schon halb fertig.
Ich hoffe mal, dass das Plugin ohne größere Probleme in einiger Zeit dann in den Store gehen kann und ich dann ein paar andere Ideen für Plugins umsetzen kann.
Wäre auf jeden Fall toll damit etwas Geld verdienen zu können, da mir Shopware-Plugins sehr viel mehr zusagen als Apps zu Entwickeln oder zu versuchen mit Werbung meine Projekte wenigstens ohne Zuzahlung betreiben zu können.
Es fällt schnell auf, dass wenn man das Array mit den Bildern im Article-Model der REST-API ersetzt, die neuen Bilder nicht die alten ersetzen, sondern nur hinzugefügt werden. Das funktioniert auch super bei den selben Bildern, so das in einigen Fällen (wenn man nicht weiß, ob es neue Bilder sind oder nicht) sich doppelte Bilder im Artikel häufen.
Zum Glück bietet die REST-API den Merge Mode an. Dieser gilt für Bilder und Kategorien.
Man muss nur ein neues Feld in den Artikel einbauen:
Default ist hier false. True als Defaultwert hätte ich persönlich logischer gefunden, bzw. eine Einstellung dafür in den Grundeinstellungen, um den Default-Wert zu ändern.
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));
$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.
Am Ende dachte ich mir nur: "ist an sich ja genau so wie in meinem Framework.."
Ok. Alle Sprachen in einer Datei und nicht wie bei den Properties-Dateien in Java, aber ansonsten. Im Grunde hat man eine ini-Datei die eingelesen wird. Sie hat einen Namespace, was es sehr viel einfacher macht auf Text-Snippets anderer Plugins oder des Core-Systems zuzugreifen.
Das Arbeiten mit der Time-API von Java ist teilweise echt nicht einfach. Auch gibt es vielmehr zu schreiben und ohne Hilfe aus dem Internet geht es einfach nicht. Wobei ich die ".from()"-Methoden schon wirklich nett finde.
Wenn man die letzten 2-3 Jahre fast nur PHP gemacht hat, erschlägt einen es fast schon, von der Fülle an Kombinationen und Klassen die man hier benötigt. Jeden Falls auf den ersten Blick. Auf den zweiten sieht es besser aus und auf den dritten gefällt es einen dann auch schon wirklich.
Und im Gegensatz zum guten alten Date mit SimpleDateFormat funktioniert es auch ohne Probleme.
Java tut auch hier was es am Besten kann: Es zwingt einen es richtig zu machen.. mit ZoneId und allem was man sonst der Bequemlichkeit halber oft lieber weg lässt.