Backend Controller wird als "does neither exist as a service or a class" ignoriert

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"

Was mache ich falsch?

1 Like

Mit Hilfe eines Kollegen gelöst:

  1. 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?

  1. 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.

Hi,

Du machst ja einen Api-Controller, laut folgendem Example brauchst Du eigentlich keine Service Definition. https://github.com/shopware/swag-docs-api-controller

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.

2 Likes

Bei mir funktioniert es leider bislang nicht mit Constructor, habe auch mit verschiedenen Services-Definitionen herumexperimentiert.

Häufigste Variante der Fehlermeldung ist jetzt

"The controller for URI “/api/v1/wao-io/flush-cache-action” is not callable. Controller “WaoIo\WaoIoCacheFlusher\Controllers\Backend\CacheFlusher”

has required constructor arguments and does not exist in the container. Did you forget to define the controller as a service?"

 

has required constructor arguments and does not exist in the container. Did you forget to define the controller as a service

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.