1. 22 Dec, 2020 1 commit
  2. 21 Dec, 2020 3 commits
  3. 20 Dec, 2020 3 commits
  4. 19 Dec, 2020 2 commits
  5. 17 Dec, 2020 1 commit
  6. 16 Dec, 2020 1 commit
  7. 15 Dec, 2020 2 commits
  8. 14 Dec, 2020 3 commits
    • Helmut Hummel's avatar
      [BUGFIX] Implement deferred BE image processing consistently · 0c5439f2
      Helmut Hummel authored
      Change the implementation of backend deferred image processing
      to use a file processor, which is only but always used in the backend.
      
      By doing so all limitations of the current implementation are resolved,
      which means, width and height of the image can be set in HTML, to avoid
      layout shifts and once the images are processed, they will simply
      be delivered by the web server.
      
      Inconsistencies with thumbnail ratio (depending on crop being defined
      or not) are also tackled on the go.
      
      While this changes processing configuration for some files,
      which triggers a re-generation, it should not matter, as image
      processing will be done in parallel on request, making such changes
      viable in a bugfix release.
      
      The introduced database field is neither used nor required for the
      current implementation, but is introduced to provide a possibility for
      third party processors to replace the current implementation with simple
      (and persisted) URLs to third party SaaS image processing services.
      
      Resolves: #92188
      Releases: master, 10.4
      Change-Id: I8d1e14324085c5b6ba646475206c8cb10a1fc10d
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66587
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      Reviewed-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      0c5439f2
    • Christian Kuhn's avatar
      [BUGFIX] More deterministic mm sorting · 3f22bb9e
      Christian Kuhn authored
      A 'true' MM relation (select / group with MM, but not inline
      with foreign_field - used in core for pages/tt_content table
      to sys_category via sys_category_record_mm) has two sorting
      fields: 'sorting' for the local (sys_category) side, and
      'sorting_foreign' for the foreign (pages / tt_content) side.
      
      When categories are added to a tt_content element,
      'sorting_foreign' is set to the given order of sys_category
      elements. 'sorting' is set to 0. When then opening a
      sys_category record that has multiple records pointing to
      it with 0 as sorting, the returned order of records is
      non-deterministic and depends on implicit DB engine fallbacks.
      
      This also confuses the reference index, which checks
      refindex integrity always from the 'local' side.
      
      The patch adds 'uid_foreign' as second order-by field to
      force deterministic ordering. There is still a possible
      collision in multi table relations (more than one foreign
      table uses the mm table like pages AND tt_content to
      sys_category with foreign records having the same uid) and
      if the mm table allows "multi" relations. Those scenarios
      however have no explicit TCA configuration (only implicit
      via MM_match_fields), need a deeper investigation and
      possibly further detail patches later.
      
      The patch should for now fix a functional test that is
      flaky with postgres.
      
      Change-Id: I3c89d0e67f8a4065354f9df173020ca0080e0d57
      Resolves: #93075
      Releases: master, 10.4
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67058
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      3f22bb9e
    • Christian Kuhn's avatar
      [TASK] Raise typo3/testing-framework to ^6.6.0 · 2bfe77bd
      Christian Kuhn authored
      Makes lit-html loadable in unit tests.
      
      composer require --dev typo3/testing-framework ^6.6.0
      
      Change-Id: I4b5cbf0825d12708882e744b10ffa31b78332c25
      Resolves: #93074
      Releases: master, 10.4
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67114
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      2bfe77bd
  9. 13 Dec, 2020 2 commits
  10. 12 Dec, 2020 1 commit
  11. 11 Dec, 2020 1 commit
  12. 10 Dec, 2020 5 commits
  13. 08 Dec, 2020 3 commits
  14. 07 Dec, 2020 2 commits
  15. 05 Dec, 2020 1 commit
  16. 04 Dec, 2020 3 commits
  17. 02 Dec, 2020 1 commit
  18. 01 Dec, 2020 4 commits
  19. 29 Nov, 2020 1 commit
    • Christian Kuhn's avatar
      [TASK] Add application type to request · 26ae838c
      Christian Kuhn authored
      The cardinal issue with constant 'TYPO3_MODE' is that it's
      value is NOT constant: It is defined early during bootstrap and
      derived from information that is hand over from entry point
      index.php's. Depending on this, value is either 'FE' or 'BE'.
      
      Using that constant or the related constant 'TYPO3_REQUESTTYPE'
      makes it impossible to change scope from backend to frontend
      in one PHP call. This actively blocks executing sub requests,
      use cases are for instance executing a frontend request within
      a running backend call (eg. view module), or executing frontend
      requests from cli (eg. some indexer).
      
      Dropping 'TYPO3_MODE' and its friends is thus a requirement to
      finally allow such scenarios. We can't get rid of the distinction
      between 'frontend' and 'backend' altogether since some legit use
      cases like different paths or security settings depend on it.
      
      Looking at TYPO3 bootstrap, the only class that 'knows' if it's
      frontend or backend are the Application classes of ext:frontend
      and ext:backend. They are the PSR-15 entry points, they create a
      first PSR-7 request object if it has not been given, and then
      call the PSR-15 middleware stack dispatcher to create a PSR-7
      response, starting with this first request object.
      
      The solution to get rid of 'TYPO3_MODE' is to add the information
      'I am a frontend or backend request' as attribute to the request
      object in the Application classes. To simplify things, the helper
      class ApplicationType is introduced that answers isFrontend() and
      isBackend() for a given request object.
      
      Documentation changelog files with full details on the impact of
      this change will be added with an upcoming patch that deprecates
      the constants in master.
      
      This patch targets master and v10: 'TYPO3_MODE' is used in
      extensions quite often. Having the API in both v10 and v11 helps
      extension developers to deliver deprecation free extensions that
      are compatible with both v10 and v11 in one version. Codewise,
      neither the 'applicationType' attribute nor the helper class
      harm in v10.
      
      Resolves: #92951
      Related: #92947
      Releases: master, 10.4
      Change-Id: Ia4ea637b252b774cf72492402e6be52ee4695242
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66920
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      26ae838c