Skip to content
Snippets Groups Projects
Select Git revision
  • 12.4
  • main default
  • 11.5
  • 13.3
  • l10n_main
  • 13.1
  • 13.0
  • l10n_12.4
  • 10.4
  • 12.1
  • 9.5
  • 11.3
  • master
  • 11.1
  • TYPO3_8-7
  • 10.2
  • 9.3
  • 9.2
  • TYPO3_7-6
  • TYPO3_7-0
  • v13.3.1
  • v12.4.21
  • v11.5.40
  • v13.3.0
  • v12.4.20
  • v12.4.19
  • v12.4.18
  • v11.5.39
  • v12.4.17
  • v13.2.1
  • v13.2.0
  • v12.4.16
  • v11.5.38
  • v13.1.1
  • v12.4.15
  • v11.5.37
  • v13.1.0
  • v12.4.14
  • v12.4.13
  • v12.4.12
40 results
Search by author
  • Any Author
  • Daniel Hürtgen Daniel Hürtgen higidi
  • Jenkins Jenkins jenkins
  • **** **** project_53_bot
3 authors
  1. Jul 16, 2019
  3. Jul 15, 2019
  5. Jul 14, 2019
  7. Jul 13, 2019
  9. Jul 12, 2019
  11. Jul 11, 2019
    • Benni Mack's avatar
      [!!!][TASK] Remove last usages of $GLOBALS[T3_VAR] · 0e7261ed
      Benni Mack authored 
      The global state array "T3_VAR" for keeping some legacy
functionality has been removed.

It is not in used by TYPO3 Core anymore, the last occurrence
for "injecting" some data into Indexed Search indexing
has been removed, as SingletonInterface, hooks and the possibility
to provide ones' own indexer for custom download extensions
should be used instead.

Resolves: #88660
Releases: master
Change-Id: I5a587271983c6bb4ae6709c0140e818c4c1eb572
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/61197


Tested-by: default avatarTYPO3com <noreply@typo3.com>
Tested-by: default avatarGeorg Ringer <georg.ringer@gmail.com>
Tested-by: default avatarSteffen Frese <steffenf14@gmail.com>
Tested-by: default avatarJörg Bösche <typo3@joergboesche.de>
Tested-by: default avatarBenni Mack <benni@typo3.org>
Reviewed-by: default avatarGeorg Ringer <georg.ringer@gmail.com>
Reviewed-by: default avatarSteffen Frese <steffenf14@gmail.com>
Reviewed-by: default avatarJörg Bösche <typo3@joergboesche.de>
Reviewed-by: default avatarBenni Mack <benni@typo3.org>
      0e7261ed
    • Benjamin Franzke's avatar
      [FEATURE] Add symfony dependency injection for core and extbase · 0cf8053e
      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: default avatarTobi Kretschmann <tobi@tobishome.de>
Tested-by: default avatarJörg Bösche <typo3@joergboesche.de>
Tested-by: default avatarAlexander Schnitzler <review.typo3.org@alexanderschnitzler.de>
Tested-by: default avatarTYPO3com <noreply@typo3.com>
Tested-by: default avatarBenjamin Franzke <bfr@qbus.de>
Reviewed-by: default avatarTobi Kretschmann <tobi@tobishome.de>
Reviewed-by: default avatarJörg Bösche <typo3@joergboesche.de>
Reviewed-by: default avatarAlexander Schnitzler <review.typo3.org@alexanderschnitzler.de>
Reviewed-by: default avatarBenjamin Franzke <bfr@qbus.de>
      0cf8053e
    • Georg Ringer's avatar
      [TASK] Use @import syntax in TypoScript example · 41fee66d
      Georg Ringer authored 
      The TypoScript which is created by the Install Tool should use the new
@import syntax.

Resolves: #88623
Releases: master, 9.5
Change-Id: I661cbe7bbc659c6ea804f4b131aa49fc7abca92a
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/61244


Tested-by: default avatarTYPO3com <noreply@typo3.com>
Tested-by: default avatarJosef Glatz <josefglatz@gmail.com>
Tested-by: default avatarJörg Bösche <typo3@joergboesche.de>
Tested-by: default avatarBjörn Jacob <bjoern.jacob@tritum.de>
Tested-by: default avatarSteffen Frese <steffenf14@gmail.com>
Tested-by: default avatarBenjamin Franzke <bfr@qbus.de>
Reviewed-by: default avatarJosef Glatz <josefglatz@gmail.com>
Reviewed-by: default avatarJörg Bösche <typo3@joergboesche.de>
Reviewed-by: default avatarBjörn Jacob <bjoern.jacob@tritum.de>
Reviewed-by: default avatarSteffen Frese <steffenf14@gmail.com>
Reviewed-by: default avatarDieter Porth <d.porth@neusta.de>
Reviewed-by: default avatarJulian Geils <j_geils@web.de>
Reviewed-by: default avatarBenjamin Franzke <bfr@qbus.de>
      41fee66d
    • Eric Chavaillaz's avatar
      [TASK] Add info to cards if installation is in composer mode · b89280f9
      Eric Chavaillaz authored 
      The cards "Rebuild PHP Autoload Information"
and "Update TYPO3 Core" show information about,
how to update and trigger the autoload in composer mode.

Resolves: #88434
Releases: master, 9.5
Change-Id: Ia7990d333bfaaef09a598b197cf3e461d5da6dd5
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/60812


Tested-by: default avatarEric Chavaillaz <eric@hemmer.ch>
Tested-by: default avatarTYPO3com <noreply@typo3.com>
Tested-by: default avatarJulian Geils <j_geils@web.de>
Tested-by: default avatarJörg Bösche <typo3@joergboesche.de>
Tested-by: default avatarFrank Naegler <frank.naegler@typo3.org>
Reviewed-by: default avatarEric Chavaillaz <eric@hemmer.ch>
Reviewed-by: default avatarJulian Geils <j_geils@web.de>
Reviewed-by: default avatarJörg Bösche <typo3@joergboesche.de>
Reviewed-by: default avatarFrank Naegler <frank.naegler@typo3.org>
      b89280f9
  13. Jul 10, 2019
  15. Jul 09, 2019
  17. Jul 08, 2019
  19. Jul 05, 2019