1. 22 Dec, 2020 1 commit
  2. 21 Dec, 2020 1 commit
  3. 19 Dec, 2020 1 commit
  4. 14 Dec, 2020 2 commits
    • Alexander Schnitzler's avatar
      [TASK] Deprecate @Extbase\Inject · 64c8a784
      Alexander Schnitzler authored and Benjamin Franzke's avatar Benjamin Franzke committed
      Since core dependency injection is in place and is about to
      replace the extbase dependency injection, marking properties
      with the @Extbase\Inject annotation to invoke property injection is
      deprecated and must be replaced by one of the following di
      methods:
      
      - constructor injection: works both with core and extbase di
        and is well suited to make extensions compatible for multiple
        TYPO3 versions.
      
      - setter injection: Basically the same like constructor injection.
        Both the core and extbase di can handle setter injection and
        both are supported in different TYPO3 versions.
      
      - (core) property injection: This kind of injection can be used
        but it requires the configuration of services via a Services.yaml
        in the Configuration folder of an extension.
      
      The recommended way is constructor injection. Not only is it the
      most compatible version of di, it also brings the advantage of
      clearly showing dependencies of a class. Also, it quickly shows
      if dependencies stack up which indicates that the service should
      be refactored.
      
      Releases: master
      Resolves: #92386
      Change-Id: I61afbb6bb15b136c200849c6c8f2cd6211d4c306
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65835
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      Tested-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
      Reviewed-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      Reviewed-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
      64c8a784
    • Benni Mack's avatar
      [BUGFIX] DBAL: Do not use deprecated classes · b2a22815
      Benni Mack authored and Christian Kuhn's avatar Christian Kuhn committed
      In preparation for Doctrine DBAL 3.0,
      
      1. all usages of Doctrine\DBAL\DBALException have
      been migrated to Doctrine\DBAL\Exception,
      because DBAL Exception does not exist in
      Doctrine 3.0 anymore.
      
      2. Doctrine\DBAL\Platforms\PostgreSqlPlatform
      has been migrated to Doctrine\DBAL\Platforms\PostgreSQL94Platform
      because this class does not exist anymore in Doctrine DBAL 3.0,
      same goes for Doctrine\DBAL\Platforms\SQLServerPlatform
      which has been replaced by Doctrine\DBAL\Platforms\SQLServer2012Platform
      
      3. Doctrine\DBAL\Driver\PDOException has been
      renamed to Doctrine\DBAL\Driver\PDO\Exception
      
      4. Doctrine\DBAL\Driver\PDOStatement has been
      renamed to Doctrine\DBAL\Driver\PDO\Statement
      
      Resolves: #93071
      Releases: master
      Change-Id: I05e82f2fca09eb7718a90c09f95e503980ae10ae
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67109
      
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      b2a22815
  5. 10 Dec, 2020 2 commits
  6. 09 Dec, 2020 3 commits
  7. 08 Dec, 2020 3 commits
  8. 05 Dec, 2020 3 commits
  9. 01 Dec, 2020 1 commit
  10. 30 Nov, 2020 2 commits
  11. 29 Nov, 2020 1 commit
  12. 20 Nov, 2020 1 commit
  13. 16 Nov, 2020 2 commits
  14. 13 Nov, 2020 1 commit
  15. 12 Nov, 2020 1 commit
    • Benni Mack's avatar
      [!!!][TASK] Do not create new version placeholders in workspaces anymore · 74899ecf
      Benni Mack authored
      Creating a new record in a workspace adds two database rows.
      
      One that is the "placeholder", which - since v10.4 - contains
      the same metadata as the other record:
      
      * t3ver_wsid = workspaceID
      * t3ver_oid = 0 (simulating behavior of an "online pendant record")
      * t3ver_state = 1
      
      And the "versionized" record, identified by:
      
      * t3ver_wsid = workspaceID
      * t3ver_oid = uid of the new placeholder record
      * t3ver_state = -1
      
      As of TYPO3 v10, the first record is not needed anymore,
      the versioned record can be queried directly, however, since
      the relations (except MM) point to the placeholder record,
      this one is kept.
      
      As result, only one record is created from now on:
      
      * t3ver_wsid = workspaceID
      * t3ver_oid = 0 (no online counterpart)
      * t3ver_state = 1
      
      On reading, the record is queried directly (no overlay needed anymore!)
      with the existing Database Doctrine Restrictions. On publishing, the
      record just gets the state/stage/wsid set and is "live".
      
      This brings fundamental benefits:
      
      * No overlays needed when querying
      * Fewer database records (placeholders are not helpful)
      * Conceptual problems with placeholder and shadowed fields are removed
      
      Resolves: #92791
      Releases: master
      Change-Id: I0288cc63fe72d8442d586f309bd4054ac44e829b
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65587
      
      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: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-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>
      74899ecf
  16. 10 Nov, 2020 1 commit
  17. 06 Nov, 2020 1 commit
    • Alexander Schnitzler's avatar
      [!!!][TASK] Make Extbase handle PSR-7 responses only · 23b09b8f
      Alexander Schnitzler authored and Daniel Goerz's avatar Daniel Goerz committed
      With this patch, Extbase does no longer handle/return
      extbase responses whose api was defined by the extbase
      ResponseInterfacer. Instead, Extbase does create a PSR-7
      compatible response object and passes it back through
      the request handling stack.
      
      Since PSR-7 requires response objects to be immutable,
      the response object is no longer accessible as property
      of class ActionController. It is also no longer accessible
      through the ControllerContext class. In fact, the response
      is completely hidden from the user and can no longer be
      changed.
      
      To address this issue, an upcoming patch will enable users
      to return user controlled responses from within controller
      actions instead of just returning content strings. User will
      then be forced to return response objects with the content
      and all necessary headers, such as the content-type, set.
      
      Since the Response class has been deleted, it is no longer
      usable in user land code. It should be replaced with PSR-7
      compatible response objects to stay compatible with response
      handlers of both the core and extbase.
      
      Releases: master
      Resolves: #92502
      Change-Id: I4d5dc1478be6dd25b43f6249139eeb4ce5cc3094
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66070
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Daniel Goerz's avatarDaniel Goerz <daniel.goerz@posteo.de>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Daniel Goerz's avatarDaniel Goerz <daniel.goerz@posteo.de>
      23b09b8f
  18. 05 Nov, 2020 1 commit
  19. 04 Nov, 2020 2 commits
  20. 03 Nov, 2020 1 commit
  21. 01 Nov, 2020 1 commit
    • Benni Mack's avatar
      [TASK] Use Symfony Routing for Backend Routing · 73bcf9a1
      Benni Mack authored and Georg Ringer's avatar Georg Ringer committed
      This is a pre-cursor for enhancing Backend Routing in general.
      
      This change implements Symfony Routing for Backend
      Routes (currently based on the "route" GET/POST argument)
      internally to make use of their compiled routes later-on.
      
      This was previously done in a simplified version where only
      the path was checked against, and most Symfony features
      were not in use, which we still don't use yet, but more can now
      be added.
      
      When Backend Routing was added in TYPO3 v7, the API
      was heavily influenced by Symfony but we did not have
      a lot of experience yet, which we benefitted in TYPO3 v9+
      for Frontend Routing.
      
      With this experience (and with PSR-15) we can gradually
      move to a more streamlined and faster API.
      
      The proposed solution still works as expected with &route
      GET parameters, but opens up the door for flexible Route arguments.
      
      Resolves: #92723
      Releases: master
      Change-Id: I48475fcb3cc15f99cc102dac36ae15bca9f3032e
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66316
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Tested-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      73bcf9a1
  22. 28 Oct, 2020 2 commits
  23. 27 Oct, 2020 1 commit
  24. 25 Oct, 2020 1 commit
  25. 23 Oct, 2020 1 commit
    • Alexander Schnitzler's avatar
      [!!!][TASK] Request processing chain must return a response object · 723cacda
      Alexander Schnitzler authored and Benni Mack's avatar Benni Mack committed
      This patch introduces a proper request/response handling chain. That
      means, that Extbase no longer creates a response object early, passes
      it through the request handler and dispatcher into the controller and
      expects it to be altered there.
      
      Instead, request handlers, the dispatcher and controllers only get
      passed a request object and controllers are then responsible for
      creating and returning a response.
      
      This change is preparatory work for the introduction of PSR-7 responses
      in Extbase. Those responses are immutable and can no longer passed by
      reference through the stack. Instead, the controller must return the
      desired response along with its state down the stack while remaining
      unaltered.
      
      This patch is considered breaking because it changes several method
      signatures of public classes and interfaces.
      
      Still, it is quite unlikely to be struck by this change when using
      the public api of Extbase and not overriding classes such as the
      ActionController.
      
      Releases: master
      Resolves: #92513
      Change-Id: I3ab7846268ea68727a2f57eea69328b85be4f5e6
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66079
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      723cacda
  26. 21 Oct, 2020 1 commit
  27. 20 Oct, 2020 1 commit
  28. 19 Oct, 2020 1 commit