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. 09 Jul, 2021 1 commit
  2. 01 Jul, 2021 1 commit
  3. 30 Jun, 2021 2 commits
  4. 29 Jun, 2021 1 commit
  5. 16 Jun, 2021 1 commit
  6. 14 Jun, 2021 1 commit
  7. 11 Jun, 2021 1 commit
  8. 10 Jun, 2021 1 commit
  9. 09 Jun, 2021 1 commit
  10. 27 May, 2021 1 commit
    • Christian Kuhn's avatar
      [TASK] Deprecate ext:backend ModuleLayout view helpers · 5a456090
      Christian Kuhn authored
      A while after the PHP based ModuleTemplate API has been
      introduced back in 2015, a couple of fluid view helpers
      have been added to ext:backend as a second way to handle
      full backend module content like the doc header.
      It found an example use in ext:beuser.
      
      Development however stopped at this point, the provided
      view helpers are only a sub set of the PHP based API and
      they didn't find broader use within the core - all other
      backend modules stick to the ModuleTemplate based API.
      
      On a structural level, those view helpers are questionable:
      They move functionality to the view component which is
      arguably more a controller task. The ext:beuser module
      proofes this since it had to assign controller knowledge
      like the current action and controller name to the view
      in order to render the doc header module down and shortcut
      buttons.
      
      The patch drops usages of these view helpers in ext:beuser,
      plus the minor usages of the outer ModuleLayout view helper
      in ext:install and ext:belog, substitutes them with the
      PHP ModuleTemplate API within controllers, and deprecates
      the full set of ModuleLayout view helpers.
      
      The change sharpens our separation between controller and
      view: The "outer" module handling like doc header buttons
      and menus are tied to controller logic and should be
      located there, while the module body is rendered by a
      fluid view.
      
      As a bonus, a couple of issues within ext:beuser are
      fixed along the way, since they can now be easily solved
      and were rather hard to tackle with the view helper based
      approach:
      * The beuser module now remembers state and jumps to
        for instance the group sub module when a user selected
        this last. This is now in line with many other backend
        modules that do the same.
      * Shortcuts to single user details work.
      * The main doc header drop down can now contain all possible
        sub modules, including those that are available only
        indirectly, for instance the single user details view.
        This is good when calling these from shortcuts.
      
      Change-Id: Idef3aa6975e97677c1da0cef57f70c855bd2ea9f
      Resolves: #94209
      Releases: master
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69269
      
      
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Tested-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Tested-by: Jochen's avatarJochen <rothjochen@gmail.com>
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Reviewed-by: Jochen's avatarJochen <rothjochen@gmail.com>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      5a456090
  11. 19 May, 2021 1 commit
  12. 14 May, 2021 1 commit
  13. 12 May, 2021 1 commit
  14. 04 May, 2021 2 commits
  15. 20 Apr, 2021 1 commit
  16. 12 Apr, 2021 1 commit
  17. 24 Mar, 2021 1 commit
  18. 17 Mar, 2021 2 commits
  19. 12 Mar, 2021 1 commit
  20. 11 Mar, 2021 1 commit
  21. 10 Mar, 2021 1 commit
  22. 09 Mar, 2021 2 commits
  23. 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>
      650d5d7b
  24. 03 Mar, 2021 1 commit
  25. 02 Mar, 2021 1 commit
  26. 01 Mar, 2021 1 commit
  27. 24 Feb, 2021 1 commit
  28. 19 Feb, 2021 1 commit
    • 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
  29. 09 Feb, 2021 1 commit
    • Benjamin Franzke's avatar
      [FEATURE] Implement lazy console command list · 38121e34
      Benjamin Franzke authored and Helmut Hummel's avatar Helmut Hummel committed
      Based on the configuration syntax of the Symfony Console
      feature https://github.com/symfony/symfony/pull/39851
      …but implemented differently, using a registry pattern
      rather then a lazy-object pattern (like symfony does).
      
      Main motiviation for the registry pattern is following:
      Symfony LazyCommand wrappers add quite some complexity only
      for the sake of the list command, we already got lazy
      commands (in terms of execution) as our CommandRegistry
      implements the ConfigurationLoaderInterface that has been
      introduced by 2017 to add support for lazy commands.
      
      Now, that means we already got a registry for lazy commands,
      so it is logical to add lazy description handling there as well.
      
      We want to assure that the command list will never instantiate
      any commands. This is in constrast to the Symfony core LazyCommand
      approach, where legacy commands, that do not provide a compile time
      description, would still be instantiated during console command list.
      
      Also commands that return false in `isEnabled()` are now listed.
      That means enabled state is only evaluated during runtime.
      Therefore the special `dumpautoload` command is transformed into a
      lowlevel command in order to be hidden dependending on being run
      in composer-mode or not.
      
      Releases: master
      Resolves: #93174
      Change-Id: Ifa68404cc81c64a335be30f2263a7eb17de0624d
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67635
      
      
      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: Helmut Hummel's avatarHelmut Hummel <typo3@helhum.io>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Helmut Hummel's avatarHelmut Hummel <typo3@helhum.io>
      38121e34
  30. 04 Feb, 2021 1 commit
  31. 01 Feb, 2021 1 commit
  32. 27 Jan, 2021 1 commit
  33. 07 Jan, 2021 1 commit
    • Benjamin Franzke's avatar
      [TASK] Propagate "immediate" responses through the middleware stack · f179a57f
      Benjamin Franzke authored and Benni Mack's avatar Benni Mack committed
      When a controller finds some pre-requisites of the called
      action are not fulfilled, it can create an 'early' response
      and throw it as ImmediateResponseException. This exception
      bypasses the middleware stack, and is caught in the Application
      to emit the response. This is a big win in contrast to
      die/exit calls.
      
      Some middlewares however expect to be always called when the
      response bubbles up. Good examples are 'locking' middlewares:
      They set up a lock when called, dispatch to inner middlewares,
      and tear town the lock when a response is retrieved.
      
      The tear down code of those middlewares is bypassed when
      a controller throws an ImmediateResponseException.
      
      The patch introduces a second exception: PropagateResponseException.
      This one is caught by a new very inner middleware positioned at the
      end of the middleware stack, just before the request is dispatched
      to some controller. It then sends the response up the outer
      middlewares. This allows middlewares like a 'locking' middleware
      to do it's job without being bypassed, and at the same time
      allows a controller to bypass any further local processing by
      throwing such a response exception.
      
      ImmediateResponseException exists as before and can still be used
      to directly bypass the middleware stack and is kept as safety net
      in case a PropagateResponseException is thrown within a middleware.
      PropagateResponseException therefore extends ImmediateResponseException.
      
      It's however discouraged to throw ImmediateResponseException from
      within controllers - they require knowledge on what middlewares
      do in their 'tear down' part and there shouldn't be a reason to
      bypass them.
      
      Middleware/BackendUserAuthenticator is adapted to properly
      handle ImmediateResponseException that would have been thrown
      BackendUserAuthentication::backendCheckLogin(). BackendUserAuthentication
      is therefore refactored to allow to call the backend login
      initialization without (duplicate) login check.
      This allows to propagate redirect/maintenance responses.
      
      Releases: master
      Resolves: #93007
      Change-Id: I291d9d532e7fa289b803e5eef38b23402e57e8ba
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67042
      
      
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      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>
      f179a57f
  34. 06 Jan, 2021 1 commit
  35. 04 Jan, 2021 1 commit
  36. 21 Dec, 2020 1 commit
    • Benjamin Franzke's avatar
      [TASK] Update bootstrap javascript to 5.0.0-beta1 · 27881b60
      Benjamin Franzke authored and Benni Mack's avatar Benni Mack committed
      Bootstrap v5 – introduced in #92616 – was added with CCS from beta1 but
      JavaScript from alpha2. bootstrap.bundle.js was manually wrapped
      into a AMD closure, and because bootstrap 5.0.0-beta1 contains alot of
      changes regarding data tags, it couldn't be updated in the initial
      patch.
      
      Bootstrap is now bundled using rollup using the ES6 sources in order
      to allow for automatic updates through `grunt build`.
      
      popperjs – previously bundled into bootstrap distributed files –
      is now added as dependency. The bootstap ES6 sources, that we now use
      through rollup, do not bundle this external dependency (for good reasons).
      
      Dependency added with:
      
         yarn add @popperjs/core
      
      Further adaptions contained in this change to ensure beta1 compatibility:
      
      a) Carousel "item" to "carousel-item" class migration
      b) $.fn.modal(options) does no longer imply $.fn.modal('show')
      c) Fix panels, both JS and CSS (card-group can't be used here)
      d) All bootstrap data- tags are migrated to data-bs-.
         (see https://github.com/twbs/bootstrap/pull/31827)
         Migrated with
      
         # renderes a sed substition with the help of a nested sed from all the
         # data-bs attributes that where changed in the twbs/bootstrap commit
         git grep -l data- | xargs sed -i $( \
              curl -s \
              https://patch-diff.githubusercontent.com/raw/twbs/bootstrap/pull/31827.patch | \
              sed 's/data-bs-[a-z-]*/\n&\n/g' | grep "data-bs-[a-z-]" | \
              sort | uniq | \
              sed 's/data-bs-\(.*\)\([^a-z-]\|$\)/ -e s\/data-\1\\\([^a-z-]\\\)\/data-bs-\1\\1\/g -e s\/data('"'"'\1'"'"')\/data('"'"'bs-\1'"'"')\/g/g' \
         )
      
         # Revert false positives from the above auto-replacement
         git checkout -- typo3/sysext/core/Documentation/Changelog/ \
              typo3/sysext/backend/Classes/Form/Container/FlexFormContainerContainer.php \
              Build/Sources/TypeScript/backend/Resources/Public/TypeScript/LiveSearch.ts \
              Build/Sources/TypeScript/backend/Resources/Public/TypeScript/FormEngineFlexForm.ts \
              Build/Sources/TypeScript/install/Resources/Public/TypeScript/Module/Settings/ExtensionConfiguration.ts \
              Build/Sources/Sass/typo3/_element_panel.scss
      
         (cd Build && grunt build)
      
      Resolves: #93126
      Resolves: #93123
      Resolves: #93132
      Related: #92616
      Releases: master
      Change-Id: Ie194d0f87d2c60df7b9e8a6de4893cfaaea55356
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67215
      
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: default avatarMartin Kutschker <mkutschker-typo3@yahoo.com>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: default avatarMartin Kutschker <mkutschker-typo3@yahoo.com>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      27881b60