Bug #58702
closed
f:uri.page Viewhelper creates broken links on cli
Added by Matthias Krappitz over 10 years ago.
Updated about 9 years ago.
Description
I'm sending out emails via an Extbase Command Controller on the shell / cli. The email text is rendered by a fluid standalone view. All links in this template are rendered wrong by f:uri.page. I never tried this before in that combination, so am unsure if this new with 6.2 or has been around for longer.
command controller part:
...
$view = $this->objectManager->get('TYPO3\CMS\Fluid\View\StandaloneView');
$view->setTemplatePathAndFilename(PATH_site . '...');
...
// various assignments
...
$content = $view->render();
...
fluid template:
...
{settings.siteUrl}<f:uri.page pageUid="{settings.someExistingPageUid}" additionalParams="{tx_this_that : {someObject: someObject}}" />
...
rendered result:
...
http://www.something.com/mod.php?moduleToken=3768ed83b6ed374301a759f0e654b7d73d5058c5&tx_this_that%5BsomeObject%5D=1234
...
expected result would have been a realurl'd url to the given page with the one get parameter added to it. Instead i get a backend module link.
For further information on this issue don't hesitate to contact me at info@aemka.de.
Files
But aren't the viewhelpers f:uri.page / f:link.page are meant to create frontend uris by definition?
So they should be able to do this in whatever context they run in to my mind. Techinally it is possible (i did it several times in pibase era) to manually instanciate a Frontend Engine object even in cli context to achieve this.
Matthias Krappitz wrote:
But aren't the viewhelpers f:uri.page / f:link.page are meant to create frontend uris by definition?
Yes, but unless there is a general solution for the UriBuilder to handle this, you have to implement a solution on your own, as per #9581.
With #60549 it should now be possible to simulate all necessary environment variables. You still have to take care of bootstrapping a minimal frontent environment though.
Write your own Viewhelper for f:link.action or f:link.page, so you can generate links for the frontend, too.
I added an example viewhelper for "link.action", if you set forceFrontendLink="1" in your link.action when executed in backend, then you will receive a frontend link like expected.
- Status changed from New to Rejected
Frontend simulation is a mine field built on an ancient tar pit with quicksand on top. It just screams "trap!" ;)
The only sane advise there is to give, is this: make a custom ViewHelper that you know is capable of generating links on exactly your TYPO3 site with the link generating configuration that you use (baseUrl, absRefPrefix, realurl, hooks that manipulate and much more). That's the only way to create a cross-context ViewHelper.
The same thing goes for any other ViewHelpers that depend on a frontend context, such as `f:format.html`. There is no universal solution to this and the official opinion is that you should be separating your contexts - and that you need to code a bit for those cases when you need to intentionally use one context from the other (it goes if you need BE context from FE, too).
Closing as "rejected" with a suggested alternative solution. It is not the responsibility of TYPO3 to provide cross-context ViewHelpers.
See also: https://forge.typo3.org/issues/67556
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by 
Updated by