Bug #90875
closed
Dependency check in Extension Manager is broken
Added by Andreas Kienast almost 5 years ago.
Updated almost 5 years ago.
Category:
Extension Manager
Description
The extension manager isn't anymore able to show the modal about conflicting dependencies upon installation of extensions from TER.
How to reproduce:
- Open Extension Manager
- Head to "Get extensions"
- Search for "news"
- Install EXT:news in an incompatible version (e.g. 7.3.1)
A modal should appear informing about unfulfillable dependency constraints with giving the possibility to ignore this ("I know what I'm doing").
You'll notice no visual dependency check appears. A flash message stating the extension has been installed appears, but in fact, the extension was downloaded only.
The response of the Extbase action DownloadController::installFromTerAction()
returns null
only. After stepping thru the execution via debug it's revealed JsonView::render()
expects all variables to be rendered to be defined via $view->setVariablesToRender()
explicitly. Doing so doesn't solve the issue as only variables passed via $view->assign()
are accepted. Object keys being created on the fly are ignored (see Templates/Download/InstallFromTer.json).
- Related to Bug #90788: Automatically use JsonView for json format added
- Description updated (diff)
This looks indeed like we merged a breaking change.
All actions that expect a TemplateView despite the format being 'json' will now receive the wrong (or from another point of view: the correct) view object. This even breaks in core itself in the EM as Andi mentioned.
The DownloadController overwrites the defaultViewObjectName in initializeInstallFromTerAction() which lead to a TemplateView object prior to this patch. Now the action receives a JsonView because the request requested 'json' as a format.
This should obviously be fixed so that HTML is requested in that AJAX call, but I still think this might break more extensions out there and should not be included in the LTS release.
- Related to Task #87511: Deprecate $namespacesViewObjectNamePattern property added
- Status changed from New to Accepted
So here is a more detailed explanation of what happened in Extbase in 9 and what I changed with the latest patch that results in errors.
In version 9, in \TYPO3\CMS\Extbase\Mvc\Controller\ActionController::resolveView()
, Extbase did the following:
- First there was a try to resolve the view object name. That the name of the view class that takes care of the rendering. There was a specific pattern which was used to determine the view class. Parts of that pattern were replaced with variables like the controller and action name and based on that a class had been loaded. This part also did respect the given format. This whole part however has been removed (breaking) in version 10.0 and it will not be brought back.
- If no specific view class could be determined by that first approach, Extbase had a look at
\TYPO3\CMS\Extbase\Mvc\Controller\ActionController::$defaultViewObjectName
. Extbase created a view object from that default view object name class. If for example an action is called with format json but with the regular default view object name, a regular object had been created and checked for its ability to render the current controller context. This check only checked if a template name with a .json
suffix was available.
My assumption was, that when requesting an action with format json e.g., Extbase would use the JsonView class automatically which is not the case. The only thing that requested format should do, is to check for a template with .json
suffix instead of .html
The current implementation checks the requested format and if json
given, \TYPO3\CMS\Extbase\Mvc\Controller\ActionController::$defaultViewObjectName
is used instead of the regular TemplateView
. And since \TYPO3\CMS\Extbase\Mvc\View\JsonView
does not implement a custom canRender
method, it falls back to the default, which is always true
.
- Status changed from Accepted to Under Review
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
- Status changed from Resolved to Closed
Also available in: Atom
PDF