Meine Apache-Conf für Shopware-Installationen, die ich in verschiedenen VMs verwende.
<VirtualHost *:80>
ServerAdmin hp@ubuntu.local
DocumentRoot "/var/www/shopware"
ServerName shopware.localhost
ServerAlias www.shopware.localhost
ErrorLog "/var/log/apache2/shopware.error.log"
CustomLog "/var/log/apache2/shopware.access.log" combined
RewriteEngine On
RewriteMap lc int:tolower
<Directory "/var/www/shopware">
Options Indexes FollowSymlinks MultiViews
AllowOverride All
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
Wer sich schon mal bei Shopware damit auseinander setzen musste, wie die Einstellung "Deaktiviere Steuern wenn eine USt-IdNr. angegeben wurde" funktioniert, ist sicher schnell im Checkout-Controller und in der Methode isTaxFreeDelivery($userData) gelandet.
Leider ist diese Methode in einem Stil geschrieben, der sie meiner Meinung nach extrem schwer lesbar macht. Die wieder negierten emptys und vielen return sorgen dafür, dass man den dahinter steckten logischen Ausdruck nur schwer erkennt, wobei der an sich ziemlich einfach ist.
Alles ist wie man man erwartet nur das bei fehlender VatID in der Shipping-Address auch die Billing-Address "einspringen" kann, muss man sich mehrmals durch den Kopf gehen lassen.
Ich habe die Methode noch mal in für mich besser lesbarer Form nieder geschrieben:
$shippingCountryTaxFree = !empty($userData['additional']['countryShipping']['taxfree']);
$shippingCountryTaxFreeVatID = !empty($userData['additional']['countryShipping']['taxfree_ustid']);
$billingCountryTaxFreeVatID = !empty($userData['additional']['country']['taxfree_ustid']);
$shippingVatID = !empty($userData['shippingaddress']['ustid'];
$billingVatID = !empty($userData['billingaddress']['ustid'];
return $shippingCountryTaxFree
||
($shippingCountryTaxFreeVatID &&
(
(!$shippingVatID && billingVatID && billingCountryTaxFreeVatID)
||
$shippingVatID
)
);
Die Logik stammt aus der Version 5.3.5
So sehen die Params von einem Article-Batch (3 Artikel) für die Article-API aus:
{
"id": false,
"subId": false,
"version": 1,
"useNumberAsId": "true",
"module": "api",
"controller": "articles",
"action": "index",
"0": {
},
"1": {
},
"2": {
}
}
Int-Index und selbst ein Array, dadurch ist ein einzelner Artikel darin zu erkennen. Id gibt es in den Params direkt auch noch, also ist das kein Indikator für eine Batch-Request.
[2018-01-09 13:26:18] plugin.WARNING: SW001: price[EK] should be checked, sell for 1041.18, purchase for 2380 by demo [] {"uid":"5e860d0"}
[2018-01-09 13:27:58] plugin.WARNING: SW002: price(EK) should be checked, sell for 8.40, purchase for 59.5 by demo. [] {"uid":"075a3b6"}
Die obere Zeile kann im Shopware Backend nicht angezeigt werden. Die untere schon. Also sollte man mit eckigen Klammern in Log-Messages aufpassen.
Ist mir beim Testen mit 5.3.5 aufgefallen.
Weil es ja Probleme mit TLS-SNI-01 gibt, kann man auch einfach eine Domain neu installieren. Dann wird ein neuer Eintrag mit dem Postfix 0001 angelegt.
sudo apache2ctl stop
sudo letsencrypt --authenticator standalone --installer apache -d mp4togif.com -d www.mp4togif.com
sudo apache2ctl start
Aber ich werde nochmal warten, ob sich das Problem nicht löst und TLs-SNI-01 wieder aktiviert wird.
Das wären so für mich die Highlights, warum man schnell auf Shopware 5.3.5 updaten sollte. Gerade die eigene Email Adresse für Fehlermails ist echt praktisch, besonders wenn man wieder Bots Formulare ausfüllen und X-CSRF Fehler auslösen.
SW-18075 - Es ist nun möglich, Fehlermails an eine separate Email Adresse zu verschicken.
SW-18510 - Fügt den API Endpunkt /users hinzu, welcher es ermöglicht Backend Benutzer über die API zu verwalten (larsbo).
SW-19404 - Ändern der Erstellung der Cronjobs, um aktive Cronjobs über die 'cronjob.xml' erstellen zu können (t2oh4e).
RTL plus liegt nicht in der voreingestellten Senderliste. Aber man kann den Sender ganz einfach hinzufügen, ohne Sendersuchlauf oder ähnliches.
Man muss nur die DLNA Senderliste (eine XML) per Hand anpassen.
<channel number="296">
<tuneType>DVB-S</tuneType>
<modulation>QPSK</modulation>
<visible>true</visible>
<type>tv</type>
<name>RTL PLUS</name>
<freq>12188</freq>
<pol>h</pol>
<sr>27500</sr>
<src>1</src>
<pids>0,41,70,137,168</pids>
</channel>
Wenn beim Versuch Shopware zu updaten, der Prozess-Dialog ewig läuft und dann irgendwann das Backenend einfach neu lädt, kann es am media/ Verzeichnis liegen. Ich hab, als das Problem bei meinem lokalen Entwickler-Shop auftrat erst einmal alle leeren Verzeichnisse entfernt mit
sudo find media/ -type d -empty -delete
Dann noch mal die Rechte für die Dateien neu gesetzt (wegen über SCP hochgeladene Plugins oder so) und nachdem das Backend zwei mal neugeladen wurde, lief das Update sofort und ohne Probleme an. Hat mich zwar einige Stunden gekostet, bis alles soweit war, aber endlich wieder Updaten zu können ist es auch wert.