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 or owner.
Last successful update .
  1. 29 Jun, 2021 1 commit
  2. 28 Jun, 2021 1 commit
  3. 14 Jun, 2021 2 commits
  4. 13 Jun, 2021 2 commits
  5. 10 Jun, 2021 1 commit
  6. 01 Jun, 2021 1 commit
  7. 31 May, 2021 1 commit
  8. 20 May, 2021 1 commit
  9. 11 May, 2021 1 commit
  10. 04 May, 2021 6 commits
  11. 03 May, 2021 1 commit
  12. 30 Apr, 2021 1 commit
  13. 28 Apr, 2021 1 commit
  14. 23 Apr, 2021 1 commit
    • Benjamin Franzke's avatar
      [TASK] Update to Lit v2-rc1 · d0da616d
      Benjamin Franzke authored
      Lit is the umbrella term for the next major
      lit-html (v2) and lit-element (v3) versions.
      Therefore we will refer to these components as
      *Lit* in TYPO3 from now on as well.
      These two libraries also have been migrated into
      a single entry point module named `lit`.
      It is officially described as:
      > The main module exports the core pieces needed for component
      > development: LitElement, html, css, and the most
      lit-html v2 and lit-element v3 are mostly compatible
      to the previous major versions. Main changes are
       * Deprecation of the `lit-element` entry point in
         favor of the new `lit` module
       * @internalProperty changed to @state
       * shadow css declaration via static property
         instead of static getter method
       * The CSSResult type declaration is gone
       * Directive (currently unused in TYPO3) API has changed
      Related testing framework change is:
      Commands used:
        rm -rf typo3/sysext/core/Resources/Public/JavaScript/Contrib/{@lit,lit-element,lit-html,lit}/
        yarn add lit@^2.0.0-rc.1 lit-html@^2.0.0-rc.2 lit-element@^3.0.0-rc.1
        yarn add --dev rollup@^2.32.0 @rollup/plugin-replace
        grunt build
        git add typo3/sysext/core/Resources/Public/JavaScript/Contrib/{@lit,lit-element,lit-html,lit}/
        composer require --dev typo3/testing-framework:^6.8.1
        composer require --dev typo3/testing-framework:^6.8.1 \
          --no-update --working-dir=typo3/sysext/core
      Resolves: #93965
      Releases: master
      Change-Id: I9b659d851e6ad9dc3cc649bd40aab886b86fb0f8
      Tested-by: Oliver Hader's avatarOliver Hader <>
      Tested-by: default avatarTYPO3com <>
      Tested-by: core-ci's avatarcore-ci <>
      Tested-by: Benni Mack's avatarBenni Mack <>
      Tested-by: Benjamin Franzke's avatarBenjamin Franzke <>
      Reviewed-by: Oliver Hader's avatarOliver Hader <>
      Reviewed-by: Benni Mack's avatarBenni Mack <>
      Reviewed-by: Benjamin Franzke's avatarBenjamin Franzke <>
  15. 30 Mar, 2021 1 commit
  16. 14 Mar, 2021 1 commit
  17. 10 Mar, 2021 1 commit
  18. 09 Mar, 2021 1 commit
  19. 08 Mar, 2021 2 commits
  20. 01 Mar, 2021 1 commit
  21. 24 Feb, 2021 1 commit
  22. 23 Feb, 2021 1 commit
  23. 22 Feb, 2021 1 commit
  24. 19 Feb, 2021 2 commits
    • Benjamin Franzke's avatar
      [TASK] Refactor low level console commands to avoid full boot · 3500a5ca
      Benjamin Franzke authored and Benni Mack's avatar Benni Mack committed
      This will allow for low level commands like cache:warmup (or flush)
      to be implemented.
      Commands that're registered in (internal!) service providers are now
      defined to be lowlevel. That allows to change behaviour for internal
      commands only, without being breaking.
      Low level commands…
       * will only be defined by TYPO3 core, not by third party extensions
         or libraries (despite by using internal interfaces)
       * will not use any $GLOBALS in constructor
       * will only inject dependencies defined by service providers
       * must not require a database connection during construction
       * will only be defined in internal service providers
       * may use the internal BootService to bootstrap to a certain
         boot level
      Regular commands…
       * are allowed to access TYPO3_CONF_VARS in constructor
       * are allowed to inject any service via constructor
       * are allowed to access TCA in constructor
       * may perform database calls in constructors (although this is not
       * may fail during construction, e.g. because of a stale DI container
         (an upcoming low level cache:flush/warmup command will be
         provided for such scenarios)
      The command list `bin/typo3 list`…
       * will show all low level commands
       * will degrade to low level only commands if the DI
         container is not loadable
      The upgrade command therefore now runs fully uncached and does not
      require a full boot upfront.
      The symfony command `help` is treated as non low level command,
      as command constructors need to be executed in order for arguments
      to be configured and available for help output. Therefore a full
      boot is required. This causes the symfony DI container,
      ext_localconf and ext_tables to be loaded.
      That means: An invalid container cache will cause help to fail,
      `list` will degrade do lowlevel commands, but an
      (upcoming) low level console command cache:flush/warmup will
      still be invokable and is intended for scenarios where 3rd party
      code is changed and therefore DI/localconf/TCA cache became stale.
      `typo3/cms-cli`, which provides vendor/bin/typo3 in composer mode,
      is adapted in:
      Commands used for updating typo3/cms-cli:
        composer require typo3/cms-cli:^3.0
        composer require typo3/cms-cli:^3.0 \
          --no-update --working-dir=typo3/sysext/core
      Resolves: #86248
      Related: #93174
      Releases: master
      Change-Id: Ie7cfb73983d96ed67532570be4099a25d106db28
      Tested-by: default avatarTYPO3com <>
      Tested-by: core-ci's avatarcore-ci <>
      Tested-by: Helmut Hummel's avatarHelmut Hummel <>
      Tested-by: Benni Mack's avatarBenni Mack <>
      Reviewed-by: Helmut Hummel's avatarHelmut Hummel <>
      Reviewed-by: Benni Mack's avatarBenni Mack <>
    • Oliver Bartsch's avatar
      [FEATURE] Introduce MFA in Core · 39145a46
      Oliver Bartsch authored and Benni Mack's avatar Benni Mack committed
      A new API is introduced, providing multi-factor
      authentication for the Core. The API is furthermore
      directly used to add two MFA providers by default:
      * TOTP (time-based one-time passwords)
      * Recovery codes
      Even if the API is designed to allow MFA in both,
      backend and frontend, it is currently only implemented
      into the backend. Users can therefore configure their
      available MFA providers in a new backend module,
      accessible via their user settings.
      There are also some configuration options for
      administrators to e.g. define a recommended provider
      or to disallow available providers for specific users
      or user groups.
      Administration of the users' MFA providers is possible
      for administrators in the corresponding user records.
      New providers can be introduced by implementing the
      MfaProviderInterface and tagging the service with the
      `mfa.provider` tag.
      Note that the API is currently marked as internal since
      changes in upcoming patches are to be expected.
      Following dependencies are introduced:
      * bacon/bacon-qr-code "^2.0"
      * christian-riesen/base32 "^1.5"
      Possible features that could follow later-on:
      * MFA frontend integration
      * Webauthn core provider for FIDO2 and U2F.
      * Forcing users to set up MFA on login
      * Password-recovery with active MFA
      Resolves: #93526
      Releases: master
      Change-Id: I4e902be624c80295c9c0c3286c90a6a680feeb5d
      Reviewed-by: Benjamin Franzke's avatarBenjamin Franzke <>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <>
      Reviewed-by: Benni Mack's avatarBenni Mack <>
      Tested-by: default avatarTYPO3com <>
      Tested-by: core-ci's avatarcore-ci <>
      Tested-by: Benjamin Franzke's avatarBenjamin Franzke <>
      Tested-by: Benni Mack's avatarBenni Mack <>
  25. 11 Feb, 2021 1 commit
  26. 10 Feb, 2021 1 commit
  27. 01 Jan, 2021 1 commit
  28. 22 Dec, 2020 2 commits
  29. 21 Dec, 2020 1 commit
  30. 14 Dec, 2020 1 commit
    • Alexander Schnitzler's avatar
      [TASK] Deprecate @Extbase\Inject · 64c8a784
      Alexander Schnitzler authored and Benjamin Franzke's avatar Benjamin Franzke committed
      Since core dependency injection is in place and is about to
      replace the extbase dependency injection, marking properties
      with the @Extbase\Inject annotation to invoke property injection is
      deprecated and must be replaced by one of the following di
      - constructor injection: works both with core and extbase di
        and is well suited to make extensions compatible for multiple
        TYPO3 versions.
      - setter injection: Basically the same like constructor injection.
        Both the core and extbase di can handle setter injection and
        both are supported in different TYPO3 versions.
      - (core) property injection: This kind of injection can be used
        but it requires the configuration of services via a Services.yaml
        in the Configuration folder of an extension.
      The recommended way is constructor injection. Not only is it the
      most compatible version of di, it also brings the advantage of
      clearly showing dependencies of a class. Also, it quickly shows
      if dependencies stack up which indicates that the service should
      be refactored.
      Releases: master
      Resolves: #92386
      Change-Id: I61afbb6bb15b136c200849c6c8f2cd6211d4c306
      Tested-by: default avatarTYPO3com <>
      Tested-by: Georg Ringer's avatarGeorg Ringer <>
      Tested-by: Benjamin Franzke's avatarBenjamin Franzke <>
      Reviewed-by: Georg Ringer's avatarGeorg Ringer <>
      Reviewed-by: Benjamin Franzke's avatarBenjamin Franzke <>