---
title: "Breaking: #98377 - Fluid StandaloneView does not create an Extbase Request anymore"
manual: "TYPO3 Core Changelog"
version: "main"
permalink: "https://docs.typo3.org/permalink/changelog:breaking-98377-1663607123"
source: "Changelog/12.0/Breaking-98377-FluidStandaloneViewDoesNotCreateAnExtbaseRequestAnymore.rst"
typo3-version: "12.0"
typo3-major: 12
type: "breaking"
issue: 98377
forge: "https://forge.typo3.org/issues/98377"
tags: ["Fluid", "PHP-API", "NotScanned", "ext:fluid"]
rendered: "2026-09-19T12:12:50+00:00"
---

# Breaking: #98377 - Fluid StandaloneView does not create an Extbase Request anymore {#breaking-98377-1663607123}

See [forge#98377](https://forge.typo3.org/issues/98377)

## Description {#description}

In our efforts to further speed up, streamline and separate Fluid from Extbase,
the `\TYPO3\CMS\Fluid\View\StandaloneView` has been changed to no longer
create an Extbase Request anymore.

StandaloneView is typically not used in Extbase context, creating an Extbase
Request at this point was a very unfortunate architectural flaw leading to a
not wanted context switch.

Not having an Extbase Request within StandaloneView anymore can have impact on
behavior of some Fluid ViewHelpers.

## Impact {#impact}

Common usages of StandaloneView are a frontend related `FLUIDTEMPLATE`
content object, plus various usages in non-Extbase extensions like rendering eMails
or similar. Within `FLUIDTEMPLATE`, the current non-Extbase PSR-7
ServerRequest is actively set to StandaloneView, custom extension usages may need
to `$view->setRequest($request)` explicitly.

Some ViewHelpers that rely on Extbase functionality throw exceptions when
a Request is not set, or if the Request is not an Extbase Request. Those will
refuse to work for instance when used in a template triggered by a `FLUIDTEMPLATE`
content object.

Most notably, all `f:form` ViewHelpers are affected of this, plus
eventually custom ViewHelpers that access Extbase specific `Request`
methods.

## Affected installations {#affected-installations}

Instances with extensions using StandaloneView in their code may need attention,
and frontend rendering using `FLUIDTEMPLATE` content objects may need
adaptions if Extbase-only ViewHelpers like `f:form` are used.

## Migration {#migration}

### Avoiding `f:form` in non-Extbase context {#avoiding-html-f-form-in-non-extbase-context}

The `f:form` ViewHelpers are Extbase specific: They especially take care of
handling Extbase internal fields like `__referrer` and similar. The casual solution
is to switch these usages away from those ViewHelpers, and use the HTML counterparts
directly, for instance using `<input ...>` instead of `<f:form.input ...>`.

### Custom StandaloneView code {#custom-standaloneview-code}

Extensions that instantiate `StandaloneView` may want to `$view->setRequest($request)`
to hand over the current request to the view, since the request is no longer initialized
automatically. This is needed for ViewHelpers that rely on `$renderingContext->getRequest()`.

### Custom ViewHelpers {#custom-viewhelpers}

Custom ViewHelpers used in `StandaloneView` that call methods from Extbase
`\TYPO3\CMS\Extbase\Mvc\Request` which are not part of
`\Psr\Http\Message\ServerRequestInterface` will throw fatal PHP errors.

Possible solutions:

-   Create an Extbase Request within a controller and `setRequest()` it to the
    view instance as quick solution.
-   Properly boot Extbase using the Extbase Bootstrap to have a fully initialized
    Extbase Request in the View.
-   Avoid using Extbase specific methods within the ViewHelper by checking if the
    incoming request implements Extbase `\TYPO3\CMS\Extbase\Mvc\RequestInterface`.
    This allows creating "hybrid" ViewHelpers that work in both contexts.
-   Avoid using Extbase specific methods within the ViewHelper by fetching data from
    the given `\Psr\Http\Message\ServerRequestInterface` Request, or it's attached
    core attributes.