1. 20 Sep, 2021 1 commit
  2. 18 Sep, 2021 1 commit
  3. 17 Sep, 2021 1 commit
  4. 16 Sep, 2021 2 commits
  5. 11 Sep, 2021 2 commits
  6. 01 Sep, 2021 1 commit
  7. 08 Aug, 2021 1 commit
  8. 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
  9. 03 Aug, 2021 1 commit
  10. 02 Aug, 2021 2 commits
  11. 29 Jul, 2021 2 commits
  12. 28 Jul, 2021 1 commit
  13. 22 Jul, 2021 2 commits
  14. 16 Jul, 2021 1 commit
  15. 15 Jul, 2021 1 commit
  16. 12 Jul, 2021 2 commits
  17. 30 Jun, 2021 1 commit
  18. 21 Jun, 2021 1 commit
  19. 16 Jun, 2021 1 commit
  20. 15 Jun, 2021 1 commit
  21. 25 May, 2021 1 commit
  22. 14 May, 2021 2 commits
  23. 07 May, 2021 1 commit
  24. 05 May, 2021 1 commit
  25. 04 May, 2021 1 commit
  26. 01 May, 2021 1 commit
  27. 27 Apr, 2021 2 commits
  28. 20 Apr, 2021 1 commit
  29. 09 Apr, 2021 1 commit
  30. 01 Apr, 2021 1 commit
  31. 28 Mar, 2021 1 commit
  32. 25 Mar, 2021 1 commit
    • Philipp Parzer's avatar
      [BUGFIX] Add pid restriction when getting previousLocalizedRecord · d5366226
      Philipp Parzer authored and Christian Kuhn's avatar Christian Kuhn committed
      Scenario:
      A content element 'ce-1-default' exists on a 'source' page. It
      has a 'free mode' localization 'ce-1-localized'. The localized
      content element thus has l18n_parent=0 (free mode) and
      l10n_source='id-of-ce-1-default' - it has been derived from
      'ce-1-default'.
      
      Now 'ce-1-default' is moved to a different 'target' page. Due to
      free mode, 'ce-1-localized' is NOT moved along with it's localization
      source, but keeps l10n_source='id-of-ce-1-default' (this needs to be
      discussed if we change this) and stays on 'source' page. This is ok.
      
      Now, a new content element 'ce-2-default' is added on 'target' page,
      right below the previously moved 'ce-1-default'. And then, this
      element is localized.
      
      DataHandler now tries to find out where to create this localized
      'ce-2-localized' record relative to other records. It finds the
      localization 'ce-1-localized' due to its l10n_source indicator
      and then creates 'ce-2-localized' after 'ce-1-localized'. On the
      source page!
      So the content element localization ends up on a different page,
      which is of course wrong, misleading and hard to understand!
      
      To fix this, the Datahandler now finds translated content elements
      of a given content element only if it is on the same page. This
      keeps this 'relative-to' magic, and the content element does not
      end up on some foreign page.
      
      Resolves: #92783
      Resolves: #92198
      Releases: master, 10.4
      Change-Id: I104a4b2d59322ec55ad96e37e8d1b3c3fed0e515
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66552
      
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      d5366226