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: stephan.schu...@netlogix.de
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: i...@netlogix.de | 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
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
