1. 13 Jan, 2022 1 commit
  2. 12 Jan, 2022 1 commit
  3. 11 Jan, 2022 1 commit
  4. 14 Dec, 2021 1 commit
  5. 08 Dec, 2021 1 commit
  6. 06 Dec, 2021 1 commit
  7. 05 Dec, 2021 1 commit
  8. 04 Dec, 2021 2 commits
  9. 03 Dec, 2021 3 commits
  10. 02 Dec, 2021 6 commits
  11. 01 Dec, 2021 1 commit
  12. 30 Nov, 2021 3 commits
  13. 29 Nov, 2021 1 commit
  14. 28 Nov, 2021 1 commit
  15. 02 Oct, 2021 1 commit
  16. 24 Sep, 2021 1 commit
  17. 21 Sep, 2021 1 commit
    • Christian Kuhn's avatar
      [BUGFIX] Avoid dangling MM relations on workspace publish · e9069128
      Christian Kuhn authored
      When publishing workspace records with connected
      "true" MM relations (uid_local / uid_foreign columns
      and no TCA for that table), DataHandler triggers bugs:
      
      * It updates uid_local or uid_foreign rows to negative
        uids during the process as intermediate DB state.
      * It leaves "dangling" MM rows of the workspace record
        that has been pushed live.
      
      The involved code is relatively well encapsulated,
      it only kicks in for this "publish MM relations"
      scenario, the impact of this patch is limited to
      this area.
      
      The patch rewrites MM workspace publish handling:
      
      * Avoid parking state in a DataHandler class property
        only used in this scenario.
      * Avoid moving a list of stateful RelationHandler
        instances around and dynamically calling methods
        on those instances.
      * Avoid recursive flex form MM publish handling with
        indirect callback methods that change class state.
      * Obsolete a RelationHandler method used only in
        this scenario.
      * Reduce number of queries.
      
      The result is a simplified, better encapsulated and well
      commented solution. On a testing side, the patch brings
      a scenario to verify flex form MM relation handling.
      An according styleguide example is pending, too.
      
      This patch allows us to change auto created MM table
      definitions to unsigned uid_local and uid_foreign columns,
      which is of course the right way to go.
      
      Change-Id: I0d24f31cbd356f19937c2f8c18d432424e127b97
      Resolves: #95275
      Resolves: #81718
      Releases: master
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/71097
      
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Stefan Bürk's avatarStefan Bürk <stefan@buerk.tech>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Stefan Bürk's avatarStefan Bürk <stefan@buerk.tech>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      e9069128
  18. 20 Sep, 2021 1 commit
  19. 17 Sep, 2021 1 commit
  20. 16 Sep, 2021 2 commits
  21. 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
        create($request).
      * 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>
      98267055
  22. 09 Sep, 2021 2 commits
  23. 03 Sep, 2021 1 commit
  24. 23 Aug, 2021 1 commit
  25. 22 Jun, 2021 1 commit
  26. 18 Jun, 2021 1 commit
    • 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
      anyways.
      
      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
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69520
      
      Tested-by: Jochen's avatarJochen <rothjochen@gmail.com>
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Daniel Goerz's avatarDaniel Goerz <daniel.goerz@posteo.de>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Jochen's avatarJochen <rothjochen@gmail.com>
      Reviewed-by: Daniel Goerz's avatarDaniel Goerz <daniel.goerz@posteo.de>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      14805bdf
  27. 30 May, 2021 1 commit
  28. 28 May, 2021 1 commit