Bug #82196

Can no longer configure diverging templateRootPaths for the view of each plugin in an extension

Added by Thomas Prangenberg over 1 year ago. Updated about 1 year ago.

Status:
Under Review
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2017-08-24
Due date:
% Done:

100%

TYPO3 Version:
8
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

Up until including TYPO3 7.6 it was possible to configure different templateRootPaths for the views of each plugin within an extension.

For example, with the following configuration ...

plugin.tx_extensionName {
    view {
        templateRootPaths {
           0 = EXT:extensionName/Resources/Private/Templates/
        }
        partialRootPaths {
           0 = EXT:extensionName/Resources/Private/Partials/
        }
        layoutRootPaths {
           0 = EXT:extensionName/Resources/Private/Layouts/
        }
   }
}

plugin.tx_extensionName_pluginName {
    view {
        templateRootPaths {
           0 = EXT:extensionName/Resources/Private/Templates/
           1 = EXT:extensionName/Resources/Private/PluginName/Templates/
        }
        partialRootPaths {
           0 = EXT:extensionName/Resources/Private/PluginName/
           1 = EXT:extensionName/Resources/Private/PluginName/Partials/
        }
        layoutRootPaths {
           0 = EXT:extensionName/Resources/Private/Layouts/
           1 = EXT:extensionName/Resources/Private/PluginName/Layouts/
        }
   }
}

... you would get the plugin "PluginName" to use their own template path and fall back to the templates/partials in the default partial root path.
This is no longer possible due to a change in \TYPO3\CMS\Fluid\View\AbstractTemplateView:

https://github.com/TYPO3/TYPO3.CMS/blob/TYPO3_8-7/typo3/sysext/fluid/Classes/View/AbstractTemplateView.php#L79

Before this line, the templateRootPaths are configured correctly. When the templateRootPaths are reinitialized by \TYPO3Fluid\Fluid\View\TemplatePaths::fillDefaultsByPackageName, the configuration within plugin.tx_extensionName.view is used without taking plugin.tx_extensionName_pluginName into account.

Granted, this is a rather special use case, but it was helpful if you were required to change only some of the templates or partials in a plugin and wanted to reuse most of the resources of another plugin. Also, the old behaviour was much more consistent with the overall Typoscript configuration of extbase plugins where you can also, for example, configure different storagePids for each plugin.

I couldn't find a breaking change remark in the changelog so I don't think this is intended?

regards
Thomas


Related issues

Related to TYPO3 Core - Bug #82181: Cannot override plugin view.templateRootPaths because of cache Under Review 2017-08-23
Related to TYPO3 Core - Task #82487: Revert TemplatePaths optimizations and regressions Closed 2017-09-14

Associated revisions

Revision 30c46719 (diff)
Added by Claus Due over 1 year ago

[BUGFIX] Remove runtime cache and early return from TemplatePaths

This patch removes the previously introduced runtime cache
and early returns from TemplatePaths, both of which were
implemented in an attempt to prevent excessive TypoScript
parsing - an issue which has since been solved by optimising
the TypoScript parsing enough that a cache and early return
is no longer necessary (no longer constitutes a significant
performance increase).

The early return and caching introduced regressions described
in the related forge issues. Removing both solves those problems.

In addition, the method resolving TypoScript paths is now
covered by extensive unit tests confirming everything from
merging to sorting of template paths. An average of 8 tests
cover the method's lines. Each of the expected behaviors
is now declared as specific test.

Change-Id: Ia6d505dcec7d77ad7aaeea9094d7d85a58553c63
Resolves: #82196
Resolves: #82181
Related: #79662
Releases: master, 8.7
Reviewed-on: https://review.typo3.org/53917
Tested-by: TYPO3com <>
Reviewed-by: Jigal van Hemert <>
Tested-by: Jigal van Hemert <>
Reviewed-by: Wouter Wolters <>
Reviewed-by: Stefan Neufeind <>
Reviewed-by: Andreas Fernandez <>
Tested-by: Andreas Fernandez <>

Revision 6e029278 (diff)
Added by Claus Due over 1 year ago

[BUGFIX] Remove runtime cache and early return from TemplatePaths

This patch removes the previously introduced runtime cache
and early returns from TemplatePaths, both of which were
implemented in an attempt to prevent excessive TypoScript
parsing - an issue which has since been solved by optimising
the TypoScript parsing enough that a cache and early return
is no longer necessary (no longer constitutes a significant
performance increase).

