Skip to content
Snippets Groups Projects
  1. Jan 20, 2021
  2. Jan 19, 2021
  3. Jan 18, 2021
  4. Jan 17, 2021
  5. Jan 16, 2021
  6. Jan 13, 2021
  7. Jan 12, 2021
  8. Jan 11, 2021
  9. Jan 10, 2021
  10. Jan 09, 2021
  11. Jan 08, 2021
  12. Jan 07, 2021
    • Oliver Bartsch's avatar
      [TASK] Fetch route from request instead of GET parameter · b52f67b6
      Oliver Bartsch authored
      The "route" GET parameter is deprecated since #93048.
      Therefore the route path has now to be fetched from the
      request object instead.
      
      This patch replaces all places in core where the route
      is still fetched via GET. It's currently often necessary
      to access $GLOBALS['TYPO3_REQUEST'] therefore, since the
      request object is not always present at those places. This
      will be tackeled in upcoming patches.
      
      Resolves: #93158
      Releases: master
      Change-Id: I6e163919b19484171b6ebf8087fdc650cf977c9c
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67355
      
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: default avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: default avatarBenni Mack <benni@typo3.org>
      Reviewed-by: default avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: default avatarBenni Mack <benni@typo3.org>
      b52f67b6
    • Benjamin Franzke's avatar
      [TASK] Propagate "immediate" responses through the middleware stack · f179a57f
      Benjamin Franzke authored
      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: default avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: default avatarBenni Mack <benni@typo3.org>
      Reviewed-by: default avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: default avatarBenni Mack <benni@typo3.org>
      f179a57f
    • Christian Kuhn's avatar
      [BUGFIX] Working preview links in workspace mails · a97accab
      Christian Kuhn authored
      Fix a couple of issues with state change emails in
      workspaces:
      
      * We still can't deep link to the backend. The generated
        comparisonLink to the side-by-side preview module is a
        workspace backend functionality. The generated links
        don't work and show the login form. The fix is to
        generate "preview links" instead which call a frontend.
        We may be able to improve this later, when core v11
        allows deep linking.
      
      * When changing the stage of a page delete placeholder
        - when a page is for deletion in live - preview link
        generation to these pages does not make sense, trying
        to generate such a link throws an exception "no
        connection to page tree", the ajax request fails and
        no mails are send. Fix is to catch the exception and
        leave out the link in the emails.
      
      * Preview links did not carry the language id when
        sending notifications for state changes of non default
        language records. This is added to properly link to
        non-default language previews.
      
      * A missing closing p-tag in the HTML mail.
      
      * As a better default, preview links are now always added
        to the mails if possible. In rare cases where this is
        not wanted, the mail templates should be adapted.
      
      Change-Id: I84f0e4e5131d52ecbc5e7424137ae7e2ebdb2031
      Resolves: #91515
      Resolves: #81708
      Related: #90411
      Releases: master, 10.4
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67342
      
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: default avatarOliver Bartsch <bo@cedev.de>
      Tested-by: default avatarBenni Mack <benni@typo3.org>
      Reviewed-by: default avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: default avatarBenni Mack <benni@typo3.org>
      a97accab