1. 15 Dec, 2020 1 commit
  2. 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
  3. 13 Dec, 2020 2 commits
  4. 12 Dec, 2020 1 commit
  5. 11 Dec, 2020 1 commit
  6. 10 Dec, 2020 5 commits
  7. 08 Dec, 2020 3 commits
  8. 07 Dec, 2020 2 commits
  9. 05 Dec, 2020 1 commit
  10. 04 Dec, 2020 3 commits
  11. 02 Dec, 2020 1 commit
  12. 01 Dec, 2020 4 commits
  13. 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
  14. 28 Nov, 2020 1 commit
    • Christian Kuhn's avatar
      [TASK] Introduce constant 'TYPO3' · 1462f2a6
      Christian Kuhn authored
      TYPO3 still has some script files that run in global scope
      without class or callable encapsulation. Those are especially
      ext_localconf.php, ext_tables.php and Configuration/TCA/Overrides/*
      script files.
      
      When those files are located within document root, they can be
      called directly via HTTP and may output something, which can be
      a security risk. To prevent this, they have a call at the very
      start: 'defined('TYPO3_MODE') or die();'.
      
      Unfortunately, constant 'TYPO3_MODE' is a technical debt, core
      tries to phase it out in v11. We thus need something equivalent
      for these calls.
      
      Since that test for existance of a constant is so simple and
      straight forward, the solution is to define a new constant to
      true, simply named 'TYPO3', to substitute 'TYPO3_MODE'. The
      call is very similar: 'defined('TYPO3') or die();'.
      
      The patch targets core master and v10: Having that constant in
      v10 simplifies life of extension developers who want to deliver
      extensions compatible with v10 and v11 in the same version, when
      'TYPO3_MODE' constant is deprecated in v11 with upcoming patches.
      
      Resolves: #92948
      Related: #92947
      Releases: master, 10.4
      Change-Id: Ib7b438422a41e242cf49cd4f87a6f8c50a9907d3
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66919
      
      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>
      1462f2a6
  15. 27 Nov, 2020 2 commits
  16. 26 Nov, 2020 3 commits
  17. 25 Nov, 2020 1 commit
  18. 24 Nov, 2020 1 commit
  19. 22 Nov, 2020 1 commit
  20. 21 Nov, 2020 3 commits