Skip to content
GitLab
  1. 22 Dec, 2020 1 commit
  3. 21 Dec, 2020 3 commits
  5. 20 Dec, 2020 3 commits
  7. 19 Dec, 2020 2 commits
  9. 17 Dec, 2020 1 commit
  11. 16 Dec, 2020 1 commit
  13. 15 Dec, 2020 2 commits
  15. 14 Dec, 2020 3 commits
    • Helmut Hummel's avatar
      [BUGFIX] Implement deferred BE image processing consistently · 0c5439f2
      Helmut Hummel authored and Georg Ringer's avatar Georg Ringer committed 
      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
  17. 13 Dec, 2020 2 commits
  19. 12 Dec, 2020 1 commit
  21. 11 Dec, 2020 1 commit
  23. 10 Dec, 2020 5 commits
  25. 08 Dec, 2020 3 commits
  27. 07 Dec, 2020 2 commits
  29. 05 Dec, 2020 1 commit
  31. 04 Dec, 2020 3 commits
  33. 02 Dec, 2020 1 commit
  35. 01 Dec, 2020 4 commits
  37. 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