1. 25 May, 2022 1 commit
  2. 03 Mar, 2022 1 commit
  3. 23 Feb, 2022 1 commit
  4. 22 Feb, 2022 1 commit
    • Christian Kuhn's avatar
      [TASK] Allow DI for extbase validators · 78fa14c1
      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/+/73631
      
      
      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>
      Tested-by: Stefan Bürk's avatarStefan Bürk <stefan@buerk.tech>
      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>
      Reviewed-by: Stefan Bürk's avatarStefan Bürk <stefan@buerk.tech>
      78fa14c1
  5. 30 Jan, 2022 1 commit
  6. 22 Dec, 2021 1 commit
  7. 04 Dec, 2021 1 commit
  8. 03 Dec, 2021 1 commit
  9. 02 Dec, 2021 2 commits
  10. 01 Dec, 2021 1 commit
  11. 21 Sep, 2021 1 commit
  12. 16 Sep, 2021 1 commit
  13. 11 Sep, 2021 1 commit
  14. 10 Sep, 2021 1 commit
  15. 09 Sep, 2021 1 commit
  16. 26 Aug, 2021 1 commit
  17. 25 Aug, 2021 1 commit
  18. 23 Jul, 2021 1 commit
  19. 22 Jul, 2021 1 commit
  20. 12 Jul, 2021 1 commit
  21. 30 Jun, 2021 3 commits
  22. 22 Jun, 2021 1 commit
  23. 18 Jun, 2021 1 commit
  24. 15 Jun, 2021 1 commit
  25. 14 Jun, 2021 1 commit
  26. 30 May, 2021 1 commit
  27. 28 May, 2021 1 commit
  28. 18 May, 2021 1 commit
  29. 14 May, 2021 1 commit
  30. 07 May, 2021 1 commit
  31. 07 Jan, 2021 1 commit
    • Benjamin Franzke's avatar
      [BUGFIX] Use PSR-17 interfaces in Extbase · 71884c8f
      Benjamin Franzke authored
      In order to strengthen TYPO3's focus on PSR standards, this change
      uses PSR-17 interfaces instead of the custom ResponseFactoryInterface
      which was added solely for extbase in #92784.
      
      The interface was added as part of the #92784 deprecation, but it
      actually contradicts with the ideas of interchangable PSR interfaces
      and therefore we strive for native PSR-17 usage, instead of wrapping
      PSR interfaces, now.
      The Extbase ActionController::htmlResponse() method – which was
      suggested to be used by #92784 – is kept as is (functionality wise [1]),
      and since the interface was injected into the ActionController using a
      final method, the impact of this switch is very low.
      
      Concrete implementations of PSR interfaces are always internal api,
      threfore also TYPO3\CMS\Core\Http\Response is switched back to be
      marked as internal API.
      
      Furthermore TYPO3\CMS\Core\Http\JsonResponse properties do not need to
      be marked internal, as the entire class is internal.
      
      [1] ActionController::htmlResponse() is adapted to avoid rewinding()
          the response body, as every usage/respond is actually expected
          to rewind or use toString(), and therefore rewind() would be
          called twice. Only functional tests where buggy in not calling
          rewind() during test assertion.
      
      Releases: master
      Resolves: #93237
      Related: #92784
      Change-Id: I59e5a190eaa1f0dd62f08db34987c6d4a72b73c1
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67353
      
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Tested-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
      71884c8f
  32. 21 Dec, 2020 1 commit
  33. 09 Dec, 2020 1 commit
  34. 08 Dec, 2020 1 commit
  35. 05 Dec, 2020 1 commit
  36. 30 Nov, 2020 1 commit
  37. 20 Nov, 2020 1 commit