Bug #85645
closedCMS Fluid has hidden dependency on CMS Backend
0%
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.
Updated by Christian Kuhn over 6 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.
Updated by Georg Ringer over 6 years ago
IMO the VH in ext:fluid which are BE related must be moved to EXT:backend and everything is fine.
Updated by Mathias Brodala over 6 years ago
- Related to Task #85619: Streamline package interdependencies added
Updated by Georg Ringer over 4 years ago
- Related to Task #89519: Add missing dependencies to composer.json of extbase added
Updated by Georg Ringer over 4 years ago
- Related to Bug #87508: composer.json doesn't list all (soft-)mandatory PHP extensions added
Updated by Georg Ringer over 2 years 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.