1

I have a legacy extension with a plugin that's handled in MyPluginController, which extends TYPO3\CMS\Frontend\Plugin\AbstractPlugin.

The plugin is registered as a USER_INT content object:

plugin.tx_myext_pi1 = USER_INT
plugin.tx_myext_pi1.userFunc = Foo\MyExt\Controller\MyPluginController->main

The render() method of both the UserContentObject and UserInternalContentObject (which handle USER + USER_INT) return a string (i.e. the rendered output of your plugin).

There are a few instances in my controller, where a redirect is required (e.g. to call the payment page of a remote payment gateway). So far this was done with HttpUtility::redirect(), but this method has been marked as deprecated as of V11.3 [1].

The deprecation note says that a PSR-7 compliant response object should be used instead. The suggested migration strategies are to either return a Response object directly or throw a PropagateResponseException. But the latter is considered an "intermediate solution only".

If I return a PSR-7 Response directly, it (predictably) results in an exception as we already know that a string is expected:

Object of class TYPO3\CMS\Core\Http\RedirectResponse could not be converted to string

So what can you do? Is there a sustainable way to issue an HTTP redirect in this scenario? And if not, what else can you do? One could return a dummy page and work with an onload Javascript redirect or try a redirect meta header in HTML. But these are all pretty ugly approaches IMHO.

[1] https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/11.3/Deprecation-94316-DeprecatedHTTPHeaderManipulatingMethodsFromHttpUtility.html

Stoppeye
  • 85
  • 7
  • Why do you end up at the end of the render() method (and returning a string). Should the redirect not be done directly? – Thomas Löffler Mar 31 '23 at 21:00
  • No, if you read the deprecation note, that's exaclty what should NOT be done: "explicit die() or exit() calls, as well as directly manipulating HTTP headers with header() should be avoided". That's actually the reason, why HttpUtility::redirect() was deprecated, because it sets a "location:" HTTP header and then issues a `die()`. – Stoppeye Apr 03 '23 at 07:29
  • Link to documentation has changed: https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/11.3/Deprecation-94316-DeprecatedHTTPHeaderManipulatingMethodsFromHttpUtility.html – yogi Jul 11 '23 at 08:53

1 Answers1

1

There are only two clean solutions to achive a redirect in a USER_INT plugin.

Solution 1 (recommended):

As shown in the docs use the PropagateResponseException

$responseFactory = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(
    \Psr\Http\Message\ResponseFactoryInterface::class
);

$response = $responseFactory
    ->createResponse()
    ->withAddedHeader('location', 'https://example.com');

throw new \TYPO3\CMS\Core\Http\PropagateResponseException($response);

If USER_INT UserFunctions will be able to handle a PSR-7 compliant response objects and the possibility to throw a PropagateResponseException will be removed. The only thing you have to do is to remove the exception-casting and return the response.

remove:

throw new \TYPO3\CMS\Core\Http\PropagateResponseException($response);

replace by:

return $response;

Solution 2:

If you really not want to use the PropagateResponseException. Then you could return a script tag. Not sure, if this works in all browsers - But should.

return '<script type="text/javascript">location.href = "https://example.com";</script>';
Mogens
  • 548
  • 1
  • 3
  • 10
  • Thanks! This basically confirms, what I suspected. For the time being, I've used the PropagateResponseException in my specific migration case. – Stoppeye Jul 12 '23 at 07:20