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. Feb 13, 2024
  3. Feb 06, 2024
    • Stefan Bürk's avatar
      [TASK] Update `doctrine/dbal:^3.8.1` · ff1931a7
      Stefan Bürk authored 
      Doctrine DBAL 3.8.x comes with further deprecations, but
also with the new `QueryBuilder::reset*()` methods as a
mitigation for the deprecated generic QueryBuilder methods
`resetQueryParams()` and `resetQueryParam()`.

See [1] for release notes and [2] for changes from current
minimum version towards 3.8.1.

Raising the minimum version ensures that extension authors
are able to create TYPO3 v12 and v13 compatible code. At least,
they can rely on it with the TYPO3 release containing this change
for non-Composer and Composer mode.

Used command(s):

> \
  composer req --no-update --no-install \
    -d typo3/sysext/redirects \
    "doctrine/dbal":"^3.8.1" ; \
  composer req --no-update --no-install \
    -d typo3/sysext/core \
    "doctrine/dbal":"^3.8.1" ; \
  composer req --no-update --no-install \
    -d typo3/sysext/install \
    "doctrine/dbal":"^3.8.1" ; \
  composer req -W \
    "doctrine/dbal":"^3.8.1"

[1] https://github.com/doctrine/dbal/releases/tag/3.8.1
[2] h...
      ff1931a7
  5. Feb 03, 2024
  7. Feb 01, 2024
  9. Jan 25, 2024
  11. Jan 12, 2024
    • Stefan Bürk's avatar
      [BUGFIX] Update doctrine/dbal to ensure performance bugfix · c17e7978
      Stefan Bürk authored 
      Doctrine DBAL 3.7.0 introduced a performance issue [1]
which has been already fixed by the Doctrine Team [2].

This change updates the `doctrine/dbal` composer constraint
to ensure that this performance issue is gone.

Note:   The monorepo composer.lock already containted the
        3.7.2 bugfis release, therefore this has not been
        detected in casual core development. This update
        is to mitigate the performance issue at all costs
        for TYPO3 users.

As a sideeffect, this should put `composerInstallMin`
nightly function tests on speed again.

Used command(s):

> composer require --no-update --no-install \
    -d typo3/sysext/redirects \
    "doctrine/dbal":"^3.7.2" ; \
  composer require --no-update --no-install \
    -d typo3/sysext/core \
    "doctrine/dbal":"^3.7.2" ; \
  composer require --no-update --no-install \
    -d typo3/sysext/install \
    "doctrine/dbal":"^3.7.2" ; \
  composer require --no-update \
    "doctrine/...
      c17e7978
  13. Jan 06, 2024
  15. Jan 04, 2024
    • Benni Mack's avatar
      [TASK] Allow usage of symfony 7 · b03970d9
      Benni Mack authored 
      This change enables Symfony 7 in
addition to symfony 6 in TYPO3.

Symfony7 requires PHP 8.2, thus
is not installed by default for the
time being, as this change is also
allowed for TYPO3 v12 support when
running with PHP 8.2 and composer.

Used commands:

composer req -W \
 "symfony/config:^6.4 || ^7.0" \
 "symfony/console:^6.4 || ^7.0" \
 "symfony/dependency-injection:^6.4 || ^7.0" \
 "symfony/doctrine-messenger:^6.4 || ^7.0" \
 "symfony/expression-language:^6.4 || ^7.0" \
 "symfony/filesystem:^6.4 || ^7.0" \
 "symfony/finder:^6.4 || ^7.0" \
 "symfony/http-foundation:^6.4 || ^7.0" \
 "symfony/mailer:^6.4 || ^7.0" \
 "symfony/messenger:^6.4 || ^7.0" \
 "symfony/mime:^6.4 || ^7.0" \
 "symfony/options-resolver:^6.4 || ^7.0" \
 "symfony/property-access:^6.4 || ^7.0" \
 "symfony/property-info:^6.4 || ^7.0" \
 "symfony/rate-limiter:^6.4 || ^7.0" \
 "symfony/routing:^6.4 || ^7.0" \
 "symfony/uid:^6.4 || ^7.0" \
 "symfony/var-dumper:^6.4 || ^7.0" \
 "symfony/yaml:^6.4 || ^7.0"

 composer req --dev -W \
 "codeception/codeception:^5.0.13" \
 "codeception/module-filesystem:^3.0.1" \
 "friendsofphp/php-cs-fixer:^3.46" \
 "symfony/translation:^6.4 || ^7.0"

