Bug #69319

Instanciation of TSFE sets backPath of PageRenderer to frontend context. Backend assets 404.

Added by Thomas Mayer about 6 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Must have
Assignee:
-
Category:
Backend API
Target version:
-
Start date:
2015-08-26
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
7
PHP Version:
Tags:
Complexity:
hard
Is Regression:
Yes
Sprint Focus:

Description

Summary:

Whenever TypoScriptFrontendController is instanciated (e.g. by an extension) it also instanciates PageRenderer (which is a Singleton!) and sets the backPath to ``typo3/`` which is a change in behaviour which also affects URL creation of Backend Assets.

Tested with:

  • TYPO3 CMS 7.5-dev 8f540ffbf880691a17d6d4c3ca4f184abba84d22
  • PHP 5.6.9-0+deb8u1, Debian 8, running with Docker in native mode (without virtualization, Host Kernel 3.19 provided by ubuntu 14.04.3), Chromium Version 44.0.2403.89 Ubuntu 14.04 (64-bit)

Reproduce with:

  • instanciate TypoScriptFrontendController in the backend
  • => Some Javascript/CSS assets will have URL prefix typo3/typo3 instead of typo3/ and will be 404'ed.

Impact:

Any extension which instanciates TSFE is affected.

This is a regression in TYPO3 CMS 7.4.0 introduced with commit 43ab6508e7eb01a5b9cca294257349d3e4a53995
https://review.typo3.org/#/c/41239/
https://review.typo3.org/#/c/41239/5/typo3/sysext/frontend/Classes/Controller/TypoScriptFrontendController.php

Deprecation message does not include the breaking change we are faced with here.
https://docs.typo3.org/typo3cms/extensions/core/latest/Changelog/7.4/Deprecation-68074-DeprecateGetPageRenderer.html

Details, Stacktrace and Workaround available at https://github.com/mblaschke/TYPO3-metaseo/issues/150

#1

Updated by Susanne Moog over 3 years ago

  • Category set to Backend API
#2

Updated by Benni Mack over 3 years ago

  • Status changed from New to Needs Feedback

Solution was in v8 to remove the necessity for setBackPath - this is now resolved, as you just use assets with EXT: prefix or relative to PATH_site.

Is this OK for you?

#3

Updated by Thomas Mayer over 3 years ago

Thank you for reporting back. Is this this change: https://docs.typo3.org/typo3cms/extensions/core/Changelog/8.0/Breaking-73763-RemovedBackPathFromPageRenderer.html ?

To my knowledge, metaseo still runs with v8 LTS whereas the 7.6 related workaround is still applied in the code. As long as setting the backPath does not have any effect any more since 8.0, that would render this issue obsolete for v8 LTS and later versions.

The final test would be to remove our workaround (https://github.com/mblaschke/TYPO3-metaseo/issues/150 https://github.com/webdevops/TYPO3-metaseo/commit/247ef20449270874abd6670bb009324c0afabacf) for v8 LTS, as well as setting the backPath itself. I'll report back how that plays out (via https://github.com/webdevops/TYPO3-metaseo/issues/521).

#4

Updated by Riccardo De Contardi over 3 years ago

Is it ok to close this issue or is there still work that should be done? Thank you.

#5

Updated by Thomas Mayer over 3 years ago

In theory, this issue is only relevant for 7 LTS. According to my earlier investigation (https://github.com/webdevops/TYPO3-metaseo/issues/521), my workaround for 7 LTS should not have any effect in 8 LTS any more and can safely be removed (when testing against 8 LTS).

Respectively, when this is not fixed for 7 LTS any more (and I assume, it's not), this issue can be closed.

#6

Updated by Riccardo De Contardi over 3 years ago

  • Status changed from Needs Feedback to Closed

I close this one for now;

If you think that this is the wrong decision, please reopen or ping me. Thank you.

#7

Updated by Benni Mack over 3 years ago

Yes, won't fix that one in TYPO3 v7, as we conceptually fixed that for v8.

Also available in: Atom PDF