Bug #58702

f:uri.page Viewhelper creates broken links on cli

Added by Matthias Krappitz almost 6 years ago. Updated over 4 years ago.

Status:
Rejected
Priority:
Must have
Assignee:
-
Category:
Fluid
Target version:
Start date:
2014-05-12
Due date:
% Done:

0%

TYPO3 Version:
6.2
PHP Version:
5.4
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

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 .

ActionViewHelper.php View (9.33 KB) Ephraim Härer, 2015-08-20 10:23


Related issues

Related to TYPO3 Core - Bug #60549: Get GeneralUtility::getIndpEnv in ContentObjectRenderer mockable Closed 2014-07-25
Related to TYPO3 Core - Bug #67556: System news cannot render RTE content Accepted 2015-06-17

History

#1 Updated by Georg Ringer almost 6 years ago

the reason is quite simple as cli context is defined to behave like backend and not frontend.

flow got the same challange, see http://forum.typo3.org/index.php/t/198996/

#2 Updated by Matthias Krappitz almost 6 years ago

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.

#3 Updated by Mathias Brodala over 5 years ago

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.

#4 Updated by Mathias Brodala over 5 years ago

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.

#5 Updated by Ephraim Härer over 4 years ago

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.

#6 Updated by Claus Due over 4 years ago

  • 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