This project is mirrored from https://git.typo3.org/typo3/typo3.git. Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer or owner.
Last successful update .
  1. 20 Jul, 2021 1 commit
  2. 07 Jan, 2021 1 commit
    • Benjamin Franzke's avatar
      [TASK] Propagate "immediate" responses through the middleware stack · f179a57f
      Benjamin Franzke authored and Benni Mack's avatar Benni Mack committed
      When a controller finds some pre-requisites of the called
      action are not fulfilled, it can create an 'early' response
      and throw it as ImmediateResponseException. This exception
      bypasses the middleware stack, and is caught in the Application
      to emit the response. This is a big win in contrast to
      die/exit calls.
      
      Some middlewares however expect to be always called when the
      response bubbles up. Good examples are 'locking' middlewares:
      They set up a lock when called, dispatch to inner middlewares,
      and tear town the lock when a response is retrieved.
      
      The tear down code of those middlewares is bypassed when
      a controller throws an ImmediateResponseException.
      
      The patch introduces a second exception: PropagateResponseException.
      This one is caught by a new very inner middleware positioned at the
      end of the middleware stack, just before the request is dispatched
      to some controller. It then sends the response up the outer
      middlewares. This allows middlewares like a 'locking' middleware
      to do it's job without being bypassed, and at the same time
      allows a controller to bypass any further local processing by
      throwing such a response exception.
      
      ImmediateResponseException exists as before and can still be used
      to directly bypass the middleware stack and is kept as safety net
      in case a PropagateResponseException is thrown within a middleware.
      PropagateResponseException therefore extends ImmediateResponseException.
      
      It's however discouraged to throw ImmediateResponseException from
      within controllers - they require knowledge on what middlewares
      do in their 'tear down' part and there shouldn't be a reason to
      bypass them.
      
      Middleware/BackendUserAuthenticator is adapted to properly
      handle ImmediateResponseException that would have been thrown
      BackendUserAuthentication::backendCheckLogin(). BackendUserAuthentication
      is therefore refactored to allow to call the backend login
      initialization without (duplicate) login check.
      This allows to propagate redirect/maintenance responses.
      
      Releases: master
      Resolves: #93007
      Change-Id: I291d9d532e7fa289b803e5eef38b23402e57e8ba
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67042
      
      
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      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>
      f179a57f
  3. 20 Dec, 2020 1 commit
  4. 14 Oct, 2020 1 commit
    • Christian Kuhn's avatar
      [!!!][TASK] Drop 'recursive delete' backend user setting · f3e221a2
      Christian Kuhn authored and Benni Mack's avatar Benni Mack committed
      The 'you can not delete pages that have sub pages' user
      settings restriction has been annoying ever since. Users
      who actually want to delete a full tree were annoyed by
      this flag if they did not had it and had to rely on an
      administrator action to actually give it to them, and
      had to delete pages on a one-by-one base meanwhile.
      Clever admins thus often enabled that flag by default.
      
      It was meant as a feature to prevent casual users from
      commiting accidential harm to a site tree. There are
      better ways to achieve this goal however: Admins
      can set proper access rights for important key pages
      preventing editors from deleting them. Furthermore,
      a better 'prevent editors from doing harm in live'
      way is available by using the workspaces extension. And,
      in case of accidental deletion, admins can always
      resurrect full page trees using the recycler extension.
      
      The patch drops the 'recursive delete' option from
      specific user settings and always allows deleting
      pages including sub pages.
      
      Resolves: #92560
      Releases: master
      Change-Id: I8401edc10daece7f83d0c5f85f99129616fac957
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66136
      
      
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      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>
      f3e221a2
  5. 15 Apr, 2020 1 commit
  6. 14 Apr, 2020 1 commit
  7. 07 Oct, 2019 1 commit
  8. 14 Jun, 2019 1 commit
  9. 30 Sep, 2018 1 commit
  10. 14 Aug, 2018 1 commit
  11. 09 Aug, 2018 1 commit
  12. 15 Jun, 2018 1 commit
  13. 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>
      eb049dba
  14. 10 Jan, 2017 2 commits