Skip to content
Snippets Groups Projects
  1. Aug 27, 2021
    • Helmut Hummel's avatar
      [FEATURE] Consider all Composer installed extensions as active · 6cfc1a10
      Helmut Hummel authored
      The idea of this change is, that when using Composer,
      all TYPO3 extensions, that are part of the Composer
      installation, should be considered as active and there
      is no need whatsoever to install code of an
      extension with Composer (and making all its classes
      available), but not wanting the extension to interact with
      TYPO3 API.
      
      Therefore with this change, all TYPO3 extensions installed
      with Composer are considered to be active (and therefore can
      and will interact with TYPO3 API).
      
      Additionally, since the list of active extension is known
      during Composer installation, a persistent artefact is
      created at this point, which represents the final state
      of TYPO3 extension packages for the PackageManager,
      making both, the PackageStates.php file and the
      PackageManager cache obsolete for Composer managed
      TYPO3 installations.
      
      Note any extension present in the typo3conf/ext folder,
      but not installed by Composer, will still
      be considered and marked as part of TYPO3 packages when
      doing a "composer install". The only requirement here is,
      that such extensions need a composer.json file nonetheless.
      Note this behaviour is deprecated and will be removed
      with TYPO3 12.
      
      Additionally the extension manager UI is adapted to
      not allow changing the active state of extensions anymore.
      Respectively the commands "extension:activate" and
      "extension:deactivate" are disabled in Composer managed
      systems as well.
      
      A new cli command "extension:setup" is introduced, which
      supersedes both, the extension manager UI as well as the
      activate/deactivate commands. It performs all steps that
      were done before, except changing the active state of an
      extension.
      
      With cli command "extension:setup" ALL extensions are
      set up in terms of database schema changes, static data
      import, distribution files imports, etc.
      
      Last but not least, any installed Composer package, that
      defines an extra.typo3/cms section in their composer.json file,
      but is not of type "typo3-cms-extension" at the same time,
      will be considered for TYPO3 and will have full access
      to TYPO3 API. It has to be noted though that such packages
      can not deliver public resources. This remains exclusive for
      TYPO3 extensions for now.
      
      Releases: master
      Resolves: #94996
      Change-Id: I919873dd4ddd087c943f1289a12253c6acec7fa4
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69174
      
      
      Tested-by: default avatarBenjamin Franzke <bfr@qbus.de>
      Tested-by: default avatarJochen <rothjochen@gmail.com>
      Tested-by: default avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: default avatarHelmut Hummel <typo3@helhum.io>
      Tested-by: default avatarcore-ci <typo3@b13.com>
      Reviewed-by: default avatarBenjamin Franzke <bfr@qbus.de>
      Reviewed-by: default avatarJochen <rothjochen@gmail.com>
      Reviewed-by: default avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: default avatarHelmut Hummel <typo3@helhum.io>
      6cfc1a10
  2. Aug 10, 2021
  3. Jul 19, 2021
  4. Jun 30, 2021
    • Christian Kuhn's avatar
      [FEATURE] Extbase Request implements ServerRequestInterface · 8fde6812
      Christian Kuhn authored
      The patch changes the extbase Mvc/Request to implement
      PSR-7 ServerRequestInterface: The former extbase request
      details like 'controllerAction' are changed to an
      PSR-7 attribute and the Request class is now a
      decorator - it receives the original PSR-7 request
      as constructor argument, then implements both the
      extbase RequestInterface plus PSR-7 ServerRequestInterface.
      
      This way, the Request object itself does not hold
      state (except the original request), but channels
      all get* and with* calls to the PSR-7 request object.
      This avoids creating a new standalone object and moving
      all data from the PSR-7 object into the new object.
      
      The patch is relatively conservative. The extbase
      related set* methods are kept even though they're
      all @internal and violate immutability, and various
      method signatures are not adapted towards strict
      typing, yet. The reason for that are various
      chain- and loop dependencies especially in fluid view
      that should be solved with single patches before extbase
      Request can be streamlined further. Current usages also
      rely on fallback layers within __construct(), which can
      be solved when consuming places are adapted - The patch
      would have become much bigger if that would be mixed in.
      
      Change-Id: I218de0ee30d16245e7d562d0aba2795ccc439901
      Resolves: #94428
      Releases: master
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69545
      
      
      Tested-by: default avatarcore-ci <typo3@b13.com>
      Tested-by: default avatarOliver Bartsch <bo@cedev.de>
      Tested-by: default avatarBenni Mack <benni@typo3.org>
      Reviewed-by: default avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: default avatarBenni Mack <benni@typo3.org>
      8fde6812
  5. Jun 28, 2021
  6. Jun 21, 2021
  7. Jun 09, 2021
  8. Jun 01, 2021
  9. May 31, 2021
  10. May 04, 2021
  11. Apr 27, 2021
  12. Apr 21, 2021
  13. Apr 20, 2021
  14. Mar 12, 2021
  15. Mar 11, 2021
  16. Jan 26, 2021
  17. Jan 04, 2021
  18. Oct 29, 2020
  19. Sep 26, 2020
  20. Aug 13, 2020
  21. Apr 16, 2020
  22. Apr 08, 2020
  23. Apr 07, 2020
  24. Apr 02, 2020
  25. Mar 27, 2020
  26. Mar 23, 2020
  27. Mar 20, 2020
  28. Mar 08, 2020
  29. Mar 06, 2020
  30. Mar 02, 2020
  31. Feb 28, 2020
  32. Feb 27, 2020
  33. Feb 23, 2020
  34. Feb 21, 2020
    • Alexander Schnitzler's avatar
      [TASK] Ignore phpstan errors to achieve level 0 compatibility · 6f136584
      Alexander Schnitzler authored
      This patch ignores several errors found by phpstan which are
      not easy to solve as of now or which are not solvable at all.
      
      - Unsafe usage of new static
      
        Those errors can be solved in different ways. Making classes
        final, making constructors final or using new self. Which
        solution is used has to be decided by people who are familiar
        which the affected files.
      
      - Call to an undefined method in AbstractWidgetViewHelper and
        AbstractViewHelper
      
        Those issues aren't solvable as those methods exist if users
        choose fluid ^3.
      
      - Access to undefined constant TYPO3\CMS\Core\Type\Enumeration
        ::__default
      
        This issue can't be solved as the Enumeration class does a
        lot of magic stuff which isn't compatible with static code
        analysis.
      
      Releases: master
      Resolves: #90402
      Change-Id: Ie4a1623d42cb37d30082275ca1a09a733301d06e
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/63276
      
      
      Reviewed-by: default avatarMathias Brodala <mbrodala@pagemachine.de&gt;...>
      6f136584
  35. Feb 19, 2020
  36. Feb 15, 2020
  37. Jan 17, 2020