This project is mirrored from Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
  1. 09 Jul, 2021 1 commit
  2. 07 Sep, 2020 1 commit
  3. 04 Sep, 2020 1 commit
  4. 30 May, 2020 1 commit
  5. 17 Apr, 2020 2 commits
    • Benjamin Franzke's avatar
      [TASK] Inject singletons used by EXT:install in service providers · c020e9ba
      Benjamin Franzke authored and Susanne Moog's avatar Susanne Moog committed
      This will allow both, dependency injection for these services (manually
      wired in service providers), and usage in install/maintenance tool
      (where we do not use the caching symfony container for basic tasks).
      The move to DI is possible thanks to the failsafe container and the
      service providers which can fed the failsafe container with service
      factories. These factories are used to wire services manually.
       * The definition in a service provider means we are required to use
         manual wiring and are forced to define the dependencies in the service
         provider when we add new depenencies to services that are being used
         by the install..
         With that approach we can assure that we do not accidentally add new
         dependencies to services which would become available in symfony DI due
         to autowiring, but would be unavailable in the install tool.
       * The install tool has operations that require a booted symfony
         container which is provided by the LateBootService. Services that
         are used in that mode do not need to be listed in service providers.
         Therefore we do only add core services to service providers if they
         are used in a context without a fully booted symfony DI container.
       * GLOBALS['LANG'] mocks in Core\Tests\Unit\DataHandling\DataHandlerTest
         have been removed as the code under test does no longer use
         $GLOBALS['LANG']->csConvObj->substr() but mb_substr. The test had been
         introduced with #68602 but the tested code was adapted in #78670.
       * We got a bit ugly constructs now, where a unit(!) test previously used
           $GLOBALS['LANG'] = new LanguageService();
         …we now have to encode the dependency structure:
           $GLOBALS['LANG'] = new LanguageService(new Locales,
               new LocalizationFactory(
                   new LanguageStore,
         This isn't nice, but this change reveals that the affected unit tests
         should either be adapted, removed or be moved to a functional test.
         Such adaption are out of scope for this change.
       * loadExtLocalconfDatabaseAndExtTables() is removed from the
         EXT:install AbstractController, as it hides the implicit dependency
         to LateBootService
       * Nullable constructor arguments have been changed to be non-nullable
         whenever possible. That results in some more test adaptions, but
         reveals, where unit tests rely on implicit dependencies and offers
         better readability and less possible codepaths.
      Releases: master
      Resolves: #89892
      Resolves: #89891
      Change-Id: Ib72d6440f81b2c0d05279e8768697c3b48aecfe4
      Tested-by: default avatarTYPO3com <>
      Tested-by: Andreas Fernandez's avatarAndreas Fernandez <>
      Tested-by: Susanne Moog's avatarSusanne Moog <>
      Reviewed-by: Andreas Fernandez's avatarAndreas Fernandez <>
      Reviewed-by: Susanne Moog's avatarSusanne Moog <>
    • Benjamin Franzke's avatar
      [BUGFIX] Provide symfony container in install tool "Check TCA" action · d8dda294
      Benjamin Franzke authored and Andreas Fernandez's avatar Andreas Fernandez committed
      A booted symfony container is needed as ext_localconf.php is
      loaded since #89713 for the "Check TCA" action.
      ext_localconf.php files may depend on a fully-booted
      symfony container, therefore we need to provide it in this
      case as well – or ext_localconf.php loading may fail.
      Adapt the LateBootService to allow to reset to a
      previously backuped container (even if it has been
      reset in the meantime by another method).
      Currently affected extensions were EXT:news before commit
      ac0cb20c (which added a workaround for this case).
      Thus the bugfix can be verified against the parent of that commit:
      Releases: master
      Resolves: #91073
      Related: #89713
      Change-Id: Iaceb5efae26c1ae2e08e0db31ff2c223cc803ce7
      Tested-by: default avatarTYPO3com <>
      Tested-by: default avatarJosef Glatz <>
      Tested-by: Georg Ringer's avatarGeorg Ringer <>
      Tested-by: Andreas Fernandez's avatarAndreas Fernandez <>
      Reviewed-by: Georg Ringer's avatarGeorg Ringer <>
      Reviewed-by: Andreas Fernandez's avatarAndreas Fernandez <>
  6. 15 Apr, 2020 1 commit
  7. 14 Apr, 2020 1 commit
  8. 13 Apr, 2020 1 commit
  9. 11 Apr, 2020 1 commit
  10. 25 Mar, 2020 2 commits
  11. 20 Mar, 2020 1 commit
  12. 11 Mar, 2020 1 commit
  13. 19 Dec, 2019 2 commits
  14. 18 Dec, 2019 1 commit
  15. 29 Nov, 2019 1 commit
    • Benjamin Franzke's avatar
      [BUGFIX] Provide global Symfony container instance in upgrade wizards · 5601673d
      Benjamin Franzke authored and Susanne Moog's avatar Susanne Moog committed
      Upgrade wizars may contain legacy code that requires services
      using makeInstance. As makeInstance needs to use the PSR-11 container
      for services that require dependency injection, we need to provide
      the global container intance during upgrade wizard execution.
      Also ensure that only *one* (singleton) PackageManager instance is used:
      ProviderConfigurationLoader used to create a second PackageManager
      instance. It passed a constructor argument which caused GU::makeInstance
      to bypass the symfony (PSR-11) container and to create a new instance
      (on its own). This new instance was then cached as singleton instance and
      all subsequent makeInstance calls returned this instance instead of the
      global instance. Therefore we now ensure that new singleton instances
      will not be cached if the singleton is known by the PSR-11 container.
      This inconsistency caused the Typo3DbExtractionUpdate to fail because
      some codepaths used one PackageManager instance (through DI) and some
      codepaths another instance (through makeInstance).
      Change-Id: I947310d1c2e46f7ded6399ad48d94efa9854f347
      Releases: master
      Resolves: #89504
      Tested-by: default avatarTYPO3com <>
      Tested-by: Benni Mack's avatarBenni Mack <>
      Tested-by: Susanne Moog's avatarSusanne Moog <>
      Reviewed-by: Benni Mack's avatarBenni Mack <>
      Reviewed-by: default avatarJörg Bösche <>
      Reviewed-by: Susanne Moog's avatarSusanne Moog <>
  16. 11 Jul, 2019 1 commit
    • 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}
      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
       * 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
      Tested-by: default avatarTobi Kretschmann <>
      Tested-by: default avatarJörg Bösche <>
      Tested-by: default avatarAlexander Schnitzler <>
      Tested-by: default avatarTYPO3com <>
      Tested-by: Benjamin Franzke's avatarBenjamin Franzke <>
      Reviewed-by: default avatarTobi Kretschmann <>
      Reviewed-by: default avatarJörg Bösche <>
      Reviewed-by: default avatarAlexander Schnitzler <>
      Reviewed-by: Benjamin Franzke's avatarBenjamin Franzke <>
  17. 28 Jun, 2019 1 commit
  18. 18 Jan, 2019 1 commit
  19. 06 Jan, 2019 1 commit
  20. 01 Oct, 2018 1 commit
  21. 29 Sep, 2018 1 commit
  22. 28 Sep, 2018 1 commit
  23. 27 Sep, 2018 1 commit
  24. 20 Sep, 2018 1 commit
  25. 19 Sep, 2018 2 commits
  26. 18 Sep, 2018 1 commit
  27. 07 Sep, 2018 1 commit
  28. 02 Sep, 2018 2 commits
  29. 29 Jul, 2018 1 commit
  30. 06 Jul, 2018 1 commit
  31. 15 Jun, 2018 1 commit
  32. 20 Apr, 2018 1 commit
  33. 04 Apr, 2018 1 commit
  34. 07 Mar, 2018 1 commit
    • Benni Mack's avatar
      [FEATURE] Introduce an Environment API class · f10f551b
      Benni Mack authored and Susanne Moog's avatar Susanne Moog committed
      A new class Environment is added, which is initialized right at the very
      beginning of any TYPO3-based request.
      The class contains a static list of properties commonly used throughout the
      core to access paths, constants or global variables. The class also contains
      methods that are relevant for ALL kind of PHP requests, CLI and web requests.
      In order to avoid constants, and global variables, this is centralized in one
      place, which allows to "re-define" values for testing purposes, making functional
      tests a lot simpler.
      This would better be stored in a dependency injection container and injected
      as dependency/parameter into the respective classes that need the information.
      We're not at that point to use dependency injection for every class, therefore
      this class provides a static interface as a long-term interim solution.
      Additionally, it adds a new functionality, basically finally allowing to move
      code outside of the PATH_site constant with a proper API.
      If the environment variable "TYPO3_PATH_APP" is set, this acts as a root path
      for the project, which can be the same as PATH_site, or (usually) one level
      All typical new composer-based installations have this folder structure set up
      automatically. Non-composer mode installations can set this environment variable
      to make TYPO3 aware of non-public-accessable folders.
      The following changes apply (with further patches):
      - When TYPO3_PATH_APP is set, all logs / sessions / cache files are moved into $PROJECT_ROOT/var/.
      - Same applies to typo3conf/l10n/, effectively moving this into a semi-writable
      place, the same place where logs should be placed.
      - LocalConfiguration.php, PackageStates.php and AdditionalConfiguration.php
        are now located at $PROJECT_ROOT/config/
      The folder typo3conf then only contains code related to extensions.
      The long-term goal until 9 LTS is that TYPO3 Core does not use any constants
      anymore, which have been superseded by this class right now.
      Resolves: #84153
      Releases: master
      Change-Id: I7ca35f752493d7e0d1c21c83a9ffbfb6a40eb463
      Reviewed-by: Benjamin Franzke's avatarBenjamin Franzke <>
      Tested-by: Benjamin Franzke's avatarBenjamin Franzke <>
      Tested-by: default avatarTYPO3com <>
      Reviewed-by: default avatarMathias Schreiber <>
      Tested-by: default avatarMathias Schreiber <>
      Reviewed-by: Susanne Moog's avatarSusanne Moog <>
      Tested-by: Susanne Moog's avatarSusanne Moog <>
  35. 14 Feb, 2018 1 commit