1. 14 Jan, 2022 1 commit
  2. 03 Jan, 2022 1 commit
  3. 20 Dec, 2021 1 commit
    • Stefan Bürk's avatar
      [BUGFIX] Forward-compatible prepared statement support · ed725d12
      Stefan Bürk authored and Benni Mack's avatar Benni Mack committed
      doctrine/dbal:^3.2 changed return type of result for QueryBuilder
      execute methods, no longer have used prepared statement accessible
      for further query execution with other placeholder values.
      To raise doctrine/dbal:^3.2 two places have been changed to reuse
      the QueryBuilder instance itself instead of prepared statement with
      the corresponding patch #96287, thus given up the performance gain
      through reusable query execution plan in corresponding dbms systems.
      This patch adds support for prepared statements to TYPO3's
      QueryBuilder facade as this was not publicly available yet
      for TYPO3 users to be forward-compatible with Doctrine DBAL 3.
      Resolves: #96393
      Related: #96287
      Releases: main
      Change-Id: I814670ebf9920ed3162a31f98ad9efd4031f47c9
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/72716
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
  4. 16 Dec, 2021 1 commit
    • Nikita Hovratov's avatar
      [BUGFIX] Fix validation in form override settings · bf3eaa6c
      Nikita Hovratov authored and Benni Mack's avatar Benni Mack committed
      The FinisherOptionGenerator of the form extension
      generates the data structure for the form setting
      overrides on the fly. By doing so, it didn't make
      a distinction between normal TCA fields and flexform
      specific sections/containers and added the wrapper
      "TCEforms" to sections as well, which broke the
      validation in DataHandler for the fields inside the
      container (E.g. the email field).
      The patch checks if section is set to "true" and
      adds the "TCEforms" key only for normal TCA field
      Unit tests have been added for the DataHandler
      checkValue_flex_procInData_travDS method, which
      show cases with and without the "TCEforms" key.
      Also, since this works now, a PHP 8 warning
      appeared. This is fixed now, too.
      Resolves: #95441
      Releases: main, 11.5
      Change-Id: Ib12a0484bcbdc827664181ca6af89edfadee13d8
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/72688
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
  5. 13 Dec, 2021 1 commit
  6. 08 Dec, 2021 1 commit
  7. 07 Dec, 2021 1 commit
  8. 25 Nov, 2021 2 commits
  9. 24 Nov, 2021 1 commit
    • Christian Kuhn's avatar
      [BUGFIX] Better sys_refindex with workspace mm · 93279297
      Christian Kuhn authored
      This fixes issues regarding sys_refindex handling when dealing
      with workspace mm relations. Various DataHandler tests run with
      disabled refindex check after performing mm related operations.
      All those are enabled now, so all known issues in this area
      are fixed.
      The patch touches various areas in DataHandler, ReferenceIndex
      and RelationHandler to achieve this.
      The key changes are triggered by a database scenario that is
      unique for mm relations. Usually, when creating a workspace record
      or overlay, child record overlays (for instance inline children)
      are also created in this workspace.
      For mm records, this can be different: When the local or foreign
      side of a record is created in a workspace, it does not necessarily
      mean that a connected opposite side is also created as workspace
      This would otherwise create the need for a recursive operation that
      would basically end up with "everything" being created as workspace
      overlay. However, mm table entries are created for these relations,
      leading to a situation that a workspace record can point to a
      non-workspace record through the mm table.
      Reference index entries for mm table connections are always handled
      from the 'local' side. For instance, with categories, 'sys_category'
      table is the local side, with 'pages', 'tt_content' and others
      being the foreign side. If now one of the records on the foreign
      side gets a workspace overlay record, sys_refindex rows of all
      connected records of the affected local side need to be created.
      This can lead to the funny situation that we end up with refindex
      rows that point from a non-workspace to a non-workspace record,
      but have a non-0 workspace entry. Those additional rows are needed
      to have "the full set" and proper sorting when looking at refindex
      of such a relation from the local side.
      The patch basically handles especially these 'foreign side has
      a workspace overlay' scenarios, plus the side effects that
      have to be taken care of when discarding and publishing these
      Additionally, a couple of side effects are tackled: First, the
      ReferenceIndex->updateIndex() - that's the main logic when
      running cli referenceindex:update command - is tuned to drop
      reference index entries related to meanwhile deleted workspaces.
      This is covered with additional tests and is done now since
      the code needs to iterate over existing workspaces for local-side
      mm records that may have workspace overlays on the foreign side.
      So most of the code had to be created now anyways.
      RelationHandler->readMM() receives a fix for a long standing bug
      (Issue #83582, introduced by #57169), to no longer show workspace
      relations in live when looking at local-side records, for instance
      when looking at category items in live when one of the connected
      items has a workspace overlay.
      Next to lots of comments explaining details in place and
      referencing the test cases that nail specific scenarios, a
      couple of @todo's are added to point out things we may
      want to tackle in the future.
      All in all, the patch resolves a series of issues that will
      especially lead to 'categories' being much more reliable in
      Change-Id: I24407f93665852fa761f6fbe6c5ab249473468d2
      Related: #57169
      Resolves: #83582
      Resolves: #96067
      Releases: master, 11.5
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/72268
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
  10. 22 Nov, 2021 1 commit
  11. 20 Nov, 2021 1 commit
  12. 15 Nov, 2021 1 commit
  13. 10 Nov, 2021 1 commit
  14. 09 Nov, 2021 1 commit
  15. 04 Nov, 2021 1 commit
  16. 03 Nov, 2021 1 commit
  17. 02 Nov, 2021 1 commit
  18. 26 Oct, 2021 1 commit
  19. 24 Oct, 2021 1 commit
  20. 19 Oct, 2021 1 commit
  21. 12 Oct, 2021 1 commit
  22. 09 Oct, 2021 1 commit
  23. 07 Oct, 2021 2 commits
  24. 04 Oct, 2021 1 commit
  25. 01 Oct, 2021 1 commit
  26. 30 Sep, 2021 1 commit
  27. 27 Sep, 2021 1 commit
  28. 24 Sep, 2021 2 commits
  29. 22 Sep, 2021 1 commit
  30. 21 Sep, 2021 1 commit
    • Christian Kuhn's avatar
      [BUGFIX] Avoid dangling MM relations on workspace publish · e9069128
      Christian Kuhn authored
      When publishing workspace records with connected
      "true" MM relations (uid_local / uid_foreign columns
      and no TCA for that table), DataHandler triggers bugs:
      * It updates uid_local or uid_foreign rows to negative
        uids during the process as intermediate DB state.
      * It leaves "dangling" MM rows of the workspace record
        that has been pushed live.
      The involved code is relatively well encapsulated,
      it only kicks in for this "publish MM relations"
      scenario, the impact of this patch is limited to
      this area.
      The patch rewrites MM workspace publish handling:
      * Avoid parking state in a DataHandler class property
        only used in this scenario.
      * Avoid moving a list of stateful RelationHandler
        instances around and dynamically calling methods
        on those instances.
      * Avoid recursive flex form MM publish handling with
        indirect callback methods that change class state.
      * Obsolete a RelationHandler method used only in
        this scenario.
      * Reduce number of queries.
      The result is a simplified, better encapsulated and well
      commented solution. On a testing side, the patch brings
      a scenario to verify flex form MM relation handling.
      An according styleguide example is pending, too.
      This patch allows us to change auto created MM table
      definitions to unsigned uid_local and uid_foreign columns,
      which is of course the right way to go.
      Change-Id: I0d24f31cbd356f19937c2f8c18d432424e127b97
      Resolves: #95275
      Resolves: #81718
      Releases: master
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/71097
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Stefan Bürk's avatarStefan Bürk <stefan@buerk.tech>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Stefan Bürk's avatarStefan Bürk <stefan@buerk.tech>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
  31. 20 Sep, 2021 1 commit
  32. 18 Sep, 2021 1 commit
  33. 17 Sep, 2021 2 commits
  34. 16 Sep, 2021 2 commits
  35. 11 Sep, 2021 1 commit