1. 22 Feb, 2022 3 commits
    • Oliver Hader's avatar
      [RELEASE] Release of TYPO3 11.5.7 · 96afa84d
      Oliver Hader authored and Oliver Hader's avatar Oliver Hader committed
      Change-Id: I62fdb4ee41b85c87291ad38c28e4c4ecdaa7dc36
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73641
      Tested-by: Oliver Hader's avatarOliver Hader <oliver.hader@typo3.org>
      Reviewed-by: Oliver Hader's avatarOliver Hader <oliver.hader@typo3.org>
    • Stefan Bürk's avatar
      [BUGFIX] Use proper Postgres types on inserting / updating rows · e43bff35
      Stefan Bürk authored and Oliver Bartsch's avatar Oliver Bartsch committed
      In early stage of TYPO3v11 the storage format for data
      in the TCA ctrl transOrigDiffSourceField database field,
      often called l18n_diffsource changed from PHP serialized
      data to JSON encoded storage format with #91906, mainly
      to mitigate general security risks.
      doctrine/dbal enquotes json data provided as string with
      backslashes if not the correct field type is provided,
      which emits a postgres sql error exception when inserting
      or updating these fields, which are of type 'bytea' when
      dbms Postgres is used.
      Various parts of the core deal with arbitrary tables and
      don't know if a column is int, text or lob, or whatever.
      Those are blindly updated/inserted, resulting in Postgres
      saying "no".
      MSSQL has been named pickier than postgres in the past on
      that for similar issues with these fields. To solve this
      for MSSQL a expensive workaround on several places through
      the core with #81498 to get a working state and leaving it
      open to find a better way with a eventual cache-layer for
      these database field schema informations, thus unsolved yet.
      As core suffers now from the same issue for Postgres since
      the changed storage format, this patch adopts the choosen
      MSSQL solution for Postgres. This is a first bugfix solution
      with the tradeoff to be more expensive but working.
      Additionally one test case is added to cover this issue
      basicly but should be extended and further tightend in a
      dedicated patch.
      Improving the schema handling should be picked up and proper
      engineered in a another dedicated patch.
      Resolves: #96940
      Related: #91906
      Related: #81498
      Releases: main, 11.5
      Change-Id: I250fa10c9c7e06ddd330f7ab64f7680f21f3b4cd
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73551
      Tested-by: Stefan Bürk's avatarStefan Bürk <stefan@buerk.tech>
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: Stefan Bürk's avatarStefan Bürk <stefan@buerk.tech>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
    • Christian Kuhn's avatar
      [TASK] Allow DI for extbase validators · 72d16bc3
      Christian Kuhn authored
      With #92238, it has been postulated that Extbase
      validators should not be dependency injection aware.
      Further places following this idea have been done
      in v11 with #94451 and #94384. A final breaking
      ReST file has been added with #95026.
      All of that is pretty unfortunate and there is
      simply no reason that Extbase validators can
      not get dependencies injected, no matter if
      they're not singletons.
      This patch specifically targets v11 to allow
      dependency injection in Extbase validators again
      if extension authors really need this, and don't
      want to stick to manual dependency retrieval
      as outlined in #95026. This patch should basically
      mitigate issues for extension upgrades and paves
      the way for a more solid general solution in v12.
      Extension authors have a more smooth upgrade path,
      especially when supporting two core versions at
      the same time.
      The v12 version of this patch is identical with
      v11 for now - The breaking interface change,
      adapting all core validators, and declaring core
      validators 'final' in v12 will be done with a
      dedicated v12 patch as soon as this
      v11 tailored version has been aligned on.
      Note all of this is pretty hairy and the solution
      outlined with the patch for v11 hopefully gives the
      maximum amount of compatibility without being
      breaking again, with giving extension authors
      additional options, and having v12 options to
      further mitigate this complex mess.
      Resolves: #96332
      Related: #92238
      Related: #95026
      Related: #94451
      Related: #94384
      Releases: main, 11.5
      Change-Id: I5fea15c9b73c59e5d7c3212a0842bc9a3413d2a1
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73630
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
  2. 21 Feb, 2022 5 commits
  3. 20 Feb, 2022 6 commits
  4. 19 Feb, 2022 1 commit
  5. 18 Feb, 2022 2 commits
  6. 17 Feb, 2022 7 commits
  7. 16 Feb, 2022 2 commits
  8. 15 Feb, 2022 7 commits
  9. 14 Feb, 2022 7 commits