Skip to content
GitLab
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 or owner.
Last successful update .
  1. 29 Jun, 2021 1 commit
  3. 28 Jun, 2021 1 commit
  5. 14 Jun, 2021 2 commits
  7. 13 Jun, 2021 2 commits
  9. 10 Jun, 2021 1 commit
  11. 01 Jun, 2021 1 commit
  13. 31 May, 2021 1 commit
  15. 20 May, 2021 1 commit
  17. 11 May, 2021 1 commit
  19. 04 May, 2021 6 commits
  21. 03 May, 2021 1 commit
  23. 30 Apr, 2021 1 commit
  25. 28 Apr, 2021 1 commit
  27. 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:
https://github.com/TYPO3/testing-framework/pull/229

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
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/68104


Tested-by: Oliver Hader's avatarOliver Hader <oliver.hader@typo3.org>
Tested-by: default avatarTYPO3com <noreply@typo3.com>
Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
Tested-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
Reviewed-by: Oliver Hader's avatarOliver Hader <oliver.hader@typo3.org>
Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
Reviewed-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
      d0da616d
  29. 30 Mar, 2021 1 commit
  31. 14 Mar, 2021 1 commit
  33. 10 Mar, 2021 1 commit
  35. 09 Mar, 2021 1 commit
  37. 08 Mar, 2021 2 commits
  39. 01 Mar, 2021 1 commit
  41. 24 Feb, 2021 1 commit
  43. 23 Feb, 2021 1 commit
  45. 22 Feb, 2021 1 commit
  47. 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
   recommended)
 * 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: https://github.com/TYPO3/cms-cli/pull/5

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
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67241


Tested-by: default avatarTYPO3com <noreply@typo3.com>
Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
Tested-by: Helmut Hummel's avatarHelmut Hummel <typo3@helhum.io>
Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
Reviewed-by: Helmut Hummel's avatarHelmut Hummel <typo3@helhum.io>
Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      3500a5ca
    • 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-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67548


Reviewed-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
Tested-by: default avatarTYPO3com <noreply@typo3.com>
Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
Tested-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      39145a46
  49. 11 Feb, 2021 1 commit
  51. 10 Feb, 2021 1 commit
  53. 01 Jan, 2021 1 commit
  55. 22 Dec, 2020 2 commits
  57. 21 Dec, 2020 1 commit
  59. 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
methods:

- 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
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65835


Tested-by: default avatarTYPO3com <noreply@typo3.com>
Tested-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
Tested-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
Reviewed-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
Reviewed-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
      64c8a784