Skip to content

Drop v11/v12, add TYPO3 v14 support#49

Merged
achimfritz merged 4 commits into
masterfrom
feature/typo3-v14-support
May 28, 2026
Merged

Drop v11/v12, add TYPO3 v14 support#49
achimfritz merged 4 commits into
masterfrom
feature/typo3-v14-support

Conversation

@davidsteeb
Copy link
Copy Markdown
Contributor

Summary

  • Bumps typo3/cms-{backend,frontend} constraint to ^13.4 || ^14.0 and PHP to ^8.2
  • Removes v11-only paths: Hook/FrontendHook.php, ext_tables.php, Resources/Private/TemplatesV11/, and the matching SC_OPTIONS hook in ext_localconf.php
  • Updates two listeners/controllers for TYPO3 v14 breaking changes

TYPO3 v14 breaking changes

AfterCachedPageIsPersistedEvent lost its controller.
In v14 the event only carries request / cacheIdentifier / cacheData / cacheLifetime (cms-frontend/Classes/Event/AfterCachedPageIsPersistedEvent.php). The listener now reads cache tags from $event->getCacheData()['cacheTags'], which both v13 and v14 populate before dispatching ($content['cacheTags'] = $pageCacheTags; in RequestHandler::handle()).

AbstractMessage::OK / WARNING / ERROR removed. Replaced by ContextualFeedbackSeverity::* enum cases unconditionally — the Typo3Version::getMajorVersion() === 11 branches in ManagementController are gone.

v11/v12 cleanup

With v11/v12 out of scope, the following v11-only fallbacks are removed:

  • Classes/Hook/FrontendHook.php + matching SC_OPTIONS entry (tslib/class.tslib_fe.php / insertPageIncache) — superseded by the event listener since v12
  • ext_tables.php (v11 ExtensionUtility::registerModule) — Configuration/Backend/Modules.php already handles this on v12+
  • Resources/Private/TemplatesV11/

This is a backwards-incompatible release — see UPGRADE.md for the v4 → v5 notes. Tag accordingly (5.0.0).

Context

Sister PR over at b13/cloudflare-cdn#6. Both are needed so b13.com (currently on TYPO3 14.3) can wire up the existing TAE-style Cloudflare CDN integration.

Test plan

  • Install on a fresh TYPO3 v14.3 instance — module loads, no PHP errors
  • Page cache write → tx_proxy cache row appears with correct URL + tags
  • Trigger backend "Clear proxy cache" → flushes via configured reverseProxyProvider
  • Backend module purge-URL form works and renders flash messages with correct severity
  • Smoke-test against a v13 install to confirm we didn't accidentally break the still-supported LTS

Bumps the supported TYPO3 range to ^13.4 || ^14.0 and PHP minimum to ^8.2.
Two TYPO3 v14 breaking changes required code adjustments; the rest is
just removing the v11-only fallback code that is no longer reachable.

* AfterCachedPageIsPersistedEvent no longer carries the
  TypoScriptFrontendController in v14. The listener now reads cache tags
  from $event->getCacheData()['cacheTags'], which TYPO3 populates in
  both v13 and v14 before dispatching the event.
* AbstractMessage::OK / WARNING / ERROR constants were removed in v14.
  ManagementController switches to ContextualFeedbackSeverity::* enum
  cases unconditionally; the Typo3Version major-version checks are gone.

Cleanup of v11-only code:

* Classes/Hook/FrontendHook.php and the matching SC_OPTIONS hook in
  ext_localconf.php — the v11 tslib_fe insertPageIncache hook has been
  superseded by the AfterCachedPageIsPersistedEvent listener since v12.
* ext_tables.php — v11-only ExtensionUtility::registerModule() call.
  Configuration/Backend/Modules.php has handled the registration since
  v12.
* Resources/Private/TemplatesV11/ — v11 fallback Fluid template.

See UPGRADE.md for the v4 -> v5 upgrade notes.
@davidsteeb davidsteeb self-assigned this May 26, 2026
@davidsteeb davidsteeb requested a review from bmack May 26, 2026 19:05
@bmack bmack requested a review from achimfritz May 26, 2026 21:13
TYPO3 v14 added strict type declarations to Typo3DatabaseBackend's
public API; v13's parent signatures had no types. Loading the
extension on v14 fataled with:

  Declaration of B13\Proxycachemanager\Cache\Backend\ReverseProxyCacheBackend::remove($entryIdentifier)
  must be compatible with TYPO3\CMS\Core\Cache\Backend\Typo3DatabaseBackend::remove(string $entryIdentifier): bool

The fix:

* Drop the remove() override entirely. It was a pure passthrough to
  parent::remove() — the docblock explained the historical reason the
  provider call was removed, but the override itself adds no behaviour.
  Parent::remove() is inherited automatically.
* Add covariant ": void" return types to flush(), flushByTag(),
  flushByTags() to match v14 while staying compatible with v13's
  untyped parents (return-type covariance is allowed).

Parameter types stay untyped so v13 (untyped parent) keeps working;
PHP allows the child to widen — but not narrow — parameter types.
TYPO3 v14 changed TransientBackendInterface from an empty marker
interface to a proper contract with

    set(string $entryIdentifier, mixed \$data, ...): void

That contract is incompatible with the parent Typo3DatabaseBackend's
typed signature

    set(string \$entryIdentifier, string \$data, ...): void

so v14 refuses to load a class that both extends Typo3DatabaseBackend
and implements TransientBackendInterface, fataling with:

  Declaration of TYPO3\CMS\Core\Cache\Backend\Typo3DatabaseBackend::set(...)
  must be compatible with TYPO3\CMS\Core\Cache\Backend\TransientBackendInterface::set(...)

ReverseProxyCacheBackend originally declared the marker so the
configured VariableFrontend would skip serialize()/unserialize() on
the stored URL strings. The optimisation was always minor (we store
short strings), and the marker simply cannot coexist with
Typo3DatabaseBackend on v14. Dropping the interface declaration
returns to the default VariableFrontend behaviour — URLs are
serialised/unserialised transparently — which is functionally
identical and works on both v13 and v14.
The previous commit removed Classes/Hook/FrontendHook.php but missed
the matching service definition in Configuration/Services.yaml. With
the class gone, every DI container build fataled:

  Invalid service "B13\Proxycachemanager\Hook\FrontendHook": class
  "B13\Proxycachemanager\Hook\FrontendHook" does not exist.
Copy link
Copy Markdown
Contributor

@achimfritz achimfritz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think we have also adapt the CI workflow (which was disabled when creating PR).
can be done in an other issue.
we should also use ServerRequestInterface instead of RequestInterface in ProxyProviderInterface (this will be breaking but can be done, because we make a new major release)

@achimfritz achimfritz merged commit 4bd118f into master May 28, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants