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. 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 <>
  2. 30 Mar, 2021 1 commit
  3. 14 Mar, 2021 1 commit
  4. 10 Mar, 2021 1 commit
  5. 09 Mar, 2021 1 commit
  6. 08 Mar, 2021 2 commits
  7. 01 Mar, 2021 1 commit
  8. 24 Feb, 2021 1 commit
  9. 23 Feb, 2021 1 commit
  10. 22 Feb, 2021 1 commit
  11. 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 <>
  12. 11 Feb, 2021 1 commit
  13. 10 Feb, 2021 1 commit
  14. 01 Jan, 2021 1 commit
  15. 22 Dec, 2020 2 commits
  16. 21 Dec, 2020 1 commit
  17. 14 Dec, 2020 1 commit
  18. 10 Dec, 2020 1 commit
  19. 05 Dec, 2020 2 commits
  20. 04 Dec, 2020 1 commit
  21. 01 Dec, 2020 1 commit
  22. 24 Nov, 2020 1 commit
  23. 20 Nov, 2020 1 commit
  24. 17 Nov, 2020 1 commit
  25. 11 Nov, 2020 1 commit
  26. 07 Nov, 2020 1 commit
  27. 03 Nov, 2020 1 commit
    • Helmut Hummel's avatar
      [TASK] Enforce Composer 2 usage for TYPO3 development · 6889e440
      Helmut Hummel authored and Benni Mack's avatar Benni Mack committed
      To benefit from faster operations and cleaner updates
      Composer 2 usage is now enforced by requiring ^2.0
      of composer-runtime-api.
      Although currently there is no real code dependency yet
      to the runtime API introduced for Composer 2, this
      requirement enforces usage of Composer 2 for all interactions
      with this package (install/ update).
      The package is required as dev dependency to still
      allow "manual" usage of this package for classic installs
      and make the breaking impact low (composer install --no-dev
      will still work with Composer 1)
      For TYPO3 v11 this dependency will likely be a production
      dependency as well.
      composer up --lock
      composer req --dev composer-runtime-api:^2.0
      Resolves: #92753
      Releases: master, 10.4, 9.5
      Change-Id: Ie919c0cf36a0818eea2124bb9623485d3d642066
      Tested-by: default avatarTYPO3com <>
      Tested-by: Benni Mack's avatarBenni Mack <>
      Reviewed-by: Benni Mack's avatarBenni Mack <>
  28. 30 Oct, 2020 1 commit
  29. 20 Oct, 2020 1 commit
  30. 13 Oct, 2020 1 commit
  31. 08 Oct, 2020 1 commit
  32. 06 Oct, 2020 1 commit
  33. 02 Oct, 2020 1 commit
  34. 30 Sep, 2020 1 commit
  35. 25 Sep, 2020 1 commit
  36. 18 Sep, 2020 1 commit