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. 21 Dec, 2020 3 commits
    • 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
      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-.
         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 \
     | \
              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 \
         (cd Build && grunt build)
      Resolves: #93126
      Resolves: #93123
      Resolves: #93132
      Related: #92616
      Releases: master
      Change-Id: Ie194d0f87d2c60df7b9e8a6de4893cfaaea55356
      Tested-by: default avatarTYPO3com <>
      Tested-by: default avatarMartin Kutschker <>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <>
      Tested-by: Benni Mack's avatarBenni Mack <>
      Reviewed-by: default avatarMartin Kutschker <>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <>
      Reviewed-by: Benni Mack's avatarBenni Mack <>
    • Imko Schumacher's avatar
      [BUGFIX] Set timezone on TCA dbType input · 89f2e9f8
      Imko Schumacher authored and Benjamin Franzke's avatar Benjamin Franzke committed
      The value from columns that are marked as "dbType" date(time) fields
      in TCA configuration are now explicitly interpreted using UTC timezone,
      when the string value has no timezone specifier given.
      JS supplied values contain Z as specifier, while records from the database
      (which are processed during copy operations) do not contain a timezone
      Local time was assumed by PHP in the latter case before, as we did not
      pass an explicit timezone information to the DateTime constructor.
      Therefore we now assure no timezone conversion will happen and no
      time/date-offset will be added, by using UTC explicitly.
      Resolves: #89914
      Releases: master, 10.4, 9.5
      Change-Id: I8e531ae5f3367c4493ce1e7db4bec0ef02311e24
      Tested-by: default avatarTYPO3com <>
      Tested-by: Markus Klein's avatarMarkus Klein <>
      Tested-by: Benjamin Franzke's avatarBenjamin Franzke <>
      Reviewed-by: Markus Klein's avatarMarkus Klein <>
      Reviewed-by: Benjamin Franzke's avatarBenjamin Franzke <>
    • Christian Kuhn's avatar
      [TASK] Increase session id db field size · e4eee470
      Christian Kuhn authored and Benni Mack's avatar Benni Mack committed
      Since one of the recent security patches, frontend and
      backend user sessions are stored as HMAC-SHA256 if using
      redis storage backend, and HMAC-MD5 if using default
      database storage backend.
      Reason for using the less collision resistant md5 in
      database backend over sha256 has been, that the 64
      characters of sha256 did not fit into the varchar(32)
      field of the ses_id fields. This would have led to
      trouble for users upgrading to the security patch level
      We now increase the field size to varchar(255) with this
      patch, and backport this to v10. A second patch will then
      switch only v11/master to sha256. This way, users
      can increase db field size in v10 already to prepare for
      v11 and later upgrade to v11 without being logged out or
      experiencing db errors. Only users running current
      master will have to use the standalone install tool once
      to increase field size.
      Strictly, a field size of 64 characters would be enough
      for sha256, we however raise to 255 to never run into
      this chicken-egg issue again - just in case.
      Resolves: #93131
      Releases: master, 10.4
      Change-Id: Ifcafba0c3bae2f27ba0e13e6925007a6e1627d88
      Tested-by: default avatarTYPO3com <>
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <>
      Tested-by: Benni Mack's avatarBenni Mack <>
      Reviewed-by: Oliver Hader's avatarOliver Hader <>
      Reviewed-by: Benni Mack's avatarBenni Mack <>
      Reviewed-by: Oliver Klee's avatarOliver Klee <>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <>
  2. 20 Dec, 2020 7 commits
  3. 19 Dec, 2020 3 commits
  4. 18 Dec, 2020 5 commits
  5. 17 Dec, 2020 2 commits
  6. 16 Dec, 2020 1 commit
  7. 15 Dec, 2020 5 commits
  8. 14 Dec, 2020 12 commits
  9. 13 Dec, 2020 2 commits