1. 06 May, 2022 1 commit
  2. 28 Mar, 2022 1 commit
  3. 05 Feb, 2022 1 commit
  4. 02 Feb, 2022 1 commit
  5. 28 Jan, 2022 1 commit
  6. 18 Jan, 2022 1 commit
    • Stefan Bürk's avatar
      [TASK] Use proper QueryBuilder execute() replacement methods · 597a92fd
      Stefan Bürk authored and Benni Mack's avatar Benni Mack committed
      doctrine/dbal implemented single purpose method to replace the
      compound 'execute()' in QueryBuilder to avoid the incompatible
      return typehint tuple of 'Doctrine\DBAL\Result|int' in favour
      of 'executeQuery()' and 'executeStatement()' which was added
      forward-compatible with #96247 marking the old one internal
      but not deprecated for now to keep a eventually longer grace
      period to mitigate for extensions developers.
      
      This patch however goes through the core and replace these
      methods to be clean as possible and is a first preparation
      to remove the 'checkThisOnly' option from phpstan which are
      swallowed by this option.
      
      * replace 'execute' with 'executeQuery()' for select and
        count queries generating results ('Doctrine\DBAL\Result').
      * use 'executeStatement()' for insert, update and delete
        queries return affected rows as return value (int)
      * adjust return typehints to match the single return type
        signature on really minor places to match the return type
        of the wrapped replaced execute method.
      * replace one really old 'exec()' from connection with
        corresponding replacement method along the way.
      * add several todos on two places which are weird and do
        not make any sense for further investigation and fixing,
        as declared as out-of-the-scope for this wide-area patch.
      
      Resolves: #96551
      Related: #96247
      Related: #96521
      Releases: main, 11.5
      Change-Id: Ie8d40f3882f1694ab7f7e5053729fa1c798a9c5f
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73032
      
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      597a92fd
  7. 08 Jan, 2022 1 commit
  8. 01 Dec, 2021 1 commit
  9. 24 Sep, 2021 1 commit
  10. 03 Sep, 2021 1 commit
    • Oliver Bartsch's avatar
      [FEATURE] Introduce AfterFileCommandProcessedEvent · 412df9f4
      Oliver Bartsch authored
      A new PSR-14 based event "AfterFileCommandProcessedEvent"
      is introduced in favour of the existing
      $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_extfilefunc.php']['processData']
      hook, which is now marked as deprecated, along with
      its interface "ExtendedFileUtilityProcessDataHookInterface".
      
      The new event features the same data, however
      the way they can be accessed is improved.
      
      The previous `$action` and `$cmdArr` arguments
      are now available within the `getCommand()` method,
      while the action is the array key and the command
      data ($cmdArr) is the value. This is more in line
      with the actual request.
      
      The hooks `$result` argument always contained all
      results of previous operations, making it unnecessary
      complicated to find out the actual result for the
      current operation. This is now resolved. The new
      `getResult()` method only returns the result for
      the currently executed operation.
      
      Finally the "getConflictMode()" method just returns
      the conflict mode, used for the current operation.
      
      Resolves: #95089
      Releases: master
      Change-Id: I9991eb73aed873da5987f88d2d0255764274e143
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70874
      
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Jochen's avatarJochen <rothjochen@gmail.com>
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Jochen's avatarJochen <rothjochen@gmail.com>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      412df9f4
  11. 29 Jul, 2021 1 commit
  12. 28 Jul, 2021 1 commit
  13. 22 Jul, 2021 1 commit
  14. 12 Jul, 2021 1 commit
  15. 06 Jul, 2021 1 commit
  16. 14 May, 2021 1 commit
  17. 12 Mar, 2021 1 commit
  18. 08 Dec, 2020 1 commit
  19. 30 Nov, 2020 1 commit
  20. 30 Sep, 2020 1 commit
  21. 16 Apr, 2020 1 commit
  22. 15 Apr, 2020 1 commit
  23. 14 Apr, 2020 1 commit
  24. 06 Mar, 2020 1 commit
  25. 28 Feb, 2020 1 commit
  26. 30 Jan, 2020 1 commit
  27. 09 Jan, 2020 1 commit
  28. 30 Dec, 2019 1 commit
  29. 18 Dec, 2019 1 commit
  30. 25 Oct, 2019 1 commit
  31. 07 Oct, 2019 1 commit
  32. 07 Aug, 2019 1 commit
  33. 17 Jul, 2019 1 commit
  34. 02 Sep, 2018 1 commit
  35. 27 Aug, 2018 1 commit
  36. 12 Jul, 2018 1 commit
    • Susanne Moog's avatar
      [!!!][SECURITY] Deny direct FAL commands for form definitions · f3445f96
      Susanne Moog authored and Oliver Hader's avatar Oliver Hader committed
      Before this change, form definitions have been persisted in regular
      `.yaml` files. In order to make the meaning and purpose of those
      files more explicit, the new file ending `.form.yaml` is introduced.
      
      Invocations of the file abstraction layer API for those form files
      have to be allowed explicitly by granting commands individually using
      `FilePersistenceSlot::allowInvocation`.
      
      New form definitions are created with the new file ending per default.
      An upgrade wizard renames existing form definitions that are stored in
      according storage folders (`allowedFileMounts`). In addition references
      in FlexForm of content elements are adjusted to the new file names as
      well - in case a form definition has been referenced before.
      
      The file list user interface disabled according direct actions for
      `.form.yaml` files or redirects those to the according form module.
      
      Using just `.yaml` instead of `.form.yaml` from site packages
      is deprecated. Using just `.yaml` instead of `.form.yaml` from
      file storages is not allowed anymore.
      
      Resolves: #84910
      Releases: master, 8.7
      Security-Commit: 444f9dc4f1902871391bd1f139d19b46a63a162f
      Security-Bulletin: TYPO3-CORE-SA-2018-003
      Change-Id: I456c03f745e614729cdbf2915efc6b5e6d11fc0f
      Reviewed-on: https://review.typo3.org/57561
      
      Reviewed-by: Oliver Hader's avatarOliver Hader <oliver.hader@typo3.org>
      Tested-by: Oliver Hader's avatarOliver Hader <oliver.hader@typo3.org>
      f3445f96
  37. 22 Jun, 2018 1 commit
  38. 25 Apr, 2018 1 commit
  39. 18 Mar, 2018 1 commit
  40. 19 Jan, 2018 1 commit