1. 02 Dec, 2021 1 commit
  2. 15 Nov, 2021 1 commit
    • Simon Gilli's avatar
      [TASK] Move Composer package artifact to vendor folder · d87cc4f5
      Simon Gilli authored and Benni Mack's avatar Benni Mack committed
      Storing the package artifact in the var/build folder raised
      questions how this folder shall be treated in general and during
      deployment. Since the Package Artifact is built in
      a `composer install` process, it should be treated the same as
      other build artifacts like all files in the vendor folder.
      To make this more clear, the package artifact is now also stored in
      the vendor folder.
      Accessing the vendor folder during runtime is now possible with
      using Composer 2.1 runtime API, which is required anyway already.
      The path to the vendor folder is determined indirectly, by using
      the path to the typo3/cms-composer-installers package. This means,
      this package must not be replaced by another package with a different
      name. Since no public replacements for this package exist and
      there are no benefits for a private replacement of this package over
      having a private fork with the same package name,
      this should not be an impediment.
      To ease the required related changes in the testing framework,
      late static binding is used for calling
      Resolves: #95897
      Releases: master
      Change-Id: I3cfc982c289b312d22f59d2704d7e7932efc8cc1
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/72071
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Oliver Hader's avatarOliver Hader <oliver.hader@typo3.org>
      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>
  3. 12 Oct, 2021 1 commit
  4. 19 Dec, 2020 1 commit
  5. 01 Dec, 2020 1 commit
  6. 28 Nov, 2020 1 commit
    • Christian Kuhn's avatar
      [TASK] Introduce constant 'TYPO3' · aa4bd8ad
      Christian Kuhn authored
      TYPO3 still has some script files that run in global scope
      without class or callable encapsulation. Those are especially
      ext_localconf.php, ext_tables.php and Configuration/TCA/Overrides/*
      script files.
      When those files are located within document root, they can be
      called directly via HTTP and may output something, which can be
      a security risk. To prevent this, they have a call at the very
      start: 'defined('TYPO3_MODE') or die();'.
      Unfortunately, constant 'TYPO3_MODE' is a technical debt, core
      tries to phase it out in v11. We thus need something equivalent
      for these calls.
      Since that test for existance of a constant is so simple and
      straight forward, the solution is to define a new constant to
      true, simply named 'TYPO3', to substitute 'TYPO3_MODE'. The
      call is very similar: 'defined('TYPO3') or die();'.
      The patch targets core master and v10: Having that constant in
      v10 simplifies life of extension developers who want to deliver
      extensions compatible with v10 and v11 in the same version, when
      'TYPO3_MODE' constant is deprecated in v11 with upcoming patches.
      Resolves: #92948
      Related: #92947
      Releases: master, 10.4
      Change-Id: Ib7b438422a41e242cf49cd4f87a6f8c50a9907d3
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66937
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
  7. 26 Sep, 2020 1 commit
  8. 26 May, 2020 1 commit
  9. 28 Apr, 2020 1 commit
  10. 15 Apr, 2020 1 commit
  11. 14 Apr, 2020 1 commit
  12. 23 Mar, 2020 1 commit
  13. 21 Mar, 2020 1 commit
  14. 15 Mar, 2020 1 commit
  15. 08 Mar, 2020 1 commit
  16. 14 Feb, 2020 1 commit
  17. 10 Jan, 2020 1 commit
  18. 09 Jan, 2020 1 commit
  19. 30 Dec, 2019 2 commits
  20. 15 Dec, 2019 1 commit
    • Benni Mack's avatar
      [TASK] Thin out SystemEnvironmentBuilder · 05f6e212
      Benni Mack authored and Susanne Moog's avatar Susanne Moog committed
      This a pre-patch to clean up the functionality of the SystemEnvironmentBuilder,
      which was originally introduced as part of the Bootstrap logic in 6.0.
      However, a few cross-concerns can be cut in TYPO3 v10:
      - Calling the deprecated GeneralUtility::presetApplicationContext() is not
      needed anymore, as it can be populated on-demand when the deprecated
      GeneralUtility::getApplicationContext() method is called via Environment API.
      This way, the ApplicationContext initialization can be put directly in the
      Environment API initialization call.
      - The static "isFunctionDisabled" method with a nasty runtime cache is only
      used in one place in backend, so does not belong to "building system environment",
      and is therefore removed.
      - The now unused "exitWithMessage" protected method is removed,
      removing a dependency to the HttpUtility class.
      Resolves: #89943
      Releases: master
      Change-Id: I31156b1a1ded306d99bcf2d51de43bc919a0b3e0
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/62628
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Daniel Goerz's avatarDaniel Goerz <daniel.goerz@posteo.de>
      Tested-by: Susanne Moog's avatarSusanne Moog <look@susi.dev>
      Reviewed-by: Daniel Goerz's avatarDaniel Goerz <daniel.goerz@posteo.de>
      Reviewed-by: Susanne Moog's avatarSusanne Moog <look@susi.dev>
  21. 03 Dec, 2019 2 commits
  22. 07 Oct, 2019 1 commit
  23. 01 Oct, 2019 2 commits
  24. 23 Aug, 2019 1 commit
  25. 23 Jul, 2019 2 commits
  26. 11 Jul, 2019 1 commit
  27. 08 Jun, 2019 1 commit
  28. 07 Mar, 2019 1 commit
  29. 01 Feb, 2019 1 commit
  30. 22 Jan, 2019 1 commit
  31. 11 Jan, 2019 2 commits
  32. 09 Jan, 2019 2 commits
  33. 20 Dec, 2018 1 commit
  34. 19 Dec, 2018 1 commit