This project is mirrored from Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
  1. 09 Jul, 2021 1 commit
  2. 01 Jul, 2021 1 commit
  3. 30 Jun, 2021 2 commits
  4. 29 Jun, 2021 1 commit
  5. 28 Jun, 2021 2 commits
  6. 22 Jun, 2021 1 commit
  7. 18 Jun, 2021 2 commits
    • Christian Kuhn's avatar
      [TASK] Deprecate extbase ReferringRequest · 8eb528d0
      Christian Kuhn authored
      When extbase has been changed to PSR-7 responses,
      class ReferringRequest has been nearly obsoleted:
      It is only used to be immediately turned into a
      To further prepare towards PSR-7 requests, usage of
      ReferringRequest which extends extbase Request is
      dropped and the class marked as deprecated.
      Change-Id: If16c09b0601792f6702fbacee064cd4d514c70c6
      Resolves: #94367
      Related: #92502
      Releases: master
      Tested-by: core-ci's avatarcore-ci <>
      Tested-by: Benni Mack's avatarBenni Mack <>
      Tested-by: Jochen's avatarJochen <>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <>
      Reviewed-by: Benni Mack's avatarBenni Mack <>
      Reviewed-by: Jochen's avatarJochen <>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <>
    • Christian Kuhn's avatar
      [TASK] Deprecate extbase ObjectManager->getEmptyObject() · 14805bdf
      Christian Kuhn authored
      ObjectManager->getEmptyObject() is only used in extbase
      persistence DataMapper when domain objects are "thawed":
      An existing DB row is fetched and a model object is
      created from it.
      From extbase PoV, a domain object lifecycle is "creation"
      ("own a new car"), then eventually "freezing" it in DB,
      "thawing" it from DB to update it's state ("washed today,
      it's now clean"), and eventually deletion ("brought to
      scrapyard, don't own it anymore").
      Extbase now says that "thawing" and "creation" are two
      different things and thus decided that programmatically,
      __construct() on thawed objects should NOT be called,
      because, well, it's not new, just thawed! Don't assume
      __wakeup() is called instead, though: It's not.
      Extbase of course has to hop through quite some loops
      to violate this PHP language construct. It even needs
      the 3rd party dependency doctrine/instantiator to achieve
      suppressing __construct() call, since the previous
      'unserialize hack' broke somewhere during PHP 5 times.
      Additionally, even though extbase Domain Model objects
      *should* be plain old PHP objects, they still allow
      inject* methods and are dependency injection aware.
      This is a problem when moving away from ObjectManager
      towards symfony DI, because symfony does not support
      this creative extbase view of supressing __construct()
      when instantiating objects.
      We can't get rid of this easily in extbase, though.
      There is no good way to deprecation-log this behavior. A
      feature toggle seems to be overkill - probably not too
      many extbase devs are aware of this implementation detail
      in the first place, and the impact if __construct() is
      properly called when an object is thawed should be relatively
      small: First, models are usually relatively stupid in extbase
      (which is good, they should be), and if they have a
      __construct() method at all, chances are, everything that is
      done there is overriden during the following mapping process
      We thus decided against a feature toggle for this. Instead,
      we *keep* the current instantiation logic in v11, just
      mark the code places as deprecated, configure the extension
      scanner to look for additional getEmptyObject() calls in
      extensions, and add a depreation reST file pointing out the
      situation and stating __construct() will be called in v12
      for thawed objects.
      Resolves: #94377
      Related: #90803
      Releases: master
      Change-Id: Ied3da8b9d885be2f635b9bc6c66b37fc9825decc
      Tested-by: Jochen's avatarJochen <>
      Tested-by: core-ci's avatarcore-ci <>
      Tested-by: Daniel Goerz's avatarDaniel Goerz <>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <>
      Reviewed-by: Jochen's avatarJochen <>
      Reviewed-by: Daniel Goerz's avatarDaniel Goerz <>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <>
  8. 16 Jun, 2021 1 commit
  9. 14 Jun, 2021 3 commits
  10. 11 Jun, 2021 4 commits
  11. 10 Jun, 2021 1 commit
  12. 09 Jun, 2021 1 commit
  13. 04 Jun, 2021 1 commit
  14. 03 Jun, 2021 1 commit
  15. 01 Jun, 2021 1 commit
  16. 30 May, 2021 1 commit
  17. 29 May, 2021 1 commit
  18. 28 May, 2021 1 commit
  19. 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
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <>
      Tested-by: Anja Leichsenring's avatarAnja Leichsenring <>
      Tested-by: Jochen's avatarJochen <>
      Tested-by: core-ci's avatarcore-ci <>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <>
      Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <>
      Reviewed-by: Jochen's avatarJochen <>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <>
  20. 26 May, 2021 2 commits
  21. 20 May, 2021 1 commit
  22. 19 May, 2021 1 commit
  23. 17 May, 2021 1 commit
  24. 14 May, 2021 2 commits
  25. 12 May, 2021 1 commit
  26. 06 May, 2021 1 commit
  27. 04 May, 2021 4 commits