Bug #90875
closedDependency check in Extension Manager is broken
100%
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).
Updated by Andreas Kienast almost 5 years ago
- Related to Bug #90788: Automatically use JsonView for json format added
Updated by Daniel Goerz almost 5 years ago
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.
Updated by Georg Ringer almost 5 years ago
- Related to Task #87511: Deprecate $namespacesViewObjectNamePattern property added
Updated by Alexander Schnitzler almost 5 years ago
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
.
Updated by Gerrit Code Review almost 5 years ago
- Status changed from Accepted 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/c/Packages/TYPO3.CMS/+/64014
Updated by Gerrit Code Review almost 5 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/c/Packages/TYPO3.CMS/+/63974
Updated by Anonymous almost 5 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset e68e24da37687de28a68427a7b1732a227f05af7.
Updated by Benni Mack almost 5 years ago
- Status changed from Resolved to Closed