1. 07 Oct, 2021 1 commit
  2. 04 Oct, 2021 1 commit
  3. 30 Sep, 2021 1 commit
  4. 24 Sep, 2021 1 commit
  5. 22 Sep, 2021 1 commit
  6. 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
  7. 20 Sep, 2021 1 commit
  8. 18 Sep, 2021 1 commit
  9. 17 Sep, 2021 1 commit
  10. 16 Sep, 2021 2 commits
  11. 11 Sep, 2021 2 commits
  12. 01 Sep, 2021 1 commit
  13. 08 Aug, 2021 1 commit
  14. 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
  15. 03 Aug, 2021 1 commit
  16. 02 Aug, 2021 2 commits
  17. 29 Jul, 2021 2 commits
  18. 28 Jul, 2021 1 commit
  19. 22 Jul, 2021 2 commits
  20. 16 Jul, 2021 1 commit
  21. 15 Jul, 2021 1 commit
  22. 12 Jul, 2021 2 commits
  23. 30 Jun, 2021 1 commit
  24. 21 Jun, 2021 1 commit
  25. 16 Jun, 2021 1 commit
  26. 15 Jun, 2021 1 commit
  27. 25 May, 2021 1 commit
  28. 14 May, 2021 2 commits
  29. 07 May, 2021 1 commit
  30. 05 May, 2021 1 commit
  31. 04 May, 2021 1 commit
  32. 01 May, 2021 1 commit
  33. 27 Apr, 2021 1 commit