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 26, 2024
  3. Feb 24, 2024
  5. Feb 13, 2024
  7. Feb 06, 2024
  9. Feb 03, 2024
  11. Jan 30, 2024
  13. Jan 29, 2024
  15. Jan 27, 2024
    • Stefan Bürk's avatar
      [TASK] Upgrade to `doctrine/dbal:4.0.0-RC2` · 3b563e58
      Stefan Bürk authored 
      Doctrine DBAL has been upgraded to the next
major version using the development version
as a intermediate solution. Recently, the
second release candidate has been released.

This change upgraded to that candidate now.
Adding the release candidate to a project
root composer.json is still needed as a
workaround - or lowering the minimum stability.

Used command(s):

> \
  composer req --no-update --no-install \
    -d typo3/sysext/redirects \
    "doctrine/dbal":"4.0.0-RC2@rc" ; \
  composer req --no-update --no-install \
    -d typo3/sysext/core \
    "doctrine/dbal":"4.0.0-RC2@rc" ; \
  composer req --no-update --no-install \
    -d typo3/sysext/install \
    "doctrine/dbal":"4.0.0-RC2@rc" ; \
  composer req -W \
    "doctrine/dbal":"4.0.0-RC2@rc" ; \
  COMPOSER=composer.dist.json composer req --no-update \
    -d Build/composer \
    "doctrine/dbal":"4.0.0-RC2@rc"

Resolves: #102959
Releated: #102875
Releases: main

Change-Id: Ia4c4c39234c68d6382fd6bebcc359eac6a8ab51e
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/82674


Tested-by: default avatarChristian Kuhn <lolli@schwarzbu.ch>
Tested-by: default avatarBenni Mack <benni@typo3.org>
Tested-by: default avatarcore-ci <typo3@b13.com>
Reviewed-by: default avatarBenni Mack <benni@typo3.org>
Reviewed-by: default avatarChristian Kuhn <lolli@schwarzbu.ch>
      3b563e58
  17. Jan 26, 2024
    • Christian Kuhn's avatar
      [TASK] Move 'extension download' upgrade wizard to EM · 3e6b817a
      Christian Kuhn authored 
      The install tool has just a few dependencies to
ext:extensionmanager. Most notably, it ships the
AbstractDownloadExtensionUpdate upgrade wizard,
which is used when core extracts stuff to dedicated
extensions that are removed from monorepo.

The v12 upgrade wizard for 'fe_login_mode' uses this.

These upgrade wizards are tailored for non-composer-mode
only, just like the extensionmanager, which essentially
does nothing in composer mode.

To loosen the dependency from ext:install to
ext:extensionmanager, the patch moves the abstract, a
model class for this case, plus the fe_login_mode
implementation to ext:extensionmanager.

Class aliases are established, so a casual deprecation
is enough in this case. A few extensions rely on the
class, typically those that try to extend the upgrade
range of core by forward porting wizards older than
two major core versions. Those shoud continue to work
with v13, and will have to adapt the class namespace
of the abstract with v14 latest.

Moving the fe_login_mode wizard around does not make the
wizard show up again in case the wizard has been marked
'done' during v12 upgrade already, since usually the
according DB field does not exist anymore. We don't need
special handling for this case.

Resolves: #102943
Releases: main
Change-Id: Idb5e6c90900ffad7f9c3c383fff58a05c6728aa9
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/82659


Tested-by: default avatarAndreas Kienast <a.fernandez@scripting-base.de>
Tested-by: default avatarcore-ci <typo3@b13.com>
Tested-by: default avatarNikita Hovratov <nikita.h@live.de>
Reviewed-by: default avatarAndreas Kienast <a.fernandez@scripting-base.de>
Reviewed-by: default avatarNikita Hovratov <nikita.h@live.de>
      3e6b817a
  19. Jan 25, 2024
  21. Jan 24, 2024
  23. Jan 12, 2024
  25. Jan 09, 2024
  27. Jan 08, 2024
  29. Jan 06, 2024
  31. Jan 04, 2024
  33. Dec 28, 2023
  35. Dec 09, 2023
  37. Dec 08, 2023
  39. Dec 05, 2023
    • Christian Kuhn's avatar
      [BUGFIX] Allow access to TypoScript overrides for labels in _LOCAL_LANG · ed503f90
      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 disolve 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/+/80732


Tested-by: default avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
Tested-by: default avatarBenni Mack <benni@typo3.org>
Reviewed-by: default avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
Tested-by: default avatarcore-ci <typo3@b13.com>
Reviewed-by: default avatarBenni Mack <benni@typo3.org>
      ed503f90
  41. Dec 04, 2023
  43. Dec 02, 2023
  45. Nov 29, 2023
  47. Nov 27, 2023
  49. Nov 25, 2023
  51. Nov 14, 2023
  53. Nov 07, 2023
  55. Nov 06, 2023
  57. Nov 02, 2023
  59. Oct 31, 2023
  61. Oct 30, 2023
  63. Oct 24, 2023
  65. Oct 18, 2023
    • Benjamin Franzke's avatar
      [TASK] Add phpstan check for unneeded pseudo uncertain instanceof usage · 6c0b5518
      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/+/80859


Tested-by: default avatarAndreas Kienast <a.fernandez@scripting-base.de>
Tested-by: default avatarcore-ci <typo3@b13.com>
Tested-by: default avatarOliver Hader <oliver.hader@typo3.org>
Reviewed-by: default avatarOliver Hader <oliver.hader@typo3.org>
Tested-by: default avatarBenjamin Franzke <ben@bnf.dev>
Reviewed-by: default avatarBenjamin Franzke <ben@bnf.dev>
Reviewed-by: default avatarAndreas Kienast <a.fernandez@scripting-base.de>
Reviewed-by: default avatarNikita Hovratov <nikita.h@live.de>
      6c0b5518
  67. Oct 10, 2023