Shopware Cronjob effektiv debuggen

Vor kurzem ist uns aufgefallen, dass in einem Shop die Bonuspunkte stets sofort freigegeben wurden. Eigentlich sollte dies laut Subshop Konfiguration erst nach 30 Tagen geschehen. Woran das ganze lag schauen wir uns im folgenden Artikel mal genauer an.

Bonus-System

Mit dem Bonus System kann man Kunden leichter zum erneuten Einkauf bewegen. Oft reichen schon 2-10€ an Bonus aus um dir CR um 0,25% zu steigern. Die Bonuspunkte werden bei jedem Kauf gut geschrieben und können beim nächsten Kauf wieder eingelöst werden. Ziemlich simpel.

Was passiert aber wenn der Kunde den Auftrag storniert oder retourniert? Die Punkte können dann theoretisch widerrufen werden, nicht allerdings wenn der Kunde bis dahin diese bereits eingelöst hat. Genau das passiert wenn man die Punkte sofort freigibt, daher haben wir für gewöhnlich eine Sperre von 30 Tagen auf die Freigabe der Punkte.

Fehlverhalten beim Cronjob

Nun kommt mit dem Plugin ein Cronjob. Dieser wird im Standard jede Stunde einmal ausgeführt und prüft ob neue Orders für einen Subshop Vorliegen, welches Freigabeverfahren es gibt (bezahlt oder nach X Tagen) und ob diese Punkte bereits approved wurden oder nicht.

Cronjobs können in Shopware via CLI ausgeführt werden. Ihr müsst also nicht warten bis die Zeit verstrichen ist oder es im Backend ausführen, sondern einfach:

// Ausführen des Cronjobs via Action-Name:
php bin/console sw:cron:run ACTION-NAME
 
// Force den Aufruf des Cronjobs:
php bin/console sw:cron:run ACTION-NAME -f
 

ausführen. Mehr dazu findet Ihr hier.

In dem genannten Fall gab es ein Problem beim ausführen des Cronjobs, denn das Query welches entscheidet welcher Auftrag das approved bekommt hat einwandfrei funktioniert. Und die restlichen Funktionen im Shop liefen ebenfalls ohne Probleme.

XDEBUG

Sobald solche komischen Verhalten auftreten lohnt sich das aktivieren des Debuggers, alles andere ist raten. Für die Nutzung in der CLI müssen wir vorab:

export XDEBUG_CONFIG="idekey=PHPSTORM"

ins Terminal eingeben (je nach IDE auch einen anderen IDEKEY). Ihr könnt danach die xdebug config als parameter im Befehl hinzufügen oder in der php.ini der cli (/etc/php/7.2/cli/php.ini)

xdebug.remote_enable=on
xdebug.remote_host=127.0.0.1
xdebug.remote_port=9006
xdebug.idekey=PhpStorm

Ich bevorzuge die zweite Option, da der CLI Befehl so clean bleibt. Ob der Debugger läuft könnte Ihr einfach mit einem Breakpoint im sw:cache:clear Befehl testen.

Fehlersuche

Schauen wir uns also den Cronjob vom Bonus System an (custom/plugins/SwagBonusSystem/Subscriber/Cronjob.php) – Shopware_CronJob_SwagBonusSystemCron

php bin/console sw:cron:run Shopware_CronJob_SwagBonusSystemCron

Dieser Cron called den $this->unlockPointsService->unlockPointsForAllShops() Service über das Interface. Welcher wiederum die unlockBonusPointsForShop() Method called. Und in der wird es eigentlich erst interessant – also setzen wir uns einen Breakpoint auf $settings bzw. in den switch/case

switch ($settings['bonus_point_unlock_type']) {
case 'paid':
//select all orders which are payed
$orders = $this->getPayedOrders($shop);
break;
case 'day':
$orders = $this->getUnlockedOrdersByDay($shop, $settings);
break;
default:
$orders = [];
}

Da wir in unserem Fall day statt paid nutzen, sollte der Code hier in day gehen – doch leider switched er immer in paid.

Was hier passiert ist folgendes, der Code in getBonusSystemSettings()

public function getBonusSystemSettings()
{
    $customerGroupKey = $this->contextService->getShopContext()->getCurrentCustomerGroup()->getKey();
    if ($this->settings === null) {
        $this->settings = $this->settingsDataService->getSettingsData(
            $this->contextService->getShopContext()->getShop()->getId(),
            $customerGroupKey
        );
    }

    return $this->settings;
}

nutzt den Shopcontext, welcher in der CLI nicht gegeben ist. Correct wäre hier ein find auf das Shop Model mit der ID welche vorher bereits vorliegt. Alles in allem heißt das, wenn euer Hauptshop die Freigabe auf „Bezahlt“ hat und euer Subshop „Nach X Tagen“ werden IMMER die Settings des Hauptshops geladen. Ein ziemlich gravierender Fehler, welcher beim Review einfach übersehen wurde.

Dazu wurde von mir bereits ein Issue erstellt. Schauen wir mal wie Shopware das ganze löst. Meine Empfehlung wäre eine neue Methode, welche als Parameter die ShopId bekommt. Denn getBonusSystemSettings() wird an über 10 Punkten ebenfalls verwendet (mit dem Shopcontext, da der Kunde auf der Website surft und kein anonymer Cronjob das ganze startet).

Fazit

Debugging von Cronjobs ist eigentlich ganz simpel und kann gravierende Fehler aufdecken. Nach dem Implementierung von Cronjobs sollte man zur Sicherheit auf jeden Fall einmal mit dem Debugger durchlaufen und prüfen ob alles passt.