Project

General

Profile

Actions

Bug #82196

closed

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

Added by Thomas Prangenberg over 6 years ago. Updated about 4 years ago.

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

100%

Estimated time:
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 2 (0 open2 closed)

Related to TYPO3 Core - Bug #82181: Cannot override plugin view.templateRootPaths because of cacheClosed2017-08-23

Actions
Related to TYPO3 Core - Task #82487: Revert TemplatePaths optimizations and regressionsClosedBenni Mack2017-09-14

Actions
Actions #1

Updated by Thomas Prangenberg over 6 years ago

  • Description updated (diff)
Actions #2

Updated by RVVN no-lastname-given over 6 years ago

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

Updated by Thomas Prangenberg over 6 years 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?

Actions #4

Updated by Claus Due over 6 years 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.

Actions #5

Updated by Gerrit Code Review over 6 years 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

Actions #6

Updated by Gerrit Code Review over 6 years 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

Actions #7

Updated by Claus Due over 6 years 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 ;)

Actions #8

Updated by Gerrit Code Review over 6 years 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

Actions #9

Updated by Gerrit Code Review over 6 years 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

Actions #10

Updated by Gerrit Code Review over 6 years 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

Actions #11

Updated by Gerrit Code Review over 6 years 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

Actions #12

Updated by Gerrit Code Review over 6 years 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

Actions #13

Updated by Gerrit Code Review over 6 years 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

Actions #14

Updated by Anonymous over 6 years ago

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

Updated by David Frerich over 6 years 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.

Actions #16

Updated by Benni Mack over 6 years ago

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

Updated by Claus Due over 6 years ago

  • Status changed from Resolved to Under Review
Actions #18

Updated by Susanne Moog about 5 years ago

  • Status changed from Under Review to Needs Feedback

The patch has been applied, reverted and fixed differently. Therefor please check whether this issue still persists.

Actions #19

Updated by Georg Ringer about 4 years ago

  • Status changed from Needs Feedback to Closed

closed as has been solved and lack of feedback. feel free to reopen if still valid

Actions

Also available in: Atom PDF