Skip to content
Snippets Groups Projects
Select Git revision
  • 12.4
  • main default
  • 11.5
  • 13.3
  • l10n_main
  • 13.1
  • 13.0
  • l10n_12.4
  • 10.4
  • 12.1
  • 9.5
  • 11.3
  • master
  • 11.1
  • TYPO3_8-7
  • 10.2
  • 9.3
  • 9.2
  • TYPO3_7-6
  • TYPO3_7-0
  • v13.3.1
  • v12.4.21
  • v11.5.40
  • v13.3.0
  • v12.4.20
  • v12.4.19
  • v12.4.18
  • v11.5.39
  • v12.4.17
  • v13.2.1
  • v13.2.0
  • v12.4.16
  • v11.5.38
  • v13.1.1
  • v12.4.15
  • v11.5.37
  • v13.1.0
  • v12.4.14
  • v12.4.13
  • v12.4.12
40 results
Search by author
  • Any Author
  • Daniel Hürtgen Daniel Hürtgen higidi
  • Jenkins Jenkins jenkins
  • **** **** project_53_bot
3 authors
  1. Jul 10, 2023
  3. Jul 08, 2023
  5. Jul 07, 2023
  7. Jul 06, 2023
  9. Jul 05, 2023
  11. Jul 04, 2023
    • Stefan Bürk's avatar
      [BUGFIX] Resolve page with trailing slash requested without one · 9d43c6f8
      Stefan Bürk authored 
      With #89091 pages with slugs containing trailing slash have
been enabled to be resolved when requested with trailing
slash in the request uri and have been a logical follow-up
of #86055.

In between an issue with language fallback chain have been
found, which allowed that a valid translated page could be
resolved with the default language slug even and reported
as #88715 and #96010. These issues have been solved with
https://review.typo3.org/c/Packages/TYPO3.CMS/+/75101 which
partly broke the original implemented behaviour for pages
with trailing slash slugs requested without a trailing slash.

This change now ensures pages are resolved containing a trailing
slash in their "slug" like "/my-page/subpage/" if requested without
the trailing slash like "https://domain.tld/my-page/subpage".

Additionally, tests are added to cover this case along with
other possible cases. This should detect future regressions.

The docblock return annotation for `PageRouter::matchRequest()` is
changed to the correct returned value, removing ignore pattern for
the phpstan baseline instead of increasing the counter.

Note: This change ensures that a page can be resolved in any
      constellation with trailing slash in record slug/not
      in record slug and requested with trailing slash/not
      requested slug. In both cases, already working and the
      now fixed variant are serving both potential duplicate
      content - if no correct cannonical url is provided.

Tackling the duplicate issue should be done in a dedicated
change for both cases.

Used command(s):

> Build/Scripts/runTests.sh -s phpstanGenerateBaseline

Resolves: #100990
Related: #96010
Related: #88715
Related: #89091
Related: #86055
Releases: main, 12.4, 11.5
Change-Id: I9f26c4500e2f812e8727b4b565570fcc579bf3e6
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/79705


Reviewed-by: default avatarStefan Bürk <stefan@buerk.tech>
Tested-by: default avatarcore-ci <typo3@b13.com>
Tested-by: default avatarStefan Bürk <stefan@buerk.tech>
      9d43c6f8
    • Alexander Schnitzler's avatar
      [BUGFIX] Avoid symfony/property-access in getGettablePropertyNames() · 26e15895
      Alexander Schnitzler authored 
      ObjectAccess::getGettablePropertyNames() has quite the history by now.
It used to be quite simple, an is_callable() check for getters/hassers
and issers of objects. That didn't account for methods with mandatory
method arguments which was fixed by using reflection. Because runtime
reflection is slow, the usage of cached reflection (ClassSchema) had
been introduced. But, during that change, symfony/property-access had
also been introduces, which contradicts the idea of performance gain
because:

- symfony/property-access also uses uncached reflection
- symfony/property-access actually calls the accessors under test

As both is undesirable, the usage of symfony/property-access has been
removed again.

Releases: main, 12.4, 11.5
Resolves: #101176
Change-Id: I2bc796ebeaf2f1357fd3154b711910c6f553f4e4
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/79676


Tested-by: default avatarBenni Mack <benni@typo3.org>
Reviewed-by: default avatarBenni Mack <benni@typo3.org>
Tested-by: default avatarcore-ci <typo3@b13.com>
      26e15895
    • Guillaume Germain's avatar
      [BUGFIX] Avoid reaching placeholder limit in DataMapProcessor · 317b4a7d
      Guillaume Germain authored 
      Use array chunked query combined with direct value list
to retrieve full data set in `DataMapProcessor` methods
`fetchTranslationValues` and `fetchDependentElements`.

Resolves: #99326
Releases: main, 12.4, 11.5
Change-Id: Iaf220014cd991002450779197169c5c32a3c7dbc
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/79692


Tested-by: default avatarStefan Bürk <stefan@buerk.tech>
Reviewed-by: default avatarStefan Bürk <stefan@buerk.tech>
Tested-by: default avatarcore-ci <typo3@b13.com>
      317b4a7d
  13. Jul 03, 2023
  15. Jul 01, 2023
  17. Jun 29, 2023
  19. Jun 27, 2023
  21. Jun 26, 2023
    • Stefan Bürk's avatar
      [BUGFIX] Add `ESCAPE` keyword for `like()` and `notLike() expressions · cd000ec9
      Stefan Bürk authored 
      Values for `like` expressions should be escaping the
corresponding like wildcards ($ and _). TYPO3 core
provides a `escapeLikeWildcards()` in `QueryBuilder`
and on the `Connection`. Under the hood, the php
`addcslashes()` method is used to escape wildcards
in the value before appending/prepending wildcards.

It has been assumed, that `\` as escape character
is always the default character throughout all
database server vendors and versions - which makes
`addcslashes()` the one-shot to use.

It has been recently discovered, that if values in
the database contains one of these wildcards, for
example the underscore `_` and a like expression
is built using the escape method, the row cannot
be matched in all databases.

This relates to the fact, that the generated like
expressions do not contains the `ESCAPE` keyword
to define which escape character has been used.

`doctrine/dbal` has added a corresponding argument
to the doctrine/dbal query ExpressionBuilder like()
and notLike() method, so this can be set.

TYPO3 uses a custom ExpressionBuilder, not extending
the doctrine ExpressionBuilder (which will change
with upcoming doctrine/dbal v4).

This change always adds the `ESCAPE` keyword to
like and not like expressions with the hardcoded
`\` escape character - except for PostgresSQL.
PostgresSQL doesn't like it when ILIKE/NOT ILIKE
is used, which the ExpressionBuilder does to mimic
case insensitive LIKE/NOT LIKE similar to MySql.

This can be made configurable in a dedicated patch
and must be done for upgrading to doctrine/dbal 4.x
anyway.

Resolves: #100874
Releases: main, 12.4, 11.5
Change-Id: Id7eb891ef52e8c6988a605eaadd0afcbcf5176bb
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/79491


Tested-by: default avatarStefan Bürk <stefan@buerk.tech>
Tested-by: default avatarcore-ci <typo3@b13.com>
Reviewed-by: default avatarStefan Bürk <stefan@buerk.tech>
      cd000ec9
  23. Jun 21, 2023
  25. Jun 20, 2023
  27. Jun 15, 2023
  29. Jun 14, 2023