Resolves: #102746
Releases: main, 12.4
Change-Id: I6bbbfb0bc6e26c00fba0010234b5c8b698cf0a81
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/82314


Tested-by: default avatarcore-ci <typo3@b13.com>
Tested-by: default avatarBenni Mack <benni@typo3.org>
Reviewed-by: default avatarBenni Mack <benni@typo3.org>
      b03970d9
    • Anja Leichsenring's avatar
      [TASK] Update locales translation files · 5a4a17fa
      Anja Leichsenring authored 
      TYPO3 uses a composer package [1] to import
locales along with translations and a custom
script has been added to create and update
included translation files.

This change updates the language files with
the last updates and requires the package
with the current highest version as minimum.

Used command(s):

> composer req --dev \
    "sokil/php-isocodes-db-i18n":"^4.0.18"

> Build/Scripts/runTests.sh \
    -s checkIsoDatabase \
    -p 8.1

[1] sokil/php-isocodes-db-i18n

Resolves: #102747
Releases: main, 12.4
Change-Id: I4d6603484c4fca213c66f0df0feff13bc1011b29
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/82307


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>
      5a4a17fa
  17. Dec 28, 2023
  19. Dec 09, 2023
  21. Dec 05, 2023
    • Christian Kuhn's avatar
      [BUGFIX] Allow access to TypoScript overrides for labels in _LOCAL_LANG · 490f1269
      Christian Kuhn authored 
      This bugfix enables the possibility to access _LOCAL_LANG
values from TypoScript properly again via Extbase's
LocalizationUtility, and thus for <f:translate> ViewHelpers
as well again.

This is what has changed under-the-hood:

The TranslateViewHelper is now only a thin layer
to Extbase's LocalizationUtility (as before), and only
checks if a current request or Locale/languageKey is
given, if a locale can be resolved. Everything else
is then dispatched to the LocalizationUtility.

<f:translate> is very clean now and has almost no further
responsibility than to call LocalizationUtility::translate

Instead of adding further LocalizationUtility magic,
overriding of TypoScript is now enabled for any kind
of plugin which hands in $extensionName. This is achieved
by building proper Locale objects from the request which
are then used to build the respective LanguageService.

As it turned out after the 12.4.0 release, the "Locales"
class is indeed the factory for creating a Locale, which
is decoupled from the actual LanguageService (= label magic),
the Locales factory receives a few create methods to make
life easier for usage, which both f:translate AND
LocalizationUtility receive, making their parts much smaller.

Further work will dissolve the usage of the Configuration
Manager of Extbase, but this won't happen in v12 anymore.

Resolves: #100759
Releases: main, 12.4
Change-Id: Ifcad2ec590746e96066a96f314500bd50e9b4695
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/82023


Tested-by: default avatarcore-ci <typo3@b13.com>
Reviewed-by: default avatarBenni Mack <benni@typo3.org>
Tested-by: default avatarBenni Mack <benni@typo3.org>
      490f1269
  23. Dec 04, 2023
  25. Dec 02, 2023
  27. Nov 29, 2023
  29. Nov 27, 2023
  31. Nov 24, 2023
  33. Nov 14, 2023
  35. Nov 07, 2023
  37. Nov 06, 2023
  39. Oct 31, 2023
  41. Oct 30, 2023
  43. Oct 24, 2023
  45. Oct 18, 2023
    • Benjamin Franzke's avatar
      [TASK] Add phpstan check for unneeded pseudo uncertain instanceof usage · 979a4571
      Benjamin Franzke authored 
      An `instanceof Type` on `Type|null` is unneeded and is to be replaced by
a null-check (or modern alternatives like optional chaning or the null
coalescing operator) in order to avoid narrowing code branches
unnecessarily. We call them "pseudo" uncertain checks there is no need
to express uncertainty regarding the type in a condition where native
type declarations define a specific type *or* null:

  It is `null` or `!null`.

Definition of a pseudo uncertain instanceof check:

  `$foo instanceof Bar` is fully equivalent to `$foo !== null`,
    when `$foo` is defined (via native PHP types) to be `Bar|null`.
   ⇒ `instanceof` expresses pseudo uncertainty regarding the type.

From what we have seen in previous gerrit discussions, there were two
reasons why instanceof was preferred over null checks although being
unneeded:

1) Cognitive load for an instanceof check is perceived to be lower in
   contrast to negated null (not null) conditions
2) Preparatory safe-guard against type of $foo being changed at sometime
   later

