1. 13 Jan, 2022 1 commit
  2. 12 Jan, 2022 1 commit
    • Christian Kuhn's avatar
      [TASK] Simplify Templating Bootstrap in BE Controllers · 37ac299f
      Christian Kuhn authored
      This patch introduces a new EXT:fluid view class
      "BackendTemplateView" to be used as main view for
      backend-related non-Extbase views.
      This class is the base of a new non-Extbase and
      non-request dependent backend view. The class is for
      now marked @internal and experimental since we'll
      probably add a factory to configure backend template
      overrides for any backend view later-on.
      A few ViewHelpers are changed to work without
      accessing the request if enough VH arguments are provided.
      This is the first patch in a series of patches that will
      switch from StandaloneView usages in backend
      controllers to this new BackendTemplateView.
      Basic strategy:
      * $view->getRequest()->setControllerExtensionName('SysNote')
        is removed. This is Extbase-specific and not needed nor
        wanted for common non-Extbase controllers.
      * Instantiate the View (for now with makeInstance, will be
        replaced with a factory later-on)
      * Set the needed paths via ->setTemplateRootPaths() etc.
        For these, we *always* use the main extension's entry
        templating paths, for instance
        'EXT:sys_note/Resources/Private/Templates' or
        We do *not* use sub directories here to clear up path
      * ->assign() / ->assignMultiple() whatever is needed.
      * ->render('SubDirectory/TemplateName') the actual
        action / template, no '.html' suffix.
      As a demo, EXT:sys_note is adapted accordingly which hands
      over arguments to the above mentioned VH's in a way so
      these don't access the request object anymore. The sys_note
      code gets a couple of additional changes so the hooks can
      prepare request dependent arguments and set them as
      template variables (here: returnUrl).
      This patch triggers a hidden gem: Since ViewHelpers no
      longer receive an Extbase request, they also don't trigger
      Extbase magic anymore. The casual victim here is
      f:translate, which has already been prepared to not trigger
      Extbase's frontend TypoScript parsing if there is no
      Extbase request. This often improves backend view performance
      by 25% or more, depending on the amount of frontend
      TypoScript to parse.
      Further patches will adapt other core backend routes and will
      relate to this patch for reference.
      Change-Id: I4fec3ad690452a00e731c9f6928273048397dd89
      Resolves: #96513
      Related: #96473
      Releases: main
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/72966
      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>
      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>
  3. 27 Nov, 2021 1 commit
  4. 24 Sep, 2021 1 commit
  5. 28 Jul, 2021 1 commit
  6. 14 May, 2021 1 commit
  7. 20 Nov, 2020 1 commit
  8. 18 Sep, 2020 1 commit
  9. 30 Aug, 2020 1 commit
    • Daniel Windloff's avatar
      [TASK] Migrate RecordListController hooks to an PSR-14 event · ff67726f
      Daniel Windloff authored and Anja Leichsenring's avatar Anja Leichsenring committed
      The following hooks in the RecordListController are used to add
      additional content above or below the main controller content:
      As this functionality could be useful, it should be migrated to a
      PSR-14 event. Both hook implementations use a meaningful parameter
      set (the request object) and return the additional content as string.
      As there is no dependency to the parent object (the class instance of
      the class where the hooks are placed), they could be migrated to a
      psr-14 event without a breaking change.
      Therefore, a PSR-14 event has been implemented to replace the hook
      functionality. An event listener has been created to provide a
      compatibility layer for both hooks. This allows a proper deprecation
      without breaking the hooks.
      The event listener (compatibility layer) could be removed in later
      versions without any changes in the controller class.
      Releases: master
      Resolves: #92062
      Change-Id: I50e4897bae256ec165861bccd8356db107c78962
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65401
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
  10. 17 Apr, 2020 1 commit
  11. 15 Apr, 2020 1 commit
  12. 14 Apr, 2020 1 commit
  13. 13 Apr, 2020 1 commit
  14. 15 Feb, 2020 1 commit
  15. 29 Jan, 2019 1 commit
  16. 01 Oct, 2018 1 commit
  17. 10 Sep, 2018 1 commit
  18. 09 Sep, 2018 1 commit
  19. 17 May, 2018 1 commit
  20. 17 Mar, 2018 1 commit
  21. 03 Mar, 2018 1 commit
  22. 28 Feb, 2018 1 commit
  23. 18 Dec, 2017 1 commit
  24. 07 Dec, 2017 1 commit
  25. 30 Nov, 2017 1 commit
  26. 04 Oct, 2017 1 commit
    • Benni Mack's avatar
      [!!!][TASK] Use native trigger_error and ErrorHandler for deprecations · 95b13dca
      Benni Mack authored and Christian Kuhn's avatar Christian Kuhn committed
      The native PHP way of triggering deprecations by a framework or
      applications is done via
      `trigger_error($deprecationMessage, E_USER_DEPRECATED)`.
      Previously, TYPO3 used `GeneralUtility::deprecationLog()` and
      similar methods to generate a custom deprecation log, however it's
      more flexible to use native logging through TYPO3's ErrorHandler.
      This solution centralizes the way to configure the place if and
      how deprecation logs should be written to various log destinations.
      This also changes the way how deprecated methods, arguments and classes
      are handled.
      The new way to deprecate code in TYPO3 is done via
      `trigger_error()`, the @deprecated annotation within a method only
      exists now for IDE support, but is not reflected anymore for the
      logging message.
      That's why the @deprecated annotation does not contain
      a description anymore.
      The methods
      are marked as deprecated from now on.
      The configuration option $TYPO3_CONF_VARS[SYS][enableDeprecationLog]
      is removed.
      Deprecation messages can now be activated by adding
      the E_USER_DEPRECATED constant to the respective values in
       (so exceptions are handled by the TYPO3 error handler)
       (so exceptions are put into GeneralUtility::sysLog)
       (so exceptions are put into sys_log DB table)
       (so exceptions are thrown on a deprecation)
      Deprecations will still go into GeneralUtility::devLog(),
      if deprecations are activated via the "errorHandlerErrors" option.
      Tests which test explicitly for deprecated code is moved into
      Tests/UnitDeprecated, to ensure that the deprecated code is not
      throwing an exception.
      Resolves: #82438
      Releases: master
      Change-Id: I6ef9a642d179001f0484c4c7678e0bec12284faf
      Reviewed-on: https://review.typo3.org/54015
      Reviewed-by: Susanne Moog's avatarSusanne Moog <susanne.moog@typo3.org>
      Tested-by: Susanne Moog's avatarSusanne Moog <susanne.moog@typo3.org>
      Tested-by: default avatarTYPO3com <no-reply@typo3.com>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
  27. 20 Sep, 2017 1 commit
  28. 14 Aug, 2017 1 commit
  29. 28 Mar, 2017 1 commit
    • Wouter Wolters's avatar
      [TASK] Streamline return tags in phpdocs · eb049dba
      Wouter Wolters authored and Benni Mack's avatar Benni Mack committed
      The TYPO3 Core currently has no guidline how to handle phpdoc
      comments regarding @return annoations related to "void" and "null".
      In practice, these annotations have no additional value if no additional
      documentation is given.
      With this change, the php-cs-fixer will remove any unnecessary linebreaks
      within the comments above the @return annotation, as well as remove completely
      empty phpdoc comments because the @return annotation is removed.
      Please be aware, that once PSR-5 is accepted, this coding standard
      within the TYPO3 Core will change again, where there are currently
      some further proposal details like inheritance information.
      Resolves: #80454
      Releases: master
      Change-Id: Ie969d720684c0a75919fe5addd1c36ef5b12eb04
      Reviewed-on: https://review.typo3.org/51686
      Reviewed-by: Nicole Cordes's avatarNicole Cordes <typo3@cordes.co>
      Tested-by: Nicole Cordes's avatarNicole Cordes <typo3@cordes.co>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
  30. 26 Oct, 2016 2 commits
  31. 30 Aug, 2016 1 commit
  32. 24 Jul, 2016 1 commit
  33. 03 Jun, 2016 1 commit
  34. 20 Apr, 2016 1 commit
  35. 19 Apr, 2016 1 commit
  36. 18 Apr, 2016 1 commit
  37. 14 Apr, 2016 1 commit
  38. 07 Apr, 2016 1 commit
  39. 29 Jan, 2016 1 commit