Skip to content
Snippets Groups Projects
  1. Feb 28, 2024
  2. Feb 27, 2024
  3. Feb 26, 2024
  4. Feb 25, 2024
  5. Feb 24, 2024
  6. Feb 23, 2024
  7. Feb 22, 2024
  8. Feb 21, 2024
    • Torben Hansen's avatar
      [TASK] Show sender email address for mailtest in ext:install · 1d6aaf77
      Torben Hansen authored
      In TYPO3 versions before v9, the mailtest showed the configured
      sender email address. This has been removed due to a wrong fluid
      variable usage with #88523
      
      With this change, the sender email address is now shown again in
      the mailtest. Additionally, a note is added to clarify, that not
      receiving the test email could be due to spam filters or the
      sender domain SPF settings.
      
      The notice about the `defaultMailFromAddress` has been removed,
      since it is already checked in `EnvironmentController`, that
      the value is configured and a valid email address.
      
      Finally, the fluid variable `queueIdentifier` introduced with
      #100084 has been removed, since it is not used in the template.
      
      Resolves: #103136
      Related: #88523
      Related: #100084
      Releases: main, 12.4
      Change-Id: Ib076934732a05d9c709f6d822526e8316cf87106
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/83021
      
      
      Tested-by: default avatarcore-ci <typo3@b13.com>
      Reviewed-by: default avatarAndreas Kienast <a.fernandez@scripting-base.de>
      Tested-by: default avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: default avatarOliver Bartsch <bo@cedev.de>
      Tested-by: default avatarAndreas Kienast <a.fernandez@scripting-base.de>
      1d6aaf77
    • Christian Kuhn's avatar
      [TASK] Avoid runtime caching pages in DataHandler · cbb8e240
      Christian Kuhn authored
      The DataHandler has a major structural flaw by not handing
      over known record state to sub methods. It thus tends to
      fetch and process the same table/uid combination over and
      over again to figure out details like permissions.
      
      This is of course expensive: DH tends to fire lots of DB
      calls. Over the years, a series of caches have been added
      in order to suppress those DB calls and mitigate DB load.
      
      Obvious cache layers:
      * $this->recInsertAccessCache
      * $this->isRecordInWebMount_Cache
      * $this->isInWebMount_Cache
      * $this->pageCache
      * $this->runtimeCache 'checkRecordUpdateAccess_'
      * $this->runtimeCache 'doesRecordExist_pageLookUp_'
      
      As an additional gem that increases complexity, runtimeCache
      is currently abused to transfer state between DH sub instances.
      Various lower level caches kick in, too, e.g. from BackendUtility.
      
      There is a problem with these caches, in particular those that
      suppress record state DB calls: DH itself changes this state all
      the time by adding, deleting and changing records. This makes
      cache eviction a crucial aspect when dealing with them. This
      however is hard and not properly done at various places. The true
      solution is to hand over more 'known correct state at this time'
      to sub methods instead, which voids more and more of these layers.
      We've done this with the 'workspace discard' methods in v11 already
      with great success: The DB load has been reduced significantly,
      and there are no cache eviction issues in this area anymore.
      
      The patch removes a cache in doesRecordExist_pageLookUp(),
      which unblocks one aspect of a patch to fix #92604. For now,
      we actively accept a (slight, but not critical) performance
      penalty due to repeated DB queries, mainly hit when importing
      many records. Looking at use cases, we can and should instead
      refactor the call chains to hand over 'known' page record state
      directly. We will establish this with upcoming v13 patches and
      will suppress more queries than this cache avoided in the first
      place.
      
      Note the penalty introduced with this patch can be mostly
      suppressed for imports using DH->bypassAccessCheckForRecords=true,
      which is a good idea in many cases anyway at the moment, if
      the import is an admin-only operation.
      
      Resolves: #103172
      Related: #79610
      Related: #92604
      Releases: main
      Change-Id: Ie25cb4563c0bd09eb2d0060aafeae26bea7a54f5
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/83057
      
      
      Tested-by: default avatarcore-ci <typo3@b13.com>
      Tested-by: default avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Reviewed-by: default avatarSascha Nowak <typo3@saschanowak.me>
      Reviewed-by: default avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: default avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Reviewed-by: default avatarOliver Klee <typo3-coding@oliverklee.de>
      Reviewed-by: default avatarStefan Bürk <stefan@buerk.tech>
      Tested-by: default avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: default avatarStefan Bürk <stefan@buerk.tech>
      cbb8e240