Bug #90875

Dependency check in Extension Manager is broken

Added by Andreas Fernandez 4 months ago. Updated 3 months ago.

Status:
Closed
Priority:
Must have
Assignee:
-
Category:
Extension Manager
Target version:
Start date:
2020-03-29
Due date:
% Done:

100%

TYPO3 Version:
10
PHP Version:
Tags:
Complexity:
Is Regression:
Yes
Sprint Focus:

Description

The extension manager isn't anymore able to show the modal about conflicting dependencies upon installation of extensions from TER.

How to reproduce:
  1. Open Extension Manager
  2. Head to "Get extensions"
  3. Search for "news"
  4. 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 issues

Related to TYPO3 Core - Bug #90788: Automatically use JsonView for json format Closed 2019-01-22 2019-01-22
Related to TYPO3 Core - Task #87511: Deprecate $namespacesViewObjectNamePattern property Closed 2019-01-21

Associated revisions

Revision e68e24da (diff)
Added by Alexander Schnitzler 4 months ago

Revert "[BUGFIX] Automatically use JsonView for json format"

This reverts commit 9c0e151e311639fbc930ba36f767ec11dfef2bef.

The original patch followed the misconception that when using json as format query parameter, Extbase would automatically use the JsonView object. Instead, Extbase should only try to find a template file with a .json file type.

Change-Id: Id224ad901d1e415687c8cd2207d516b19a09fd99
Releases: master
Resolves: #90875
Reverts: #90788
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/63974
Tested-by: TYPO3com <>
Tested-by: Alexander Schnitzler <>
Tested-by: Andreas Fernandez <>
Tested-by: Christian Eßl <>
Tested-by: Daniel Goerz <>
Reviewed-by: Alexander Schnitzler <>
Reviewed-by: Andreas Fernandez <>
Reviewed-by: Christian Eßl <>
Reviewed-by: Daniel Goerz <>

History

#1 Updated by Andreas Fernandez 4 months ago

  • Related to Bug #90788: Automatically use JsonView for json format added

#2 Updated by Andreas Fernandez 4 months ago

  • Description updated (diff)

#3 Updated by Daniel Goerz 4 months 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.

#4 Updated by Georg Ringer 4 months ago

  • Related to Task #87511: Deprecate $namespacesViewObjectNamePattern property added

#5 Updated by Georg Ringer 4 months ago

  • Status changed from New to Accepted

#6 Updated by Alexander Schnitzler 4 months 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:

  1. 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.
  1. 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.

#7 Updated by Gerrit Code Review 4 months 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

#8 Updated by Gerrit Code Review 4 months 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

#9 Updated by Anonymous 4 months ago

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

#10 Updated by Benni Mack 3 months ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF