1. 02 Dec, 2021 4 commits
  2. 01 Dec, 2021 3 commits
  3. 30 Nov, 2021 4 commits
  4. 29 Nov, 2021 1 commit
  5. 28 Nov, 2021 4 commits
  6. 24 Sep, 2021 1 commit
  7. 16 Sep, 2021 1 commit
  8. 15 Sep, 2021 1 commit
    • Christian Kuhn's avatar
      [TASK] Deprecate ext:backend BackendTemplateView · 98267055
      Christian Kuhn authored
      The BackendTemplateView is a - usually Extbase backend
      module related - Fluid view that adds a default backend
      ModuleTemplate to render backend module content.
      That implementation has a couple of drawbacks:
      * Using BackendTemplateView hides a dependency to the
        request object by triggering a fallback in ModuleTemplate
        accessing $GLOBALS['TYPO3_REQUEST'].
      * Using $this->view->getModuleTemplate() is pretty ugly,
        controllers should work with the ModuleTemplateFactory
        instead and retrieve an instance of ModuleTemplate using
      * The level of indirection by having ModuleTemplate within
        the view class magically created makes controller actions
        harder to follow and understand.
      With extbase Request nowadays implementing ServerRequestInterface
      we can get rid of this indirection: Controllers should get an
      instance of ModuleTemplateFactory injected, receive the
      ModuleTemplate using ->create($request), and add further
      title and doc header related details using that instance.
      The patch changes ext:indexed_search, ext:extensionmanager and
      ext:form to do that, and deprecates BackendTemplateView.
      Change-Id: I613a560c8fc3c35343e31f397479f0c008a4a314
      Resolves: #95164
      Related: #92513
      Related: #94428
      Related: #94209
      Related: #93885
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70973
      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: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Jochen's avatarJochen <rothjochen@gmail.com>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
  9. 09 Sep, 2021 1 commit
  10. 08 Sep, 2021 1 commit
  11. 04 Sep, 2021 1 commit
  12. 03 Sep, 2021 2 commits
  13. 02 Sep, 2021 3 commits
  14. 26 Aug, 2021 1 commit
  15. 25 Aug, 2021 1 commit
  16. 23 Aug, 2021 1 commit
  17. 12 Aug, 2021 1 commit
    • Nikita Hovratov's avatar
      [FEATURE] Register SoftReference parsers via DI · 48810cb7
      Nikita Hovratov authored and Benni Mack's avatar Benni Mack committed
      The concept for registration and usage of soft reference parsers
      received a complete overhaul.
      Starting with the registration, it is now possible to register soft
      reference parsers by dependency injection in the extension's
      Services.(yaml|php) file. For this, the new tag name
      "softreference.parser" has been introduced. One has to provide the
      additional attribute "parserKey" to identify the parser. This
      replaces the old way of registering these parsers in the $GLOBALS
      array. If a parser is registered with the same key in both ways,
      the old way takes precedence for b/w compatibility.
      This comes with a completely new factory service class
      This classes' responsibilities are collecting all registered soft
      reference parsers and serving them to the consumer by calling the
      method "getSoftReferenceParser" with the desired parser key as the
      only argument. There is a compatibility layer for the old way of
      registration and for classes not implementing the new interface.
      Soft reference parsers now have to implement
      The interface defines the implementation of the "parse" method.
      The first 4 and the last parameter stay the same as in the old method
      "findRef". The remaining two parameters "spKey" and "spParams" have to
      be set with the "setParserKey" method, if they are needed. The key can
      be retrieved by using the "getParserKey" method.
      The different parser implementations in the old class
      TYPO3\CMS\Core\Database\SoftReferenceIndex have been extracted and
      moved into dedicated classes in the
      TYPO3\CMS\Core\DataHandling\SoftReference namespace. Missing tests
      for parsers other than "typolink" and "typolink_tag" are added.
      The method makeTokenID of SoftReferenceIndex has been moved into
      A parser can extend this abstract class, if this method is needed.
      The methods of BackendUtility "softRefParserObj" and
      "explodeSoftRefParserList" are now deprecated and the replacement
      should be used instead.
      Resolves: #94687
      Resolves: #94741
      Releases: master
      Change-Id: I460bfdd4478194fa4b4111fc44871f7225c6c084
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70177
      Tested-by: core-ci's avatarcore-ci <typo3@b13.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>
  18. 04 Aug, 2021 1 commit
  19. 02 Aug, 2021 1 commit
    • Christian Kuhn's avatar
      [TASK] Deprecate generic extbase domain classes · 3c78adc6
      Christian Kuhn authored
      Extbase provides a couple of generic domain repositories
      and models, especially frontend / backend users and
      groups. Those are flawed by design:
      The main issue is that domain models have to be specific
      for the domain they are used in. By definition, a generic,
      opinionated model can't be "correct" since the domain
      it is used in, is unique: It might be that a backend user
      email has to be set and the domain does not model
      anything but email and firstname?
      Many usages don't need backend groups attached to a
      backend user model at all, or if they need them, then
      maybe in a recursive presentation, or a specific order
      or something similar. Having a default group resolution
      is thus at least misleading, if not wrong, and can be a
      performance issue on top.
      A generic model can never foresee its usages. The existing
      models thus try to 1:1 adapt the database fields, which
      is also misleading since a domain model is not and should
      not be a direct representation of a database table. It
      would only be by chance if the generic models fit a
      specific domain.
      Similar issues exist with the repositories: The
      CategoryRepository for instance assumes it is a good
      idea to set respectStoragePid(false), which is most
      likely not the right thing for an extension use.
      In the end, whatever extbase delivers here, is most
      likely wrong and does not fit the problem domain.
      The patch keeps the 'experimental' FAL related models
      since those can be actually useful for extensions and
      their final fate has not been decided, yet. The other
      generic models, especially those with lots of properties
      are marked as deprecated with the patch.
      Change-Id: I06629fddd0258c517f3fa8bdf2e9c4b342be9678
      Resolves: #94654
      Related: #83296
      Releases: master
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70061
      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>
      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>
  20. 23 Jul, 2021 1 commit
  21. 18 Jun, 2021 1 commit
  22. 11 Jun, 2021 1 commit
  23. 29 May, 2021 1 commit
  24. 27 May, 2021 1 commit
    • Christian Kuhn's avatar
      [TASK] Deprecate ext:backend ModuleLayout view helpers · 5a456090
      Christian Kuhn authored
      A while after the PHP based ModuleTemplate API has been
      introduced back in 2015, a couple of fluid view helpers
      have been added to ext:backend as a second way to handle
      full backend module content like the doc header.
      It found an example use in ext:beuser.
      Development however stopped at this point, the provided
      view helpers are only a sub set of the PHP based API and
      they didn't find broader use within the core - all other
      backend modules stick to the ModuleTemplate based API.
      On a structural level, those view helpers are questionable:
      They move functionality to the view component which is
      arguably more a controller task. The ext:beuser module
      proofes this since it had to assign controller knowledge
      like the current action and controller name to the view
      in order to render the doc header module down and shortcut
      The patch drops usages of these view helpers in ext:beuser,
      plus the minor usages of the outer ModuleLayout view helper
      in ext:install and ext:belog, substitutes them with the
      PHP ModuleTemplate API within controllers, and deprecates
      the full set of ModuleLayout view helpers.
      The change sharpens our separation between controller and
      view: The "outer" module handling like doc header buttons
      and menus are tied to controller logic and should be
      located there, while the module body is rendered by a
      fluid view.
      As a bonus, a couple of issues within ext:beuser are
      fixed along the way, since they can now be easily solved
      and were rather hard to tackle with the view helper based
      * The beuser module now remembers state and jumps to
        for instance the group sub module when a user selected
        this last. This is now in line with many other backend
        modules that do the same.
      * Shortcuts to single user details work.
      * The main doc header drop down can now contain all possible
        sub modules, including those that are available only
        indirectly, for instance the single user details view.
        This is good when calling these from shortcuts.
      Change-Id: Idef3aa6975e97677c1da0cef57f70c855bd2ea9f
      Resolves: #94209
      Releases: master
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69269
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Tested-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Tested-by: Jochen's avatarJochen <rothjochen@gmail.com>
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Reviewed-by: Jochen's avatarJochen <rothjochen@gmail.com>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
  25. 01 May, 2021 1 commit
  26. 20 Nov, 2020 1 commit