1. 11 May, 2022 1 commit
  2. 07 Apr, 2022 1 commit
  3. 07 Feb, 2022 1 commit
    • Oliver Bartsch's avatar
      [!!!][FEATURE] New Module Registration API · 29db88c3
      Oliver Bartsch authored and Benni Mack's avatar Benni Mack committed
      This change introduces a new way to register
      TYPO3 Backend Modules.
      Each module is now registered during build-time
      in a dedicated registry. Therefore, The registration
      is moved from ext_tables.php to the
      Configuration/Backend/Modules.php file.
      Accessing the registered modules can be done via
      a central API, the ModuleProvider class. This class
      takes care of access permissions and further
      processing (e.g. module menu generation).
      $GLOBALS[TBE_MODULES] is fully removed as no sane
      backwards-compatibility (for a use-case) is available.
      A new PSR-14 event BeforeModuleCreationEvent is added,
      which allows to manipulate a module configuration, before
      it is used to create and register the module.
      Existing registrations do no longer work. However, to support
      extenion authors in maintaining multiple versions, the previously
      used API methods (e.g. `addModule` and `registerModule`) will
      stay until TYPO3 v13.0. No trigger_error() is used, so extension
      authors use the Extension Scanner to detect usages.
      Executed commands:
         composer u typo3/cms-styleguide
      Resolves: #96733
      Releases: main
      Change-Id: I07f4bc417e6effb1215cf0e373cc60f2b13ba8ad
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73058
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
  4. 08 Nov, 2021 1 commit
  5. 24 Sep, 2021 1 commit
  6. 09 Sep, 2021 1 commit
  7. 26 Aug, 2021 1 commit
  8. 24 Aug, 2021 1 commit
  9. 26 May, 2021 1 commit
    • Richard Haeser's avatar
      [TASK] Set proper title of window in backend · 2cba0bac
      Richard Haeser authored and Benjamin Franzke's avatar Benjamin Franzke committed
      With the introduction of the new backend module web component router,
      the title of the backend windows will be set to the title of the
      main iframe. Most of the modules didn't provide a proper name though.
      For most modules we have a proper name now which will show up in the
      title of the backend window, if no title is propagated by the module,
      the backend router will fallback to the default backend title.
      As the format of the title is quite "personal". If you are used to have
      opened more TYPO3 backend windows, you would like to see which
      installation you have open. If you only work in one backend, you
      might want to see on which module you are currently working. It is
      possible to set the order of the title of the backend within your
      user settings now. By default it will be title - siteName [version]
      Resolves: #94182
      Releases: master
      Change-Id: I02602650370140217aa252bbd8e29ea4e05d994a
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69172
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Jochen's avatarJochen <rothjochen@gmail.com>
      Tested-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
      Reviewed-by: Jochen's avatarJochen <rothjochen@gmail.com>
      Reviewed-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
  10. 26 Apr, 2021 1 commit
  11. 08 Mar, 2021 1 commit
    • Benni Mack's avatar
      [FEATURE] Use database field be_users.lang for UI language · 650d5d7b
      Benni Mack authored and Christian Kuhn's avatar Christian Kuhn committed
      Historically (even before TYPO3 3.3.0), the UI language (the language of
      the TYPO3 Backend of a user) is stored in ->uc['lang'], which is only
      filled from the database field be_users.lang when a user logs in the
      first time.
      be_user.lang is/was used for admins when creating users to set a default
      language when the user first logs in for the first time, but is never
      used afterwards.
      However, using "uc[lang]" in various places does not make life easier
      because uc always needs to be unpacked (e.g. for sending bulk mails
      to users, or changing languages for users as admins, listing
      users' preferred languages in list module).
      For this reason, be_users.lang now defines the users' UI language,
      however uc[lang] is synced on each login of a user now, if the language
      has changed.
      In addition, the TCA for be_users.lang is now handled via an
      itemsProcFunc, making uncached requests a tiny bit faster as Locales are
      not populated during TCA creation, and allows for more features such as
      dynamically showing available/downloaded languages in a be_users
      FormEngine field.
      The Setup module now updates be_users.lang instead of uc[lang],
      which makes it easier in the future to use native TCA for rendering
      the setup module fields.
      An upgrade wizard migrates all "uc[lang]" values into "be_users.lang"
      and ensures that empty values are never used, instead
      "default" (= English) is added to all user records to have an explicit
      value (also for new users).
      Resolves: #93663
      Releases: master
      Change-Id: Icb8e07f3fabb1f3022f3adcbdce6dc9efd790302
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/68192
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      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>
  12. 19 Feb, 2021 1 commit
    • 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>
  13. 29 Nov, 2020 1 commit
  14. 19 Oct, 2020 1 commit
  15. 14 Oct, 2020 1 commit
    • Christian Kuhn's avatar
      [!!!][TASK] Drop 'recursive delete' backend user setting · f3e221a2
      Christian Kuhn authored and Benni Mack's avatar Benni Mack committed
      The 'you can not delete pages that have sub pages' user
      settings restriction has been annoying ever since. Users
      who actually want to delete a full tree were annoyed by
      this flag if they did not had it and had to rely on an
      administrator action to actually give it to them, and
      had to delete pages on a one-by-one base meanwhile.
      Clever admins thus often enabled that flag by default.
      It was meant as a feature to prevent casual users from
      commiting accidential harm to a site tree. There are
      better ways to achieve this goal however: Admins
      can set proper access rights for important key pages
      preventing editors from deleting them. Furthermore,
      a better 'prevent editors from doing harm in live'
      way is available by using the workspaces extension. And,
      in case of accidental deletion, admins can always
      resurrect full page trees using the recycler extension.
      The patch drops the 'recursive delete' option from
      specific user settings and always allows deleting
      pages including sub pages.
      Resolves: #92560
      Releases: master
      Change-Id: I8401edc10daece7f83d0c5f85f99129616fac957
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66136
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
  16. 27 Aug, 2020 1 commit
    • Christian Kuhn's avatar
      [!!!][TASK] Drop TCA [ctrl][thumbnail] and user uc[thumbnailsByDefault] · ae39eb5a
      Christian Kuhn authored and Anja Leichsenring's avatar Anja Leichsenring committed
      Setting TCA[$someTable]['ctrl']['thumbnail'] to some image related
      column made the list module show attached images as preview.
      Until core v8, this has been used for tt_content and has been
      dropped for this table because two different fields (images, media)
      are used and the setting could not cope with that.
      For extensions with own tables, this setting has been used
      very seldom. It also partially destroys the list module view.
      The patch drops evaluation of this ctrl setting in the list module.
      With this gone, the 'thumbnailsByDefault' setting of the user settings
      module only affects the file list module. The file list module has
      it's own checkbox to toggle image preview rendering, so the setup module
      checkbox has little benefit and is removed as well. This additionally
      fixes a bug that thumbnail preview rendering in file list module can't
      be turned off if the setup module checkbox is set.
      Additionally, the patch drops some unused css for the list module,
      'typo3-dblist' simply does not exist as class.
      Change-Id: If9365b5a26e708cc4d4d57cfcddd728cf97d7811
      Resolves: #92118
      Related: #79622
      Releases: master
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65493
      Tested-by: Achim Fritz's avatarAchim Fritz <af@achimfritz.de>
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Daniel Windloff
      Tested-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Reviewed-by: Achim Fritz's avatarAchim Fritz <af@achimfritz.de>
      Reviewed-by: Daniel Windloff
      Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
  17. 31 May, 2020 1 commit
  18. 14 Apr, 2020 1 commit
  19. 22 Jun, 2018 1 commit
  20. 25 Apr, 2018 1 commit
  21. 27 Jan, 2018 1 commit
  22. 16 Oct, 2017 1 commit
  23. 02 Feb, 2017 1 commit
  24. 01 Dec, 2016 1 commit
  25. 01 Nov, 2016 1 commit
  26. 30 Aug, 2016 1 commit
  27. 26 May, 2016 1 commit
  28. 06 Mar, 2016 1 commit
  29. 23 Feb, 2016 1 commit
  30. 23 Jan, 2016 1 commit
  31. 04 Nov, 2015 1 commit
  32. 08 Oct, 2015 1 commit
  33. 18 Sep, 2015 1 commit
  34. 20 Jul, 2015 1 commit
  35. 18 Jul, 2015 1 commit
  36. 17 Jul, 2015 1 commit
  37. 13 Jul, 2015 1 commit
  38. 09 Mar, 2015 1 commit
  39. 05 Jan, 2015 1 commit
  40. 12 Dec, 2014 1 commit