- Sep 11, 2024
-
-
Simon Praetorius authored
This patch enables a template processor included in Fluid 4 for all Fluid instances in the Core. The template processor strips `<f:comment>` tags from Fluid template strings before the parsing starts. This prevents Fluid errors when invalid Fluid code is used inside `<f:comment>`. Original change in Fluid: https://github.com/TYPO3/Fluid/commit/faad81a9f5d991d688e1d4c673e0d7aaf41a7e94 Resolves: #104904 Releases: main Change-Id: Ieebb60ee21ae9f8d6f168e75b9fd22a7103a5f6a Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/86012 Reviewed-by:
Guido Schmechel <guido.schmechel@brandung.de> Tested-by:
Andreas Kienast <a.fernandez@scripting-base.de> Tested-by:
Stefan Bürk <stefan@buerk.tech> Tested-by:
Simon Praetorius <simon@praetorius.me> Reviewed-by:
Mathias Brodala <mbrodala@pagemachine.de> Reviewed-by:
Benni Mack <benni@typo3.org> Reviewed-by:
core-ci <typo3@b13.com>
-
- Jun 05, 2023
-
-
Simon Praetorius authored
With TYPO3 11 it was possible to use ViewHelpers from composer libraries that aren't TYPO3 extensions and thus don't use Symfony dependency injection. With the removal of objectManager, this doesn't work anymore in TYPO3 12 because the dependency injection can only instantiate ViewHelper classes that are defined as public services explicitly. This change reintroduces that functionality by falling back to "new" if the class exists but isn't registered as a service. Fluid standalone uses the same method to instantiate a ViewHelper. Resolves: #100785 Releases: main, 12.4 Change-Id: I495e006fa15eb815fb3734b4c73361821869f4ad Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/78917 Tested-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Tested-by:
-
- Mar 18, 2023
-
-
Stefan Froemken authored
If StandaloneView was instanciated as constructor argument you will now get a non shared object. Resolves: #99172 Releases: main Change-Id: I8dc72774eedfb7fd2b24e0106bb8e1ec8ecf2807 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/78149 Tested-by:
Nikita Hovratov <nikita.h@live.de> Tested-by:
Oliver Klee <typo3-coding@oliverklee.de> Reviewed-by:
-
- Sep 15, 2022
-
-
Susanne Moog authored
This change allows the injection of the fluid RenderingContextFactory while disallowing the direct injection of the RenderingContext. Resolves: #98351 Related: #96271 Releases: main Change-Id: Ia1ec782581dfc56fca86cf62cb506624b5f80bcc Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75733 Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
Benjamin Franzke <bfr@qbus.de> Reviewed-by:
Oliver Hader <oliver.hader@typo3.org> Reviewed-by:
-
- Dec 07, 2021
-
-
Christian Kuhn authored
Removes a Services.yaml entry from ext:fluid to enforce using RenderingContextFactory->create(). Change-Id: Ibd02cc394b99cb72856c3828b13a06e244544576 Resolves: #96271 Related: #94285 Releases: main Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/72541 Tested-by:
-
Christian Kuhn authored
We missed this with #96256 - StandaloneView is autowiring aware now. Resolves: #96270 Related: #96256 Releases: main Change-Id: Ib4d3ca309296e624dc608c2145247fe766a084ec Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/72540 Tested-by:
-
- Dec 01, 2021
-
-
Christian Kuhn authored
Needs a styleguide raise composer u typo3/cms-styleguide Resolves: #96174 Related: #94991 Related: #95005 Related: #95164 Related: #95222 Related: #95003 Change-Id: Iba811bf554a5ad575080950c221cc5185281435d Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/72436 Tested-by:
Oliver Bartsch <bo@cedev.de> Tested-by:
-
- Aug 26, 2021
-
-
Christian Kuhn authored
Handling ContentObjectRenderer instances is messy, especially within extbase: The ConfigurationManager is a stateful singleton since it depends on current ContentObjectRenderer being set within frontend. The extbase Bootstrap takes care of setting the current cObj. ConfigurationManager is also misused (ext:form) to "park" the current cObj for later retrieval. This needs to be tackled with a dedicated patch. This is worse with fluid StandaloneView, which accepts cObj as constructor argument to update ConfigurationManager state. Funnily, this optional constructor argument is never hand over in core. Additionally, extbase usually does not use StandaloneView, but fluid's TemplateView instead. The patch deprecates the constructor argument of fluid StandaloneView to avoid a dependency from StandaloneView to extbase. Resolves: #94959 Releases: master Change-Id: I605d4bb1133a30daf418eb418f2d5502d981b4c1 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70721 Tested-by:
Jochen <rothjochen@gmail.com> Tested-by:
-
- Jun 17, 2021
-
-
Christian Kuhn authored
Finish the ObjectManager usages in ext:fluid. With #94285 we made the ViewHelperResolver a singleton service, which is not ok since it holds state: Namespaces are added at runtime and they additionally depend on request. The solution is similar to RenderingContext from #94285 though: Have a factory to create fresh instances for each parsing cycle for this failsafe mode enabled class. View helper instance prototypes itself are then retrieved using GeneralUtility::makeInstance(). Resolves: #94292 Related: #94285 Related: #90803 Releases: master Change-Id: I08018b57e3bd5b293be999d7c5415578604c7897 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69419 Tested-by:
-
- Jun 09, 2021
-
-
Christian Kuhn authored
RenderingContext is a good case for a class that creates "arbitrary" objects: The PreProcessor class names are retrieved from global configuration in order to be instantiated. This initialization is moved into a (install tool mode compatible) factory in order to transform ObjectManager into a fallback layer for PreProcessors that are not defined in the newer PSR container. Therefore $container->has() is used prior to $container->get(), in order to fallback to ObjectManager for objects that can't be retrieved – due to missing configuration – via ContainerInterface yet. Resolves: #94285 Related: #90803 Releases: master Change-Id: I3fd1751b8580de7c8307e9b84da38e1551c2c622 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69412 Tested-by:
-
- Sep 11, 2019
-
-
Markus Poerschke authored
Configure services for each service instance. The service names of the cache frontends will follow this name pattern: "cache.[NAME OF CONFIGURATION]". E.g. the l10n cache frontend will be added as a service "cache.l10n". (One exception has been made for the workspaces_cache, which is names cache.workspaces) Resolves: #89054 Releases: master Change-Id: I5e328503ee0399f20ea37d766b8a80cd6d9930fc Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/61588 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Susanne Moog <look@susi.dev> Reviewed-by:
Markus Poerschke <markus@poerschke.nrw> Reviewed-by:
-
- Jul 11, 2019
-
-
Benjamin Franzke authored
This feature is a combined approach using two containers/concepts: 1) symfony/dependency-injection (now exposed as official TYPO3 API): Supports: autoconfiguration, autowiring using Service.{yaml,php} files 2) service providers (fork of the experimental interfaces in container-interop/service-provider, sometimes called PSR-11+) Supports: factory-style configuration using plain php code provided for internal use and possible future public use. 1) Symfony dependency injection is provided to be used by extensions and throughout the TYPO3 core for (auto)wiring of services (classes). Extensions can control symfony's dependency injection use a file located in Configuration/Services.yaml, if they need more flexibility they may also use Configuration/Services.php which can use symfony's ContainerConfigurator or ContainerBuilder. 2) Service providers are used (within TYPO3 core) to provide dependency injection for services used in the install tool which require failsafe boot. This is based on container-interop/service-provider. container-interop/service-provider is supposed to become a PSR but is still marked experimental, therefore this commit adds an implementation to TYPO3 provided for internal use only – it is not public API. We do still include it (as @interal fork) right now, to adapt to this upcoming PSR from the very beginning, in order to actually push the development of this proposal forward. Service providers in failsafe mode are consumed by a simplistic, non-compiled container. Symfony's container is too slow when running uncached (as the compilation, recursive directory lookups and autowiring needs to be performed on every invocation). We do not want caching for recovery maintenance tasks which would not be able to recover from scenarios with broken caches. Services that are configured through service providers, are both available in the non compiled install tool container and in the symfony container. They do *not* need to be defined twice. The two "worlds" are bridged using a ServiceProviderCompilerPass which creates symfony DI definitions from service-provider factories. The code is a derivative of the code from the (outdated) symfony bundle thecodingmachine/service-provider-bridge-bundle. Features -------- * inject* methods are now supported for all classes (not just Extbase) It is suggested to use constructor based injection, this feature is available to provide maximum compatibility to the old Extbase DI. * Autoconfiguration based on interface implementation. (current) autoconfigured interface are: SingletonInterface, MiddlewareInterface, RequestHandlerInterface, LoggerAwareInterface, ControllerInterface, ViewHelperInterface (we expect more to follow in subsequent commits) Included adaptions ------------------ In order to demonstrate and to be able to verify the features of this patch, some classes are adapted to use or support dependency injection: * RedirectHandler/RedirectService autowired/autoconfigured * Application classes and their dependencies are manually wired in service providers. This is required as the application runs in fail- safe mode when there is no configuration available (first install) * MiddlewareStack is composed in service providers and injected as a RequestHandler into the Http\Application classes (in order to prevent injecting the Container, which would be an anti pattern). * Middleware configuration is treated as service (like a registry), and retrieval is provided through service providers (the service providers default to the existing middleware configuration format) * The Middleware dispatcher now first tries to retrieve classes from the PSR-11 container, falling back to makeInstance if not available * Dependency Injection using symfony for all core Extbase Controllers * A Services.yaml is added for each core extension which contains classes that are used in frontend/backend context * A LateBoot service is added for install tool DI vs ext_localconf – loading order, legacy makeInstance support ---------------------------------------------------------------- Dependency Injection containers solve most of the tasks that ext_localconf.php and GeneralUtility::makeInstance solve for Singletons: Service configuration and instance management. (Symfony) DI could therefore be used to replace both in the long run. Both are doing similar tasks when talking about Singletons: They create and configure services that are stored and shared in a central memory storage (container for DI, GU::$singletonInstances for our legacy TYPO3 case). That means they both actually conflict right now – in terms of: Who is responsible for creating a class? We've made a decision to connect these both: GeneralUtility::makeInstance will offload instantiation to the Container if the class is a) available and b) no runtime constructor arguments have been passed to makeInstance (which symfony DI doesn't support). The DI container itself does provides backwards compatibility to XCLASSES and class aliases use a new internal helper method makeInstanceForDi. ext_localconf's main design flaw is the mixture of initialization and configuration composition without assurance that all configuration is available before a configuration-dependent class is instantiated. Proper DI first reads all configuration and then performs all service injections on demand and pre calculated using a dependency tree – and therefore always in proper sequence. What we *don't* want (+ reasons) ------------------------------- * Symfony Bundles pro: provide a defined way for container configuration) con: Requires the Symfony HTTP kernel which is not compatible with PSR7 * Usage of Symfony\DependencyInjection\ExtensionInterface con: It is not useful as it cannot add new compiler passes * Handling of prototypes that need dependency injection *and* a way to to get custom constructor arguments passed (individual per class) While symfony DI can handle prototypes (called 'shared: false'), it does not support passing constructor arguments like the Extbase object manager does. We'll advocate to using a factory pattern for those prototypes instead. * Circular dependencies: This is not supported by symfony DI and isn't possible with service providers either Future changes (left out for brevity) ------------------------------------- * (cli) Build tool to warmup DI cache/state during deployment * Adaptions to (all) core dispatchers to prefer a PSR-11 container over GeneralUtility::makeInstance Dependency changes ------------------ composer require symfony/dependency-injection:^4.1 symfony/config:^4.1 Releases: master Resolves: #88689 Resolves: #84112 Change-Id: I8efd817066b528a5953c56fdd027cb94b2bb8eb3 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/58255 Tested-by:Tobi Kretschmann <tobi@tobishome.de> Tested-by:
Jörg Bösche <typo3@joergboesche.de> Tested-by:
Alexander Schnitzler <review.typo3.org@alexanderschnitzler.de> Tested-by:
-
