1. 28 Jul, 2020 1 commit
  2. 07 Jul, 2020 2 commits
  3. 09 Jun, 2020 2 commits
  4. 19 May, 2020 2 commits
  5. 12 May, 2020 2 commits
  6. 28 Apr, 2020 2 commits
  7. 21 Apr, 2020 2 commits
  8. 04 Mar, 2020 1 commit
  9. 25 Feb, 2020 2 commits
  10. 03 Dec, 2019 2 commits
  11. 21 Nov, 2019 1 commit
    • Benni Mack's avatar
      [TASK] Update symfony dependencies to 4.4 or 5.0 · f20a7aae
      Benni Mack authored
      TYPO3 Core v10 should rely on Symfony 4.4 (LTS release)
      and add support for 5.0 automatically.
      
      Symfony 4.4 made breaking changes to the Mailer and Mime components
      which now need adaptions.
      
      Used composer command:
      
      composer req "symfony/config":"^4.4 || ^5.0" \
      "symfony/console":"^4.4 || ^5.0" \
      "symfony/dependency-injection":"^4.4 || ^5.0" \
      "symfony/expression-language":"^4.4 || ^5.0" \
      "symfony/finder":"^4.4 || ^5.0" \
      "symfony/mailer":"^4.4 || ^5.0" \
      "symfony/mime":"^4.4 || ^5.0" \
      "symfony/property-access":"^4.4 || ^5.0" \
      "symfony/property-info":"^4.4 || ^5.0" \
      "symfony/routing":"^4.4 || ^5.0" \
      "symfony/yaml":"^4.4 || ^5.0" --update-with-all-dependencies
      
      Loading composer repositories with package information
      Updating dependencies (including require-dev)
      Package operations: 0 installs, 27 updates, 0 removals
        - Updating symfony/polyfill-ctype (v1.11.0 => v1.12.0)
        - Updating symfony/filesystem (v4.3.1 => v4.4.0)
        - Updating symfony/config (v4.3.2 => v4.4.0)
        - Updating symfony/service-contracts (v1.1.2 => v1.1.8)
        - Updating symfony/polyfill-php73 (v1.11.0 => v1.12.0)
        - Updating symfony/polyfill-mbstring (v1.11.0 => v1.12.0)
        - Updating symfony/console (v4.3.1 => v4.4.0)
        - Updating symfony/dependency-injection (v4.3.2 => v4.4.0)
        - Updating symfony/var-exporter (v4.3.1 => v4.4.0)
        - Updating symfony/cache-contracts (v1.1.1 => v1.1.7)
        - Updating psr/log (1.0.2 => 1.1.2)
        - Updating symfony/cache (v4.3.1 => v4.4.0)
        - Updating symfony/expression-language (v4.3.1 => v4.4.0)
        - Updating symfony/finder (v4.3.3 => v4.4.0)
        - Updating symfony/polyfill-php72 (v1.11.0 => v1.12.0)
        - Updating symfony/polyfill-intl-idn (v1.11.0 => v1.12.0)
        - Updating symfony/mime (v4.3.2 => v4.4.0)
        - Updating symfony/event-dispatcher-contracts (v1.1.1 => v1.1.7)
        - Updating symfony/event-dispatcher (v4.3.1 => v4.4.0)
        - Updating doctrine/lexer (v1.0.1 => 1.2.0)
        - Updating egulias/email-validator (2.1.9 => 2.1.11)
        - Updating symfony/mailer (v4.3.2 => v4.4.0)
        - Updating symfony/inflector (v4.3.1 => v4.4.0)
        - Updating symfony/property-access (v4.3.1 => v4.4.0)
        - Updating symfony/property-info (v4.3.1 => v4.4.0)
        - Updating symfony/routing (v4.3.1 => v4.4.0)
        - Updating symfony/yaml (v4.3.1 => v4.4.0)
      
      Resolves: #89721
      Releases: master
      Change-Id: I834a79e3880b3a7a95429c2fe052657e21599ec7
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/62354
      
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Tested-by: Susanne Moog's avatarSusanne Moog <look@susi.dev>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Reviewed-by: Susanne Moog's avatarSusanne Moog <look@susi.dev>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      f20a7aae
  12. 19 Nov, 2019 1 commit
  13. 11 Oct, 2019 1 commit
  14. 01 Oct, 2019 2 commits
  15. 13 Aug, 2019 1 commit
  16. 05 Aug, 2019 1 commit
  17. 23 Jul, 2019 1 commit
  18. 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}
         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: Benjamin Franzke's 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: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
      0cf8053e
  19. 14 Dec, 2018 3 commits
  20. 11 Dec, 2018 2 commits
  21. 30 Oct, 2018 2 commits
  22. 02 Oct, 2018 2 commits
  23. 04 Sep, 2018 2 commits
  24. 11 Aug, 2018 1 commit
    • Benni Mack's avatar
      [FEATURE] Use symfony/routing for Site Resolving · a557d88d
      Benni Mack authored and Andreas Wolf's avatar Andreas Wolf committed
      Use symfony/router 4.1 for resolving a site based on the
      current request.
      
      This actually removes some simple resolving built previously
      by myself, which was stupid code to detect a site base.
      
      With the symfony/routing component, it is now possible to
      have site base prefixes without a scheme (just the domain)
      and allow to handle both prefixes. It is also possible to
      just add "/site1" and "/site2" as base for domains as
      well, allowing to listen to any incoming domain.
      
      As this Routing component will be used for further
      page-based routing, the introduced symfony-specific
      code might change and encapsulated in other places.
      
      With this patch we now require symfony 4.1 components
      or higher, as symfony/routing became fast with 4.1,
      and symfony/routing 4.1 is incompatible with various 3.x
      components we use. Composer-based installations might
      not be able to upgrade, if they have a strong
      dependency on a lower symfony version.
      
      The composer command used:
          composer req symfony/console:^4.1 symfony/expression-language:^4.1 \
          symfony/finder:^4.1 symfony/routing:^4.1 symfony/yaml:^4.1 \
          --update-with-dependencies
      
      Resolves: #85719
      Resolves: #85165
      Releases: master
      Change-Id: If21ff3581552ca98af28739a76236a160508f16d
      Reviewed-on: https://review.typo3.org/57851
      
      
      Tested-by: default avatarTYPO3com <no-reply@typo3.com>
      Tested-by: Daniel Siepmann's avatarDaniel Siepmann <daniel.siepmann@typo3.org>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Oliver Hader's avatarOliver Hader <oliver.hader@typo3.org>
      Reviewed-by: Andreas Wolf's avatarAndreas Wolf <andreas.wolf@typo3.org>
      Tested-by: Andreas Wolf's avatarAndreas Wolf <andreas.wolf@typo3.org>
      a557d88d
  25. 11 Jun, 2018 1 commit