The early return and caching introduced regressions described
in the related forge issues. Removing both solves those problems.

In addition, the method resolving TypoScript paths is now
covered by extensive unit tests confirming everything from
merging to sorting of template paths. An average of 8 tests
cover the method's lines. Each of the expected behaviors
is now declared as specific test.

Change-Id: Ia6d505dcec7d77ad7aaeea9094d7d85a58553c63
Resolves: #82196
Resolves: #82181
Related: #79662
Releases: master, 8.7
Reviewed-on: https://review.typo3.org/53932
Reviewed-by: Susanne Moog <>
Tested-by: Susanne Moog <>
Tested-by: TYPO3com <>
Reviewed-by: Andreas Fernandez <>
Tested-by: Andreas Fernandez <>

History

#1 Updated by Thomas Prangenberg over 1 year ago

  • Description updated (diff)

#2 Updated by RVVN no-lastname-given over 1 year ago

  • Related to Bug #82181: Cannot override plugin view.templateRootPaths because of cache added

#3 Updated by Thomas Prangenberg over 1 year ago

Actually, I digged a bit deeper and it seems like the configuration of the view is not even used at all when \TYPO3\CMS\Fluid\View\TemplateView::canRender is invoked.

Does that mean it is no longer possible to overwrite the default template root path of an extbase plugin to something that does not fit the nameing convention ("Resources/Private/Templates/")? Doesn't that make the configuration in TypoScript (at least configuration of the default paths) kind of pointless?

#4 Updated by Claus Due over 1 year ago

I couldn't find a breaking change remark in the changelog so I don't think this is intended?

No, this was not intended. Seems it was forgotten during the replacement and there was no similar concept in the old Fluid package the new one was built from.

The reason $paths->fillDefaultsByPackageName($extensionKeyFromRequest) gets used is simply to save a rather significant chunk of code in the CMS AbstractTemplateView IIRC. TemplatePaths itself only knows about the extension scope (there is no concept of "plugins" in Fluid itself) and the API implies that if this secondary scope has to be supported, then the TS paths must be resolved externally and set in TemplatePaths using the fillFromConfigurationArray method instead. And, I presume, it must combine those paths with any paths that are defined in the extension scope, giving the plugin-scope ones priority.

It's going to require a little refactoring. Maybe you can use this info to come up with a change that fixes this? :)

Does that mean it is no longer possible to overwrite the default template root path of an extbase plugin to something that does not fit the nameing convention(?)

No, it just means you have to add those paths to the extension view paths scope instead. If you wish, you can also completely remove the default lookup paths. The one thing you can't do because see above, is target a specific plugin by name.

#5 Updated by Gerrit Code Review over 1 year ago

  • Status changed from New to Under Review

Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/53872

#6 Updated by Gerrit Code Review over 1 year ago

Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/53872

#7 Updated by Claus Due over 1 year ago

@Thomas could I get you to try the linked core patch if that solves the problem for you? Don't forget to vote on Gerrit ;)

#8 Updated by Gerrit Code Review over 1 year ago

Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/53917

#9 Updated by Gerrit Code Review over 1 year ago

Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/53917

#10 Updated by Gerrit Code Review over 1 year ago

Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/53917

#11 Updated by Gerrit Code Review over 1 year ago

Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/53917

#12 Updated by Gerrit Code Review over 1 year ago

Patch set 5 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/53917

#13 Updated by Gerrit Code Review over 1 year ago

Patch set 1 for branch TYPO3_8-7 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/53932

#14 Updated by Anonymous over 1 year ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100

#15 Updated by David Frerich about 1 year ago

There is another problem with this issue that is not resolved and still exists.

Overriding the view configuration with flexforms is not possible anymore, because the Configuration provided by the extbase controller and set with "setViewConfiguration" is overwritten with the method "getContextSpecificViewConfiguration".

I think the Method fillDefaultsByPackageName should not be called or be additive / merged, if a Extbase Controller set the view configuration beforehand.
The Method setViewConfiguration in \TYPO3\CMS\Extbase\Mvc\Controller\ActionController is now without use.

#16 Updated by Benni Mack about 1 year ago

  • Related to Task #82487: Revert TemplatePaths optimizations and regressions added

#17 Updated by Claus Due about 1 year ago

  • Status changed from Resolved to Under Review

Also available in: Atom PDF