This project is mirrored from https://git.typo3.org/typo3/typo3.git. 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. 06 Jan, 2021 1 commit
  2. 17 Dec, 2020 1 commit
    • Oliver Bartsch's avatar
      [!!!][TASK] Rework shortcut PHP API functionality · e4833fda
      Oliver Bartsch authored and Christian Kuhn's avatar Christian Kuhn committed
      To be able to introduce URL rewrites for the backend,
      the internal handling and registration of the shortcut
      PHP API is reworked.
      
      The Shortcut PHP API previously has the full URL of
      the shortcut target stored in the database. This lead
      to many problems such as shortcuts got invalid as soon
      as their target module changed its route path. Furthermore,
      this required unnecessary functionality like replacing
      tokens on URL creation.
      
      Therefore, a shortcut record now stores only the route
      identifier of the module to link to and necessary arguments
      in two new database columns. A upgrade wizard is in place
      to migrate existing data.
      
      The rework also required to deprecate some methods in
      the ShortcutButton API and a parameter signature change
      of the JavaScript function `TYPO3.ShortcutMenu.createShortcut()`
      which performs the AJAX call to create new shortcuts.
      
      Side effect, this also deprecated the last remains of
      xMOD_alt_doc.php in the core.
      
      Resolves: #93093
      Releases: master
      Change-Id: I07666a299651e4953b4adf2987fcd3469094c288
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67143
      
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Daniel Goerz's avatarDaniel Goerz <daniel.goerz@posteo.de>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Daniel Goerz's avatarDaniel Goerz <daniel.goerz@posteo.de>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      e4833fda
  3. 01 Dec, 2020 1 commit
    • Sebastian Michaelsen's avatar
      [FEATURE] Introduce API for the configuration module · ce6d4902
      Sebastian Michaelsen authored and Christian Kuhn's avatar Christian Kuhn committed
      Instead of having a hardcoded list of "trees" available
      in the configuration module a new API is introduced and
      all existing tree functionalities are moved into separate
      provider classes to use the new API.
      
      Extension authors are now able to add their own providers
      to expose their custom configuration in the module. It's
      even possible now to disable existing providers shipped
      by core or any third-party extension.
      
      Each provider is therefore registered in the `Services.yaml`
      of the specific extension by defining the provider class
      to be used and adding the `lowlevel.configuration.module.provider`
      tag with at least the unique `identifier` attribute.
      
      All providers must then implement the new `ProviderInterface`
      to ensure the module can acquire the necessary data to
      display the tree and the module menu.
      
      The registration also provides a ordering / sorting
      functionality using the DependencyOrderingService.
      
      Resolves: #92929
      Releases: master
      Change-Id: I94e81e4b68ff9402444dca9449d251302380fd9f
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66899
      
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      ce6d4902
  4. 01 Nov, 2020 1 commit
    • Benni Mack's avatar
      [TASK] Use Symfony Routing for Backend Routing · 73bcf9a1
      Benni Mack authored and Georg Ringer's avatar Georg Ringer committed
      This is a pre-cursor for enhancing Backend Routing in general.
      
      This change implements Symfony Routing for Backend
      Routes (currently based on the "route" GET/POST argument)
      internally to make use of their compiled routes later-on.
      
      This was previously done in a simplified version where only
      the path was checked against, and most Symfony features
      were not in use, which we still don't use yet, but more can now
      be added.
      
      When Backend Routing was added in TYPO3 v7, the API
      was heavily influenced by Symfony but we did not have
      a lot of experience yet, which we benefitted in TYPO3 v9+
      for Frontend Routing.
      
      With this experience (and with PSR-15) we can gradually
      move to a more streamlined and faster API.
      
      The proposed solution still works as expected with &route
      GET parameters, but opens up the door for flexible Route arguments.
      
      Resolves: #92723
      Releases: master
      Change-Id: I48475fcb3cc15f99cc102dac36ae15bca9f3032e
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66316
      
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Tested-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      73bcf9a1
  5. 05 Sep, 2020 1 commit
    • Christian Kuhn's avatar
      [!!!][TASK] Refactor create bookmark handling · 5be7b805
      Christian Kuhn authored and Anja Leichsenring's avatar Anja Leichsenring committed
      The backend shortcut / bookmark handlig API was designed to
      hand over relevant get/post arguments as key only (eg. 'id').
      The underlying code then pulled values from GET/POST or from
      SOBE->MOD_SETTINGS. This is ugly, there shouldn't be such
      magic: Only controllers know relevant keys and values, so
      it should hand them over directly to the shortcut API.
      
      The patch changes this:
      * Old and unused ViewHelper f:be.buttons.shortcut is deprecated.
      * ViewHelper be:moduleLayout.button.shortcutButton deprecates
        argument 'getVars' and adds new argument 'arguments'.
      * Class ShortcutButton has a new setter 'setArguments' that
        accepts all relevant argument key/value pairs to create a
        shortcut. Existing get/set related methods are deprecated.
      * Helper methods 'makeShortcutIcon' and 'makeShortcutUrl' of
        class ModuleTemplate are deprecated and implemented in class
        ShortcutButton directly.
      * All core usages are adapted to new API.
      * Shortcut handling was the last core usage of SOBE, so last
        $GLOBALS['SOBE'] = $this assignments can be finally removed.
      
      Impact:
      * Shortcuts to modules not directly reachable via main menu
        do not work due to limits of the module registration API. An
        example is the 'create multiple pages' controller. This issue
        exists before the patch, affected controllers no longer render
        a shortcut button for now.
      * The old code usually added the 'route' argument twice for shortcuts.
        This has been resolved. As a side effect, the comparison if a
        shortcuts exists (yellow shortcut icon) fails currently for existing
        shortcuts when the patch is applied: The comparison relies on
        direct string equality since shortcuts always store the final url in
        the database. This storage strategy should be changed with another
        patch that will solve the 'no yellow icon' issue at the same time.
      
      Change-Id: I3ccd2b8f6adab8e7780c5f9911fdea013ccfa99b
      Resolves: #92132
      Releases: master
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65503
      
      
      Tested-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Reviewed-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      5be7b805
  6. 17 Apr, 2020 1 commit
  7. 15 Apr, 2020 1 commit
  8. 14 Apr, 2020 1 commit
  9. 13 Apr, 2020 1 commit
  10. 27 Mar, 2020 1 commit
  11. 16 Jan, 2020 1 commit
  12. 29 Nov, 2019 1 commit
  13. 16 Jul, 2019 1 commit
  14. 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
  15. 16 May, 2019 1 commit
  16. 19 Dec, 2018 1 commit
  17. 01 Oct, 2018 1 commit
  18. 30 Sep, 2018 1 commit
  19. 27 Sep, 2018 1 commit
  20. 02 Sep, 2018 1 commit
  21. 25 Jul, 2018 1 commit
  22. 30 May, 2018 1 commit
  23. 15 May, 2018 1 commit
  24. 16 Feb, 2018 1 commit
  25. 14 Feb, 2018 1 commit
  26. 13 Jan, 2018 1 commit
  27. 09 Dec, 2017 1 commit
  28. 30 Nov, 2017 1 commit
  29. 13 Oct, 2017 1 commit
  30. 12 Oct, 2017 3 commits
  31. 25 Apr, 2017 1 commit
  32. 28 Mar, 2017 1 commit
    • Wouter Wolters's avatar
      [TASK] Streamline return tags in phpdocs · eb049dba
      Wouter Wolters authored and Benni Mack's avatar Benni Mack committed
      The TYPO3 Core currently has no guidline how to handle phpdoc
      comments regarding @return annoations related to "void" and "null".
      
      In practice, these annotations have no additional value if no additional
      documentation is given.
      
      With this change, the php-cs-fixer will remove any unnecessary linebreaks
      within the comments above the @return annotation, as well as remove completely
      empty phpdoc comments because the @return annotation is removed.
      
      Please be aware, that once PSR-5 is accepted, this coding standard
      within the TYPO3 Core will change again, where there are currently
      some further proposal details like inheritance information.
      
      Resolves: #80454
      Releases: master
      Change-Id: Ie969d720684c0a75919fe5addd1c36ef5b12eb04
      Reviewed-on: https://review.typo3.org/51686
      
      
      Reviewed-by: Nicole Cordes's avatarNicole Cordes <typo3@cordes.co>
      Tested-by: Nicole Cordes's avatarNicole Cordes <typo3@cordes.co>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      eb049dba
  33. 30 Aug, 2016 1 commit
  34. 03 May, 2016 1 commit
  35. 04 Mar, 2016 1 commit
  36. 28 Dec, 2015 1 commit
  37. 11 Dec, 2015 1 commit
  38. 20 Nov, 2015 1 commit