1) Cognitive load is a subjective term and the opinions actually differ
   a lot. Some developers prefer narrowing instanceof conditions because
   they claim the desired type for a certain code branch.
   Some others say that's a clear signal for code that needs refactoring
   and perceive a high cognitive load because they do not understand why
   the type is unnecessarily checked if it can only be null or not null.
   Lets call that: "reverse cognitive load".
   That means, this argument basically boils down to
   "congitive load" (for the good "then" case: inner code block) vs
   "reverse cognitive load" (for the bad "else" case: outer code block)
   ⇒ Due to being subjective "cognitive load" is not a good argument to
     base a decision upon.

2) The second argument is that an instanceof ensures a method that is to
   be called actually exists and doesn't lead to an error – that is a
   "preparatory safe-guard".
   This is true and works, but doesn't "answer" the question,
   what happens if the object is not an instance of the desired type
   (but not null).
   While preparatory safe-guards against the type of variable being
   changed sometime later was probably a pretty good idea for code that
   is not statically analyzed and had no native type declarations, but
   such checks effectively preclude that the type must/should never
   change (which might not be true!) and has no chance of actually
   detecting when that case (type change/extension) ever happens.
   All advantages offered by pseudo uncertain instanceof checks are
   accomplished with static code analysis as well, but with the added
   downside that an `instanceof` hardcodes our human static code
   analysis result, instead of letting the static analyzer do the job.

   To explain that:
   If the type of the variable under test is actually widened (like a
   union type, or change to a base class), it will never be
   automatically detected that there is an instanceof condition that
   restricts the type too narrowly. It will always be valid code from
   static code analysis perspective.

   In comparison to that, static analysis on null-checked variables will
   report invalid method calls or assignments not allowed by the
   (natively defined) types and will notify in case a type change
   requires the code to be adapted.
   We gain the advantage that the code will not be forgotten to
   be updated to a new type.

   That means !== null combined with static code analysis has the same
   level of being a safeguard against the bad cases, while instanceof
   silently transforms new "good"-cases into bugs, where !== null is a
   transparent and secure passthrough.

   Actually to make an uncertain instanceof robust, an elseif branch
   would be needed to be somehow notified about new good-cases without
   silently ignoring them:

   if ($foo instanceof Foo) {
       …
   } elseif ($foo !== null) {
       throw new MustNeverHappenException(…);
   }

In other words an unneeded pseudo uncertain instanceof check is
basically like a switch construct without a default case.
Just to be explicit: Of course, instanceof is fine to be used
when multiples types are to be expected and handled in different code
branches.

That means pseudo uncertain instanceof usage instead of null-checks is
an antipattern for the following reasons:

 * It narrow code branches for the sake of less cognitive load
   * The cognitive load appears to be lower, but actually future-bad
     cases are overseen and are never auto-detectable in future – while
     null-checks will resolve to static analysis errors in case the
     input type is *ever* widened (which uncertain `instanceof` checks
     try to prepare for, but actually introduce future-bugs because of
     missing `else` cases)
 * It embraces deep nesting instead of early returns via null-checks
 * It embraces conditions over newer and more elegant PHP techniques
   like optional chaing
 * Tries to "help" the developer by explicitly anotating the
   current type of the variable under test
   ⇒ This is a clear sign of code smell, that needs to refactored into
      smaller chunks and methods and type autocompletion/information
      can be provided by IDEs when using proper types (which this change
      is about) anyway
 * Has zero advantages over static code analysis

Resolves: #102140
Releases: main, 12.4
Change-Id: I10de41e9744a814c9e24255573b5a5eaf6fb8b0f
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/81445


Tested-by: default avatarBenjamin Franzke <ben@bnf.dev>
Reviewed-by: default avatarBenjamin Franzke <ben@bnf.dev>
Tested-by: default avatarcore-ci <typo3@b13.com>
      979a4571
  47. Oct 10, 2023
    • Stefan Bürk's avatar
      [TASK] Upgrade `doctrine/dbal:^3.7.1` · f06bef83
      Stefan Bürk authored 
      Recent release for doctrine/dbal containes a
php docblock change which helps phpstan to
proper determine types.

This change upgrades the doctrine/dbal package
and removes a now superflous entry from the
phpstan baseline.

Used command(s):

> composer req --no-update \
    -d typo3/sysext/core \
    "doctrine/dbal":"^3.7.1" \
  && composer req --no-update \
    -d typo3/sysext/redirects \
    "doctrine/dbal":"^3.7.1" \
  && composer req --no-update \
    -d typo3/sysext/install \
    "doctrine/dbal":"^3.7.1" \
  && composer req \
    "doctrine/dbal":"^3.7.1"

