Hallo Jürgen. Auf solche Probleme stößt man leider sehr schnell, wenn man im Backend-Context oder im CLI-Context Frontendoperationen durchführt. Einen sinnvollen Weg, im Backend einen Frontend-Context zu erzeugen gibt es nicht. Das endet immer im Gefrickel und vollständig von BE auf FE umschalten wirst Du trotzdem nicht können.
Du kannst den Configuration-Manager zum Beispiel dahin vergewaltigen, dass er seine Backend-Config vergisst (die für Controller auf „module“ basiert) und eine Frontend-Config generiert (die auf „plugin“ baisert). Das ist aber weit entfernt von Public API. Damit fängt es bei mir häufig an, das ist der Teil der noch relativ einfach geht. Technisch musst Du nur die passenden Rahmenbedingungen für Frontend-Settings liefern, also ein globales TSFE. Meiner Meinung nach ist das Extbase-Utility FrontendSimulatorUtility hierfür nicht ausreichend, das TSFE-Objekt das daraus proudziert wird ist nicht funktional. Stattdessen macht das EidUtility mit „initFeUser()“ schon einen halbwegs guten Job, wenn auch das dadurch erzeugte TSFE trotzdem noch nicht vollständig initialisiert ist und außerdem ist es „private static“ im EidUtility, man muss also etwas tricksen um da ran zu kommen. Und wieder sind wir weg von der Public API. Die Links die Du ansprichst sind schon schwieriger. Der UriBuilder fragt den EnvironmentService nach „isEnvironmentInBackendMode()“, das liest eine PHP-Konstante aus. Das heißt, dass es hier einfach kein Setting gibt mit dem Du den UriBuilder dazu veranlassen kannst, eine FE-Uri zu bauen, wenn Du nicht entweder den EnvironmentService überschreibst oder den UriBuilder selbst, jeweils um eine Möglichkeit, entgegen der Konstante von einem anderen Environment auszugehen. Hier bist Du dann auch wieder sehr weit von Public API entfernt. https://github.com/TYPO3/TYPO3.CMS/blob/master/typo3/sysext/extbase/Classes/Mvc/Web/Routing/UriBuilder.php#L621 https://github.com/TYPO3/TYPO3.CMS/blob/master/typo3/sysext/extbase/Classes/Service/EnvironmentService.php#L39 Du siehst: Das ist so eigentlich gar nicht vorgesehen. Wenn ich an FE-Features im Backend muss, baue ich mir in der Regel einen Frontend-Controller dem ich die Daten per POST-Request übergeben kann. Das sieht in der Regel so aus: • Ein HttpRequest-Objekt innerhalb des CLI ruft eine bestimmte, im BE konfigurierte Seite des Frontends auf. • Es wird als POST-Payload einerseits ein Model übergeben das dem Frontend-Controller alle Daten liefert die er braucht und andererseits ein per HashService erzeugter MAC des serialisierten Model-Objekts. • Der Frontend-Controller darf so einerseits prüfen, dass mein Model-Objekt von mir kommt (weil nur ich es per MAC signieren konnte) und andererseits dann auf ein Argument mappen, bevor er sein Frontend-Ding damit durchzieht. • Hier hast Du dann spontan Timeout- und Memory-Einschränkungen des Frontends die Du im CLI nicht hast. Grundsätzlich den Umweg über ein wirkliches Frontend zu gehen und den Request dabei so zu signieren, dass er nicht von fremden gefaket werden kann, hab ich mir vor Jahren aus der Solr-Extension abgeschaut, der Index von pages wird dort so erzeugt. Beste Grüße, Stephan Schuler Web-Entwickler | netlogix Web Solutions Telefon: +49 (911) 539909 - 0 E-Mail: [email protected] Web: websolutions.netlogix.de ---------------------------- Neu: Wir sind Amazon Web Services Partner. Mehr erfahren: https://websolutions.netlogix.de/technologie/amazon-web-services-aws ---------------------------- netlogix GmbH & Co. KG IT-Services | IT-Training | Web Solutions Neuwieder Straße 10 | 90411 Nürnberg Telefon: +49 (911) 539909 - 0 | Fax: +49 (911) 539909 - 99 E-Mail: [email protected] | Web: http://www.netlogix.de netlogix GmbH & Co. KG ist eingetragen am Amtsgericht Nürnberg (HRA 13338) Persönlich haftende Gesellschafterin: netlogix Verwaltungs GmbH (HRB 20634) Umsatzsteuer-Identifikationsnummer: DE 233472254 Geschäftsführer: Matthias Schmidt _______________________________________________ TYPO3-german mailing list [email protected] http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
