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>
      ed725d12
  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
      configurations.
      
      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>
      bf3eaa6c
  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
      overlay.
      
      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
      records.
      
      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
      workspaces.
      
      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>
      93279297
  10. 20 Nov, 2021 1 commit
  11. 15 Nov, 2021 1 commit
  12. 10 Nov, 2021 1 commit
  13. 04 Nov, 2021 1 commit
  14. 03 Nov, 2021 1 commit
  15. 02 Nov, 2021 1 commit
  16. 26 Oct, 2021 1 commit
  17. 24 Oct, 2021 1 commit
  18. 12 Oct, 2021 1 commit
  19. 07 Oct, 2021 2 commits
  20. 04 Oct, 2021 1 commit
  21. 30 Sep, 2021 1 commit
  22. 24 Sep, 2021 1 commit
  23. 22 Sep, 2021 1 commit
  24. 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>
      e9069128
  25. 20 Sep, 2021 1 commit
  26. 18 Sep, 2021 1 commit
  27. 17 Sep, 2021 1 commit
  28. 16 Sep, 2021 2 commits
  29. 11 Sep, 2021 2 commits
  30. 01 Sep, 2021 1 commit
  31. 08 Aug, 2021 1 commit
  32. 04 Aug, 2021 1 commit
    • Helmut Hummel's avatar
      [TASK] Quote database identifiers when used instead of globally upfront · 55b8185f
      Helmut Hummel authored
      The implementation of the bugfix https://review.typo3.org/53360
      was done by iterating over TCA during cache generation and
      correctly quoting SQL fragments that are provided, to after
      that store TCA in cache.
      
      This has disadvantages:
      
      1. A DB connection is required to create TCA cache:
      This makes efforts for warming up caches upfront impossible,
      as cache warmup should be able to be performed on build
      systems without DB connection.
      
      2. It separates code that executes a query from code that
      is preparing a query: Escaping arguments for a query in a
      different place than the actual query execution can be
      considered an anti pattern, because at other points it isn't
      clear in which context these values are used. Beside that,
      performing the actual query, undoing DB encoding and redoing
      a different encoding is impossible.
      
      Pre-processing / quoting identifiers upfront can be considered
      a similar anti pattern as well. Despite there are less use
      cases to perform operations on the original non quoted
      identifiers, post processing of such fields in an event
      is impossible with the current implementation.
      
      3. The current implementation being buggy and the adoption
      in TYPO3 is sparse: While this could be tackled with according
      fixes, it shows that this feature, that has been implemented
      a couple of years ago and is a technical burden, is rarely
      used, and therefore the implementation can be simplified and
      cleaned up.
      
      The patch drops this TCA preparation and field name escaping
      is now done in places where the queries are actually built.
      
      Strictly seen this is a breaking change for implementers of
      the TCA post processing event or for custom code that directly
      uses TCA to perform query parts.
      
      It is unlikely though that such code exists in userland,
      nonetheless a feature flag "runtimeDbQuotingOfTcaConfiguration"
      is introduced to allow extensions to also use the feature flag
      and use the quoting on demand if not done before.
      
      For TYPO3 v12, this feature flag will be enabled at all times.
      
      Releases: master
      Resolves: #94697
      Change-Id: Ie0e48054def29c6c1e2810c8d30528c719439d9f
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69507
      
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Helmut Hummel's avatarHelmut Hummel <typo3@helhum.io>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Helmut Hummel's avatarHelmut Hummel <typo3@helhum.io>
      55b8185f
  33. 03 Aug, 2021 1 commit
  34. 02 Aug, 2021 2 commits
  35. 29 Jul, 2021 1 commit