> Build/Scripts/runTests.sh -s phpstanGenerateBaseline

Resolves: #102133
Releases: main, 12.4
Change-Id: Iaeba882e0584442c6caac71d3dd1e33ac0a56ef1
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/81395


Tested-by: default avatarcore-ci <typo3@b13.com>
Tested-by: default avatarStefan Bürk <stefan@buerk.tech>
Reviewed-by: default avatarStefan Bürk <stefan@buerk.tech>
      f06bef83
  49. Oct 09, 2023
  51. Oct 07, 2023
  53. Sep 27, 2023
  55. Sep 20, 2023
    • Oliver Hader's avatar
      [TASK] Ensure package dependencies in functional/acceptance tests · a89023e3
      Oliver Hader authored 
      This change uses the dependency ordering service in the method
`\TYPO3\TestingFramework\Core\Testbase::setUpPackageStates` for
test scenarios in functional and acceptance tests.

Besides that the following changes were applied:
* remove invalid dependency in fixture ext:test_configoverride_second
* add `PackageStatesTest` to keep track of extension dependencies
* add dependency to ext:frontend in ext:form, since it overrides
  TCA for the tables tt_content and sys_template (which would result
  in different ext:impexp results due to table field orderings)
* recreate IRRE related XML fixtures for ext:impexp since fixture
  extensions are now ordered alphabetically (and due to #100734)

Resolves: #101809
Releases: main, 12.4
Change-Id: I1f91a75ac8aec9db0291b0f5c8bcf7162d5b0082
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/81093


Tested-by: default avatarcore-ci <typo3@b13.com>
Reviewed-by: default avatarStefan Bürk <stefan@buerk.tech>
Tested-by: default avatarStefan Bürk <stefan@buerk.tech>
      a89023e3
  57. Sep 10, 2023
  59. Sep 08, 2023
  61. Sep 07, 2023
  63. Aug 28, 2023
    • Christian Kuhn's avatar
      [BUGFIX] Avoid static state in LocalizationUtility · 727fb0e5
      Christian Kuhn authored 
      The extbase ConfigurationManager is (unfortunately)
a stateful singleton that we can not get rid of
without a bigger rewrite.

While stateful singletons are bad enough, the
extbase LocalizationUtility makes this worse by
parking an instance of ConfigurationManager in
a static property, re-using it as a "cached"
singleton.

LocalizationUtility does this since it in itself
is static, which makes this service just so
convenient to use. When it comes to sub requests
and similar, static state is doomed and we need
to get rid of it, we've had a couple of patches
in v12 dealing with similar things.

Mid-term, extbase LocalizationUtility needs to
vanish anyways, but in the meantime, we have to
get rid of static state that kills sub request scope.

The patch removes the static $configurationManager
property and adapts functional tests that already
showed the current solution was a hack. There are
various upper and lower cache layers that ensure
removing this "cache layer" won't make things more
expensive in practice, which allows us to remove
this static state without further fallback.

In main, this needs a TF update:

> composer u typo3/testing-framework

In 12.4, this need a TF raise:

> composer req --dev typo3/testing-framework:^8.0.3

Resolves: #101779
Releases: main, 12.4
Change-Id: Ie5db07b0475f612a996d369ab3417672b33fbb2d
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80737


Reviewed-by: default avatarChristian Kuhn <lolli@schwarzbu.ch>
Tested-by: default avatarcore-ci <typo3@b13.com>
Tested-by: default avatarChristian Kuhn <lolli@schwarzbu.ch>
      727fb0e5
    • Oliver Klee's avatar
      [TASK] Update PHPStan & friends · 9778ef0d
      Oliver Klee authored 
      The new versions find some more possible problems,
and also improve performance.

> composer req --dev phpstan/phpstan:^1.10.32
> composer req --dev phpstan/phpstan-phpunit:^1.3.14
> ./Build/Scripts/runTests.sh -s phpstanGenerateBaseline

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


Reviewed-by: default avatarChristian Kuhn <lolli@schwarzbu.ch>
Tested-by: default avatarcore-ci <typo3@b13.com>
Tested-by: default avatarChristian Kuhn <lolli@schwarzbu.ch>
      9778ef0d
  65. Aug 18, 2023
  67. Aug 03, 2023
  69. Jul 31, 2023