Diese Meldung muss nicht wirklich was großes bedeuten, denn es kann sein, dass beim Go-Live einfach erst HTTPS aktiviert wurde und vorher nur HTTP da war.
Die APP_URL ist einmal in der .env zu finden und dann nochmal in der Datenbank in der Table system_config mit dem key core.app.shopId. Dort liegt ein JSON-Object, das auch nochmal die APP_URL enthalten kann.
Diesen Wert zu ändern hat geholfen. Wenn man komplett die Domain wechselt und noch eine Stage-Domain für den Shop bei Shopware einträgt, ist es natürlich etwas anderes.. aber für HTTP/HTTPS Probleme sollte es so ausreichen.
Ich arbeite nun doch schon einige Zeit mit Shopware 6. Während ich am Anfang vielen Konzepten etwas kritisch gegenüberstand, bin ich nun doch sehr von fast allen Dingen überzeugt. Ich habe viele verschiedene Dinge schon mit Shopware 6 realisiert und einiges wäre in Shopware 5 nicht so einfach gewesen.
Gerade Vue.js in der Administration ohne irgendwelche zusätzlichen Lizenzen nutzen zu können ist super. Ich mochte immer Vue + Bootstrap und Symfony. Also am Ende fühle ich mich so was von extrem in meinen Vorlieben bestätigt... wenn auch Shopware diese Kombinationen nutzt muss ich ja schon immer richtig gelegen haben :-)
Varianten sind immer noch viel zu kompliziert. Daten in das Model für Emails rein zubekommen ist wirklich viel zu umständlich. N:M Relation in DAL ist umständlich bzw wie früher mit puren SQL. Entweder alles vorher löschen oder sich merken was genutzt wird und alles was nicht dazugehört löschen. Aber am Ende kommt man ja gut damit klar... ist eben wie mit JDBC oder PDO direkt zu arbeiten und dass habe ich lange genug gemacht.
So.. aber was kann man alles mit Shopware 6 so alles bauen? Ich habe bis jetzt nur für Kunden direkt entwickelt und falls jemand etwas hier von gerne hätte, geht das leider nur über Anfrage und dann wird ein Angebot erstellt.
1. Adressänderungen verhindern Wie schon bei Shopware 5 war es nötig, weil SAP sonst überfordert ist.
2. Register-Form erweitern Das zu Erweitern war am Ende sehr viel einfacher als gedacht und ich nutzt einfach das Data-Mapping Event für den Customer. Der richtige Weg? Für mich funktioniert er gut.
3. Blog Einträge Das kostenlose Blog-Plugin ist schon echt super. Es fehlt nur ein Flag um Posts von er Suche auszuschließen, Typen, Rechte über Rules und Datei-Anhänge. Ja.. ich weiß.. ich könnte mich da beteiligen und alles einbauen.. sollte ich wirklich machen. Aber bis jetzt war nur Zeit das Plugin zu erweitern um Rezepte aus einem Panipro-System zu importieren.
Typen sind natürlich dynamisch und es werden nur Typen auf der linken Seite angezeigt, die auch gefunden wurden.
4. Bonuspunkte und passende Produkte Produkte die man nur oder auch gegen Bonuspunkte kaufen kann. Das war etwas komplexer und man musste über Collector und Processor des Carts eingreifen. Heute würde ich wohl einiges ein wenig anders machen, aber nicht viel und auch nur minimale Änderungen.
5. Konfigurator Style #1 So kann man sich z.B. Geschenkkörbe oder PCs/Notebooks konfigurieren. In der Administration kann man sich ein Config-Preset anlegen und es verschiedenen Products zuordnen.
6. Konfigurator Style #2 Ein Produkt das z.B. Hackfleisch beinhaltet so konfigurieren in welchen Formen man das Hack gerne geliefert bekommen würde. Wurde als Teil von Punkt 7 entwickelt.
7. Paket verkauf Erst alle Pakete verkaufen und dann erst das Tier schlachten. Spart Lagerkosten und andere Aufwände. Hier habe ich gelernt warum Varianten noch immer umständlich sind und CustomFields zu syncen zwischen Varianten schlechter ist als eine eigene Entity dafür zu erstellen. Aber die Anforderungen waren zuerst so das CustomFields die einfacher Lösung waren.
Ich musste mir eine sw2-Datenbank anlegen über root/root, aber an sich sollte es wie in meinem SW5-Environment auf mit der sw-Datenbank und sw/sw gehen.
Aus Shopware kennt man das Prinzip, dass man beim Erweitern von Templates einfach "parent:" angeben muss und es wird immer das vorher gehende Template mit dem selben Pfad erweitert. So kann man ein Template mehrmals durch eine unbekannte Anzahl von Plugins erweitern lassen. Twig will aber immer einen Namespace haben. Also muss man heraus finden, mit welchen Plugin man anfängt und welches Plugin dann auf das aktuelle folgt oder man auf das Basis-Template gehen muss. Ich hab mich von der Shopware 6 Implementierung inspirieren lassen und ein kleines Beispiel gebaut, bei dem man die ein Template erweitern kann und die Plugin-Namespaces immer dynamisch ergänzt werden.
Die Verzeichnisstruktur des Beispiels ist sehr einfach:
Die Basislogik habe ich in einer einfachen Function zusammen gefasst. Hier wird entweder das Plugin heraus gesucht mit dem angefangen werden muss oder das Plugin, das auf das aktuelle folgt und auch dieses Template mitbringt.
function findNewBase($template, $list = [], $currentBase = null) {
$result = 'base';
$found = $currentBase == null; //if null, took the first one
foreach($list as $key => $path) {
if($key == $currentBase) {
$found = true;
}
else if ($found && file_exists($path . '/' . $template)) {
$result = $key;
break;
}
}
return $result;
}
Die Integration wird über ein Token-Parser implementiert.
final class ExtTokenParser extends AbstractTokenParser {
/**
* @var Parser
*/
protected $parser;
private $list = [];
public function __construct(array $list)
{
$this->list = $list;
}
public function getTag(): string
{
return 'base_extends';
}
/**
* @return Node
*/
public function parse(Token $token)
{
$stream = $this->parser->getStream();
$source = $stream->getSourceContext()->getName();
$template = $stream->next()->getValue();
$stream->injectTokens([
new Token(Token::BLOCK_START_TYPE, '', 2),
new Token(Token::NAME_TYPE, 'extends', 2),
new Token(Token::STRING_TYPE, $parent, 2),
new Token(Token::BLOCK_END_TYPE, '', 2),
]);
Jetzt fehlt nur noch eine passende include-Funktion und man kann sich selbst ein System bauen, desen Templates sich über Plugins ohne Probleme erweitern lassen. Ich arbeite daran....
Edit: Die vollständige Implementierung mit extends und include ist jetzt auf GitHub zu finden.
Der einfachste Weg einen Shopware Shop zuinstallieren war immer, die ZIP-Datei mit dem Webinstaller downzuloaden und diese in das gewünschte Verzeichnis zu entpacken. Dann die URL aufrufen und dem Installer folgen. Das ist für automatische Deployments nicht so toll und oft wurde dort einfach die Git-Version verwendet. Die hat den extremen Nachteil, dass diese unglaublich viele Dinge mitbringt, die in einer produktiven Umgebung nichts zu suchen haben. Buildscripte, Tests, etc bringen einen wirklich nur in der Dev-Umgebung was und sollten in der produktiven Umgebung nicht mit rumliegen, weil je mehr rumliegt, desto mehr Sicherheitslücken oder ungewollte Probleme könnten mitkommen.
Seit einiger Zeit kann man Shopware aber auch sehr einfach über den Composer installieren. Dabei wird eine eher moderne Verzeichnisstruktur angelegt und auch die Basis-Konfiguration kann einfach über Env-Variablen gesetzt werden, so dass ein automatisches Deployment für einen Server damit sehr einfach wird. Im Idealfall hat man die Datenbank schon sauber und fertig vorliegen. Dann erspart man sich fast den gesamten Installationsprozess und kann direkt loslegen.
Wenn man den Composer noch nicht installiert hat, muss man diesen kurz installieren:
<Directory /var/www/your_webshop>
AllowOverride All
Require all granted
</Directory>
RewriteEngine On
</Virtualhost>
Reload des Apache und schon kann es an sich losgehen. Wenn man sehen möchte wie die DATABASE_URL verarbeitet wird, kann man einen Blick in die etwas komplexer gewordene config.php werfen die man nun unter your_webshop/app/config/config.php findet.
Sollte man noch keine fertige Datenbank auf dem Server liegen haben, muss man die ./app/bin/install.sh ausführen. Gerade für mehrere automatische Deployments, würde ich aber die Datenbank einmal local auf meiner Workstation anlegen und mit Default-Werten befüllen. Diese kommt dann auf den Datebankserver und wird beim deployment, mit den spezifischen Daten wie den Shopdaten und Admin-Zugängen versehen.
Natürlich würden Updates auch über den Composer laufen, wobei sw:migration:migrate automatisch mit aufgerufen wird, um die Datenbank mit aktuell zu halten. Das Verhalten kann man über die Deaktivierung des entsprechenden Hooks in der composer.json verhindern (aber das macht an sich nur in Cluster-Umgebungen Sinn). Ein Update über das Webinstaller-Plugin würde Probleme bereiten und sollte, wenn man es dann ,z.B. weil man eine alte Installation umgezogen hat, installiert und aktiv hat mit ./bin/console sw:plugin:uninstall SwagUpdate entfernen.
Der wirkliche Vorteil liegt jetzt darin, dass man in die composer.json seine Git-Repositories von den Plugins mit eintragen kann und die Plugins direkt über den Composer installieren und updaten kann. Man muss also nicht diese erst vom Server downloaden + entpacken oder per Git clonen (wo dann wieder viel Overhead mit rüber kommen würde).
Wenn man sich für Shopware ein Plugin kauft, kann es sein, dass man die Daten genau so vorfindet, wie man sie braucht, aber möchte das dort verwendete Template ersetzen oder die Daten in einem Template verwenden, das im Plugin noch gar nicht vorgesehen war.
Dafür kann man sich ein eigenes kleines Plugin schreiben. Das geht in 5 Minuten. Wir schreiben uns das Plugin TESTNotLoggedIn und blenden damit den Newsletter in der Footer Navigation aus.
Ins Verzeichnis TESTNotLoggedIn kommt die Datei TESTNotLoggedIn.php:
namespace TESTNotLoggedIn;
use Shopware\Components\Plugin;
class TESTNotLoggedIn extends Plugin{
public static function getSubscribedEvents()
{
return [
'Enlight_Controller_Action_PostDispatchSecure_Frontend' => 'addTemplateDir',
'Enlight_Controller_Action_PostDispatchSecure_Widgets' => 'addTemplateDir',
];
}
public function addTemplateDir(\Enlight_Controller_ActionEventArgs $args)
{
try {
$args->getSubject()->View()->addTemplateDir($this->getPath() . '/Resources/views/');
}
catch(\Exception $e){
//TODO
}
}
}
jetzt kommt das Verzeichnis Resources/views/ dazu und die Datei plugin.xml:
<?xml version="1.0" encoding="utf-8"?>
<plugin xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="https://raw.githubusercontent.com/shopware/shopware/5.2/engine/Shopware/Components/Plugin/schema/plugin.xsd">
<label lang="de">TEST Not Logged In</label>
<label lang="en">TEST Not Logged In</label>
Hier wird das Plugin, das wir erweitern wollen, angegeben. Ich verwendet das kostenlose "Globale Kunden Smarty-Variablen". Nun können wir einfach unsere Templates im views-Verzeichnis anlegen und vorhandene erweitern.
Als Beispiel kommt hier Resources/views/frontend/index/footer-navigation.tpl
Damit ist das Plugin schon fertig und kann installiert werden. Der Newsletter Bereich im Footer ist nun nur sichtbar, wenn man eingelogged ist.
Das Plugin "Eigenschaften in Artikel-Listing" bietet z.B. auch an in der Detailseite die Daten nur als Smarty-Variable bereit zu stellen, damit man selbst direkt die Darstellung implementieren kann und nicht noch eine vorhandene unpassende anpassen oder entfernen und ersetzen muss.
Ich habe jetzt fast genau ein Jahr Shopware-Plugins programmiert und im Community-Store von Shopware angeboten. Es hat mir immer viel Spass gemacht und gerade der Kontakt mit den Kunden war oft sehr interessant. Da es aber über mein Nebengewerbe lief, war die Zeit, die ich dafür verwenden konnte schon sehr eingeschränkt und auch Marketing war nicht so einfach da mit unter zu bringen. Zusätzlich benötigte das eigene Haus immer mehr Zeit. Es ist schon ein riesiger Unterschied, ob man eine Mietwohnung hat oder ein eigenes Haus, was den Zeitbedarf angeht.
Daher hatte ich mich entschiedenen meine Nebentätigkeiten herunter zu fahren. In dem Zuge kam ich an den Punkt, wo mir klar wurde, dass weniger nichts bringt, sondern ich ganz aufhören muss.
Die laufenden Projekt wollte ich aber nicht so einfach wegwerfen, besonders weil ja auch Kunden darauf vertrauen, dass deren Plugins und andere Software weitergepflegt wird und Fixes erstellt werden.
Deswegen wechseln meine Plugins nun zur Windeit Software GmbH, was mir die Möglichkeit gibt, den Plugins auch die Zeit und Investionen zukommen zu lassen, die sie benötigen. Es ist also nur zum Vorteil aller, denn jetzt wird es geben:
- verbesserten Support
- besseres Marketing
- richtige Dokumentation (Videos?)
- Urlaubsvertretung
- alles noch professioneller
In der nächsten Zeit werden also alle Plugins umgestellt. Kunden werden einen neuen Namen und ein neues Logo sehen, aber der Rest bleibt gleich und alle Kaufe und Subscribtions laufenden unverändert weiter.
Und was werde ich jetzt machen? Haus, Garten und im Blog wird es wieder vermehrt um Development, Arbeit, Hardware-Projekte und kleine private Projekte gehen. Weniger Content, aber dafür etwas persönlicher wieder mit mehr Inhalt.
Wenn man ein eigenes Haus hat, hat man auch genug mit IT und Infrastruktur Themen zu tun.
Momentan ändert sich bei mir Nebengewerblich einiges und ich überlege wie ich meine Shopware Projekte weiter pflegen kann und vielleicht sogar richtig mit Marketing pushen könnte. Das Problem dabei ist, dass ich gerne kleine Dinge für meine Kunden tue ohne direkt Geld zu verlagen. Damit aber sich eine Zukunft ergibt, müssen, die etwas mehr Geld generieren. Dabei wäre wohl der erste Schritt für die Erstellung von XSLT-Templates Geld zu verlangen. Bei JTL oder anderen Anbietern, dachte ich mir bis jetzt, dass es ja von Vorteil wäre einfach die zu bauen und dann ins Plugin zu integrieren. Damit wäre das Plugin von sich aus irgendwann mehr Wert und es wäre vertrettbar den Preis zu erhöhen.
Ich werde wohl bis Dezember dann das Schreiben von neuen XSLT-Templates kostenpflichtig machen. Pro Template brauche ich so 1-2h, wenn ich dann normale Zeiten wie bei meinem Job hätte wohl eher 1h. Das sind Preise dann die niemanden Weh-tun würden.
Das XML-Plugin bekommt noch einmal ein großes Update oder es wird sogar ein 2. Plugin mit dann aber einem entsprechenden Preis (momentan mein favorisiertes Vorgehen). Das kleine wäre dann für die Anbindung an WWS und ERPs und große wäre dann für echtes Dropshipping.
Wenn ich es schaffe, die auch weiterhin weiter entwickeln zu können, wäre dann auch hoffentlich die Zeit für Dokumentation und Tutorial-Videos.
Ich bin selbst sehr gespannt wie alles weiter geht und wie einige meiner Projekte in Zukunft aussehen werden.
Nach längerer Zeit habe ich auch mal wieder etwas Arbeit in mein B2B Registrierung-Blockieren Plugin gesteckt. Nun ist das Styling und das Layout nicht mehr ganz so hässlich. Man kann etwas mehr einstellen (nur die Form aus einer Liste auswählen macht im Backend echt viel Ärger.. ich habe es nach hinten verschoben).
Update auf Version 2.5 erfolgt in den nächsten Tagen.
Das Plugin bekommt eine Einstellung, dass Preise erst nach einem Login (oder mit Cookie) angezeigt werden. Ein Event und abstrakter Subscriber für Kundenabhängige Preismanipulationen ist in Arbeit.
Eigenschaften im Listing:
Eine Darstellung (auch nur als Smarty-Variable) im Artikel-Detail kommt hin zu und eine einfacher Tabellen-Darstellung werde ich auch noch einbauen (nur Grid-Linien oder so).
X Kunden haben gekauft:
Das Plugin zeigt an wie viele Kunden einen Artikel in einer bestimmten Zeitspanne gekauft haben und markiert diese im Listing als "HOT-Deal". Plugin ist fertig und ich muss nur noch Screenshots und so anfertigen.
Rabatt für Newsletter-Abonnenten:
Da arbeite ich momentan dran und ein Konzept und ein halber Prototyp existieren schon. Da Shopware nur einen Gutscheon pro Bestellung zulässt wird es über Discounts geregelt und nicht einfach automatisiert versuch einen Voucher-Code einzubringen.
Ich war bei Shopware von meinem eigenen Verhalten ausgegangen. Updates waren schnell und machten bis auf einen RC nie Probleme. Die produktiven verhielten sich immer genau so.
Da ich jetzt immer auf der aktuellsten Version entwickelte und dann für den Versions-Branch sagen konnte, ob es Probleme geben könnte oder nicht, habe ich auch den Support einer Plugins irgendwann daran orientiert und z.B. den 5.2er Branch nicht mehr unterstützt. Ich war mir sicher, dass das Meiste da laufen würde, aber ich hatte keine Test-Umgebung für 5.2.x und ging davon aus, dass nach einem halben Jahr wohl die meisten auf die aktuellste Version geupdatet hätten.
Falsch! Es wird noch z.B. 5.2.21 verwendet und braucht neue Plugins. Interessant wäre hier mal, welche Versionen von Shopware wie weit noch verbreitet sind, damit man abschätzen kann, ob es sich lohnt noch dafür zu entwickeln.
Nun habe ich in meiner Shopware VM folgende Versionen installiert, um ausreichend Testen zu können:
- 5.2.21
- 5.2.27
- 5.3.7
- 5.4.2
Damit sollten sich alle wichtigen Versionen abdecken lassen und wenn jemand mit einer anderen Version Probleme hat, kann man das immer noch innerhalb von 15min installieren und dann mit der konkreten Version testen.
Ich habe also jetzt angefangen, meine Plugins nochmal mit alten Versionen zu testen und auch dann dafür freizugeben.
Und wenn man sich Shop mit Oxid 4.3, XTC 3.x oder manche noch anderen Lösungen anguckt, wäre selbst die erste 5.2er Version als Alt zu bezeichnen nicht ganz richtig. Die Shopware-Welt ist exxtrem schnelllebig.
Quelloffene Plugins sind toll. IonCube ist doof, umständlich und schwer einzurichten. Wenn es die Möglichkeit gibt würde ich ein quelloffenes Plugin immer vorziehen.
Dieser Artikel von Shopware fasst alles sehr gut zusammen.
Viele Fragen zu einem Shopware-Plugin können einfacher und schneller durch einen Blick in den Code beantwortet werden:
- Wo holt es sich die Daten her?
- Wo schreibt es die Daten hin?
- Welche Daten müssen vorhanden sein, damit alles verarbeitet werden kann?
- Wann wird welche Funktion aus geführt?
Und gerade die Angst, der Code könnte geklaut werden halte ich in 99,99999% für eine verzerrte Sicht der Dinge. Denn man muss einfach davon ausgehen, dass die Plugins aus genau zwei Gründen gekauft werden:
- Der Betreiber des Shops kann nicht Programmieren und hat auch keine Entwickler
- Das Plugin selbst zu entwickeln wäre teurer als es zu kaufen
Ich selbst habe ein paar Plugins im Store die auch wirklich wenigen Zeilen Code bestehen. Manche manipulieren genau einen Wert im Request. Es hat etwas gedauert bis man musste welcher Wert manipuliert werden muss (das weiß man, weil man ja den Quellcode von Shopware einsehen kann). Umsetzen, Testen, verbessern, etc. Aber keine großen oder komplexen Leistungen.
Warum habe ich diese quelloffen im Store? Weil ich glaube, dass ein Entwickler (wenn er gerade keinen Forschungsdrang hat) eher mal paar Euro ausgibt als selbst es nach zubauen und alles selbst nochmal testen und überprüfen zu müssen.
Lösungen zu verheimlichen ist nie gut. Weil man selbst braucht ja auch oft mal Hilfe oder Denkanstöße. Mit genug Zeit kommt jeder auf die Lösung, aber man hat immer genug zu tun, um dankbar dafür zu sein, dass jemand anderes sich diese Zeit genommen hat und man sich mit deren Dingen beschäftigen kann.
Mir gefällt der neue Shopware-Newsletter nicht. OK er ist übersichtlicher, aber mir gefällt es nicht, dass die neuen und aktualisierten Updates nicht mehr direkt als Liste enthalten sind sondern nur noch Banner-Links auf deren Store, wo man diese Plugins findet.
Mir gefiel es immer meinen Namen dort zu lesen. Hat den Freitag oft verschönert :-)
Nächstes Jahr werde ich wirklich mal das Adventskalender-Projekt nach vorne bringen. Mit Shopware Emotion-Element und so. Erstmal stehen jetzt für Ende diesen und Anfang nächsten Jahres folgende Dinge auf meiner Todo-Liste:
- Shopware-Plugin: Warnung bei unnatürlichen Preisänderungen
- Shopware-Plugin: Globale Smarty-Variablen für Kundendaten
- Shopware-Plugin: XML-Order Export für ERP-Integration
Dann kommt noch die Planung/Konzeptionierung für ein Projekt mit RFID Technik in Kombination mit vielleicht Shopware.
Und auch SMS2X soll noch mal verbessert werden, so dass es vielleicht mal zum Einsatz kommen kann.
Auch Zeitmessung ab von RFID wird mich wohl noch mal beschäftigen.
Ich habe mich jetzt die letzten 2-3 Monate doch relativ ausführlich mit Shopware beschäftigt. Das erste Projekt das live ging war das Creditfair Fair-Vereinsprogramm. Dafür mussten 2 Plugins geschrieben und einige Theme-Anpassungen vorgenommen werden.
Die Plugin-API mit den Events ist wirklich einfach zu erlernen. Einzig die Suche nach dem passenden Event kann immer etwas länger dauern, wobei am Ende weniger die Frage ist, ob es das richtige Event ist, sondern ob es das beste Event ist. Events für jeden Fall gibt es mehr als genug, wobei die Unterschiede wirklich oft in Feinheiten zu suchen sind.
Nebenbei habe ich als Test ein kleines Plugin geschrieben, das das Kunden-Objekt (wenn denn ein Kunde eingeloggt) ist auch beim Versenden von Forms im Template verfügbar macht. Forms verwenden eine eigene kleine und sehr einfache Template Engine. Für die Erweiterung um den Kunden kommt aber dann Smarty3 zum Einsatz. Damit kann man bei Anfragen über Forms, die nur angemeldeten Kunden zur Verfügung stehen, die Kundendaten direkt zur Email hinzufügen, ohne dass der Kunde es selber tun muss.
Insgesamt macht es viel Spass mit Shopware zu entwickeln.. nur.. nur eine Sache gibt.. die bereitet mir noch Kopfzerbrechen.
STAGING
Mit der 5.3 kann man wenigstens Einkaufwelten exportieren und wieder importieren. Das ist schon mal wirklich eine große Hilfe, da so Designer auf dem lokalen System arbeiten und testen können und man erst dann nach der Freigabe die Einkaufwelten auf das produktive System verschieben kann.
Themes kann auch relativ einfach kopieren. Plugins aus dem Community-Store sollte man so oder so nicht durch ein Staging laufen lassen, sondern auf dem produktiven Server neu installieren und konfigurieren.
Content-Seiten sind der Punkt, wo ich noch am Überlegen bin wie man damit umgehen soll. Hier fehlt eine vergleichbare Import/Export Funktion wie bei den Einkaufwelten.
Ein anderes Thema betrifft Shopware aber auch fast alle anderen Shop-Systeme. Das Problem beginnt damit Produkte, Hersteller, etc in das Shop-System zu bekommen. Denn wenn man keinen winzigen Shop mit 10-50 Artikeln hat, wird man sicher die Produkte aus einem Waren-Wirtschafts-System beziehen wollen. Die REST-API von Shopware ist toll und man kommt schnell zu Ergebnissen. Der CSV-Import ist auch nicht schlecht. Aber das Problem ist, dass man dann immer eine Lösung für Shopware baut. Bei anderen Shops eben für das jeweilige System.
Es gibt wohl kaum Shop-Systeme (oder ich konnte sie nicht finden), die Standard-Formate als Core-Feature lesen oder schreiben können.
Bei der Arbeit dürfte ich nun mit CSV, XML und IDocs aus SAP kämpfen. IDocs sind für den Datenaustausch wirklich nicht toll. Jedenfalls nicht, wenn man die SAP-Welt verlässt. In dem Artikel Warum Sie beim Datenaustausch im E-Commerce auf Standardformate setzen sollten von Daniel Peters trifft es sehr gut gut. Ich stimme da zu 100% zu und er trifft wirklich den Punkt, den ich schon seit Jahren nicht verstehe. Wenn ich ein neues System entwickle, dass mit anderen Systemen kommunizieren und Daten austauschen muss. Warum baue ich mir dann immer wieder ein eigenes Format und nehme mir nicht von Anfang an ein Standard-Format. Damit habe ich auch schon mal eine Art Blaupause, wie man mit dieser Art von Daten umgehen kann und sollte mal ein System ausgewechselt werden, muss ich hoffentlich nicht wieder ein neues proprietäres Format in eine Schnittstelle für mein System umwandeln.
Ich hatte mir ein kleines Plugin geschrieben, dass Bestellungen direkt nach dem Speichern als JSON auf dem Server abgelegt hat. Es war zuerst zur Kontrolle und zum Debuggen auf dem Live-Server da. Es hat nicht lange gedauert und ich hatte auch einen XML-Export und 2 Stunden später auch einen rudimentären [url=]OpenTrans[/url] 1.0 export. Auch wenn der Standard sicher noch nicht zu 100% korrekt umgesetzt ist, habe ich doch schon mal ein Export-Format für Bestellungen, das alles enthält was man braucht, strukturiert ist und auch einfach wieder gelesen werden kann.
Ich werde auf jeden Fall an dem Plugin noch mal weiter rumbauen und vielleicht nochmal OpenTrans 2.1 implementieren.
Ich glaube auch das man einfacher eine OpenTrans zu IDoc Lösung findet, ohne selbst was machen zu müssen, als eine Shopware-internes-Format zu IDoc.
Auch der Import der Produkte... warum kann ich nicht einfach OCI oder BMEcat verwenden, um meinen Shop mit Daten zu befüllen. WWS und andere ERP-Systeme können ja diese Format ausgeben. Die Formate, gerade OCI, sind ja auch sehr verbreitet. Warum kann der Shop diese also nicht nativ lesen und benötigt Zusatzsoftware oder Plugins?
Auf der Roadmap von Shopware-Enterprise steht bei B2B jetzt OCI in der "Unsere Visionen für die Zukunft". Richtiges Punchout muss ja nicht mal sein.
Aber die OCI-XML Daten importieren zu können wäre schon einfach toll und würde an vielen Stellen sehr viel Arbeit und Geld sparen.
Das wohl gerade an einem Import für Kunden aus Drittsystemen gearbeitet wird kommt wohl für mich auch zu spät, aber ist schon mal eine tolle Sache.
Momentan überlege ich einen kleines Plugin zu schreiben, dass BMEcat versteht. Nichts all umfassendes mit User-Data-Extensions und so. Ein einfaches kleines, dass nur dafür sorgt, dass Systeme die BMEcat ausgeben können, grundlegend den Shop mit Produkten befüllen können. Wenn ich dann mal wieder Daten aus einem System in Shopware importieren soll, würde ich einfach die Daten auf BMEcat umbiegen können (mit einer Middleware oder XSLT oder so) und müsste an Shopware nichts mehr ändern. Shopware hätte dann eine stabile Schnittstelle, die nicht nur für mich sondern allgemein genutzt werden kann und sogar ein sehr gut dokumentiertes Format nutzt.
Sich der Welt mit Standard-Formaten als Core-Feature zu öffnen, würde vielen Shop sehr gut tun. ... aber wohl auch einen Markt der sich nur auf das verschieben von Daten zwischen Systemen spezialisiert hat, empfindlich treffen können. Für den normalen Entwickler und seinen Shop wäre es aber wirklich ein großer Vorteil.
Blog-entries by search-pattern/Tags:
Möchtest Du AdSense-Werbung erlauben und mir damit helfen die laufenden Kosten des Blogs tragen zu können?