Project

General

Profile

Actions

Bug #85645

closed

CMS Fluid has hidden dependency on CMS Backend

Added by Claus Due over 5 years ago. Updated over 1 year ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Fluid
Target version:
-
Start date:
2018-07-25
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
9
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

It is technically possible to install `typo3/cms-fluid` without also installing `typo3/cms-backend`, but classes in `typo3/cms-fluid` in some cases depend on classes from `typo3/cms-backend` not just in runtime-executed code but also in documentation-specific code, e.g. using instances of `UriBuilder` in `f:uri.page`.

Doing such a limited install, for example when automating XSD schema generation, causes an error unless you explicitly add `typo3/cms-backend` as dependency.

Is an issue in all branches that use split tree. However, 8.7 does not use those third-party classes in the VH argument registration methods and so is safe to at least generate XSD schemas for. Hence, relevant TYPO3 version is set to 9.x.


Related issues 3 (0 open3 closed)

Related to TYPO3 Core - Task #85619: Streamline package interdependenciesClosed2018-07-23

Actions
Related to TYPO3 Core - Task #89519: Add missing dependencies to composer.json of extbaseClosedDaniel Siepmann2019-10-26

Actions
Related to TYPO3 Core - Bug #87508: composer.json doesn't list all (soft-)mandatory PHP extensionsClosed2019-01-21

Actions
Actions #1

Updated by Claus Due over 5 years ago

  • Category set to Fluid
Actions #2

Updated by Christian Kuhn over 5 years ago

Well, I think we added only "hard" dependencies until now to composer.json in our core extensions. For instance, if your extensions primary job is a backend module for editors, but it also comes with a tiny frontend plugin, we until now only set cms-backend as dependency, cms-frontend could be a suggest then.

This is similar for typo3/cms-fluid: Only a couple of VH's really need cms-backend, "most" of cms-fluid works well in practice if cms-backend is not there. However, since cms-backend is a hard requirement for a full typo3 anyway, it does not matter much. Thus, I'd be fine to add cms-backend to the require section of composer.json in cms-fluid. And I'd guess same goes for cms-frontend (needs check). It simply does not make much sense to use cms-fluid if not at least one of the two is loaded. In a project that does not need cms-frontend and cms-backend, one would probably go with standalone typo3fluid/fluid only in the first place and not with the typo3 cms part on top, even if cms-core is loaded, which then would act as a library only. And in fact cms-core is evolving to a library more and more since most controllers are in cms-frontend and especially in cms-backend and we're also slowly trying to push this further.

The only thing we could argue is whether we set cms-backend and maybe cms-frontend as suggest instead of require. That could be an advantage for frontend nodes that don't install cms-backend, or backend nodes that don't install cms-frontend. However, I'm not sure if the system is far enough already to do this in a good way already. But if we set require to cms-backend right now, it may later be turned into a suggest only for that reason.

Actions #3

Updated by Georg Ringer over 5 years ago

IMO the VH in ext:fluid which are BE related must be moved to EXT:backend and everything is fine.

Actions #4

Updated by Mathias Brodala over 5 years ago

  • Related to Task #85619: Streamline package interdependencies added
Actions #5

Updated by Georg Ringer about 4 years ago

  • Status changed from New to Accepted
Actions #6

Updated by Georg Ringer about 4 years ago

  • Related to Task #89519: Add missing dependencies to composer.json of extbase added
Actions #7

Updated by Georg Ringer about 4 years ago

  • Related to Bug #87508: composer.json doesn't list all (soft-)mandatory PHP extensions added
Actions #8

Updated by Georg Ringer over 1 year ago

  • Status changed from Accepted to Closed

even though this issue is valid I am closing this issue after talking to lolli. just moving the VH itself around doesn't help much as there are far more dependencies inside the VHs to other extensions like extbase.

Actions

Also available in: Atom PDF