Nach der Lektüre mehrerer Tutorials und Beispiele (die sich alle voneinander unterscheiden) bin ich leider immer noch verwirrt, wie ich einen Backend-Controller auf einer Route bereitstellen soll.
Mein Plugin-Controller liegt in custom/plugins/WaoIoCacheFlusher/src/Controllers/Backend/CacheFlusher.php
und definiert seine Route als Annotation.
/**
* @RouteScope(scopes={"api"})
*/
class CacheFlusher extends AbstractController
// ...
/**
* @Route("/api/v{version}/wao-io/flush-cache-action", name="api.action.WaoIoCacheFlusher.flush-cache-action", methods={"GET"})
*/
public function flushCacheAction(Request $request, Context $context): JsonResponse
In der routes.xml verweise ich darauf:
was auch funktionieren muss, denn ansonsten würde in der Fehlermeldung nicht die definierte Route genannt werden.
In der services.xml definiere ich den Controller als Service:
Beim Versuch von einem Button einer Backend-Seite die Route aufzurufen, erhalte ich die Fehlermeldung
Controller for URI „/api/v1/wao-io/flush-cache-action“ is not callable. Controller „WaoIo\WaoIoCacheFlusher\Controllers\Backend\CacheFlusher“ does neither exist as service nor as class"
Der Backend-Controller darf hier keinen Constructor haben. Ohne Constructor entfällt die Fehlermeldung „does neither exist as a service nor as class“.
Das funktioniert dann zwar, aber wie bekomme ich ohne Constructor den systemConfigService in meinen Controller?
Der API-Call meines Buttons muss einen Authorization-Header mit dem JWT-Token aus der Local Storage an die API-Route des Controllers senden. Da ich leider keine Dokumentation des HttpClient aus der Shopware-Session gefunden habe, bin ich jetzt auf ein einfaches fetch gewechselt.
Durch die Verwendung von fetch stellt sich mir die Frage, ob das Shopware-Backend standardmäßig Polyfills für ältere Browser bereitstellt, oder ob ich mich selbst darum kümmern muss bzw. bewusst darauf verzichte und in der Plugin-Beschreibung vermerke, dass Internet Explorer nicht unterstützt wird.
Ich habe zwar noch keinen Controller in der Api scope gebaut aber bei mir sieht der Eintrag in der services.xml wie folgt aus (brauchst kein class Attribut wenn Du in der id den fulqualfied name nimmst, also das was Du sonst in das class Attribut schreibst)
Und das funktioniert auch wunderbar mit Constructor. Letzten Endes könntest Du aber so auch ohne DI auf Container Services zugreifen, da dieser dann mit $this->container zur Verfügung steht.
Inzwischen habe ich die Probleme lösen bzw. umgehen können.
Die services.xml befand sich an der falschen Stelle, weiterhin ist es mir nicht gelungen, einen HttpClient von Symfony mit oder ohne DI zu verwenden, schließlich hat mir die hier verlinkte Lösung mit GuzzleHttp weitergeholfen.