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.
Nach.. öhmm.. 1,2,3.. ganz vielen Jahren habe ich ein Foto bei Fotolia verkauft. Aber ich glaube ich belasse es dabei.. der Freigabe Prozess ist da genau so nervig wie damals bei Firefox OS.. da bleibe ich lieber bei Shopware-Plugins. Die nehmen einen da zur Not an die Hand bei der Freigabe und sind immer nett und helfen wirklich toll.
Ich nehme das jetzt mal als kleines Weihnachtswunder hin :-)
Manchmal möchte man nicht nur PHP-Code erweitern sondern auch den JavaScript-Code. Hier findet man eine wirklich gute und kurze Anleitung, wie man dabei vorgeht.
Sobald ein Plugin neue Models/Entities verwendet oder vorhandene erweitert, sollte das Plugin auch einen Controller für die REST-API mitbringen. Nichts ist nerviger als ein Plugin zu testen und nach 2 Minuten abzubrechen, weil das Plugin keine REST-API hat und man alles im Backend des Shops nachpflegen müsste, was man gerne beim Import der Daten aus dem PIM oder ERP schon gerne direkt mit erledigt hätte. Sets und Bundles sind da so ein Fall.
Was nützt es mir Sets und Bundles aus Artikeln im Backend zusammen bauen zu können wie sie im PIM definiert sind und zwar aus den Artikeln, die aus dem PIM Importiert werden? Wieso nicht direkt gleich mit importieren?
Integration sollte immer an erster Stelle stehen, denn oft diese Integration zu schaffen ist oft teuer und man verzichtet lieber auf ein oder zwei Features, wenn man dann nicht wieder selbst Import- und Exportlösungen zusammen stricken muss, die beim Update des Plugin vielleicht wieder hinfällig werden.
Das ist an sich sehr einfach, da man diese Funktion nicht erst in ExtJS einbinden muss, sondern direkt eine globale JavaScript-Variable ansprechen kann.
Ich bin bei diesen Artikel bei Heise mal wieder auf das Werben der Arbeitgeber mit Team-Events gestoßen. Dieser Kommentare zeigt aber auch, dass nicht nur ich diese Events auch skeptisch sehe.
Wahrscheinlich will die Masse der Arbeitnehmer einfach irgendwann nach Hause gehen um Zeit mit Freunden und Familie verbringen bzw. Hobbies nachgehen.
Wenn ich ein Job-Angebot mit "regelmäßigen Team-Events" sehe, bin ich eher geneigt, dieses Angebot erst gar nicht in Betracht zu ziehen. Nicht dass ich was gegen die anderen Team-Mitglieder hätte, werden schon nette Leute sein. Nur das Wort "regelmäßig" impliziert für mich, dass auch ein "regelmäßiges" Erscheinen vom Arbeitgeber erwünscht wird.
Wenn man Frau, Haus, Freunde, Familie, Privatleben, etc hat, ist es aber schon so schwer, alles in der Woche unterzubringen, was man erledigen muss. Einkaufen, Putzen, etc und am Ende soll man sich ja auch noch entspannen und für spontane Nachfragen oder Kontrollen von Änderungen von zu Hause soll man ja auch noch zur Verfügung stehen.
Wenn man Single ist und seine Wohnung nur als Ort sieht, den man zum Schlafen aufsucht und sonst seinen Lebensmittelpunkt bei der Arbeit sieht, mögen diese Events schön und toll sein. Für die meisten werden sie aber eher Zeit belegen, die man für andere Dinge gebraucht hätte.
Auf den jährlichen Weihnachtsmarktbesuch mit dem Team würde ich nicht verzichten wollen. So etwas im monatlichen Rhythmus würde ich auch ok finden, wobei ich aber eine Anwesenheitsrate von 50% schätzen würde, die ich realistisch einhalten könnte.
"Du kannst fast immer pünktlich gehen" wäre also für mich viel mehr ein Anreiz als Team-Events. Weil was bringt es mir pünktlich Feierabend zu machen und dann 4h bei einem Team-Event zu verbringen.
Das bei Webentwicklern PHP meistens hinter Java kommt ist bei dieser Statistik wieder eine andere Geschichte...
Die Differenz zwischen zwei Datumswerten in Tagen:
Java (LocalDateTime)
if(ldt1.isAfter(ldt2)){
days = Duration.between(ldt1.toLocalDate().atStartOfDay(), ldt2.toLocalDate().atStartOfDay()).toDays();
days = Math.abs(days);
}
Java (Date)
long days = TimeUnit.DAYS.convert(date.getTime() - date2.getTime(), TimeUnit.MILLISECONDS);
Unter den Performance-Einstellungen findet man die Einstellungen zu Filter. Leider beeinflussen diese Einstellungen nicht nur die Performance, sondern auch dass Verhalten des Filters.
Filterbutton anzeigen: Es wird erst einmal ein Button mit der Anzahl der Treffer angezeigt. Um diese zu sehen muss man auf den Button klicken. Es müssen also keine Ansichten gerendert werden, die dann vielleicht nur 1s sichtbar sind, bis der Filter vom Benutzer wieder geändert wird. Man erspart sich also viele unnötige Render-Aktivitäten.
Wenn ich bei Webcams sowohl "720p" und auch "1080p" auswähle, werden mir alle angezeigt, die zu einem der Werte passen.
Produkte live nachladen: Wie oben nur das die Ergebnisse nicht erst einmal als Zahl da gestellt werden sondern direkt als Listing gerendert werden. Erhöht also die Last auf dem
Server.
Produkte & Filter live nachladen: Hier ist das wichtige der kleine Satz "Nicht mehr kombinierbare Filter werden deaktiviert." Das bedeutet nämlich, dass wenn ich "720p" auswähle, dass Geräte mit dieser Eigenschaft angezeigt werden und nur noch Filter möglich sind, die auf die geladene Liste anwendbar sind. Also wird "1080p" direkt deaktiviert. Ich kann die Liste durch eine zusätzliche Auswahl also nicht mehr erweitern, die bei den anderen Modi. Wenn ich mir jetzt alle Tablets mit "m3", "i3" und "64GB" sowie "128GB" SSD anzeigen lassen möchte, habe ich bei diesen Modus ein Problem.
Warum der 3. Modi bei den Performance-Einstellungen zu finden ist und nicht in den Grundeinstellungen, ist hier etwas seltsam. Klar kann man dann keine riesigen Ergebnismengen mehr bauen, aber ein kartesisches Produkt sollte nicht das Problem sein oder man müsste einen 4. Modi mit diesem Verhalten aber mit Button implementieren.
Einkaufswelten im Kopfbereich von Kategorien werden mit diesem Plugin nicht nur auf der ersten Seite angezeigt, sondern auf allen. Ohne kann es ein Problem sein, dass wenn man auf z.B. ?p=2 auf einen Artikel klick und wieder zurück wechselt, die vorher (bei Infinite Scrolling) noch angezeigt wurde, nicht mehr sichtbar ist.
Das nur auf ?p=0 die Einkaufwelt angezeigt wird, ist fest im Code hinterlegt und nicht über das Backend konfigurierbar. Das Plugin ändert nun dieses Verhalten.
Wenn man mit Events und Hooks für Controller arbeitet, wird man oft die Request-Parameter manipulieren wollen. Wenn man aber nun einen Parameter entfernen will, muss man die setParam()-Methode verstehen, weil man sonst leicht in ein kleines Problem läuft, dass mit der getParam()-Methode zusammen hängt.
$request->setParam('sPage', null);
wird nicht funktionieren und getParam() wird den ursprünglichen Wert zurückliefern. Aber warum? Weil das Request-Object ein internes Array mit den Params beinhaltet. setParam() setzt aber den Eintrag im Array aber nicht auf null, sondern entfernt diesen aus dem Array. Soweit ok. Aber nun kommt das Problem. Wenn getParam den Key im Array nicht findet, get es auch $_GET und $_POST zurück und findet dort natürlich noch den Original-Wert von sPage und liefert den zurück.
$_GET oder $_POST kann man natürlich auch ändern.. ABER das fällt bei der automatischen Prüfung im Shopware Store auf und das Plugin wird instant abgelehnt (auch wenn $_GET in einem Kommentar steht....).
$request->setParam('sPage', 0);
So funktioniert es und durch das seltsame Casting von PHP ist 'if($request->getParam('sPage'))' dann auch false.