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. Oct 27, 2023
  3. Oct 26, 2023
  5. Oct 25, 2023
  7. Oct 24, 2023
  9. Oct 23, 2023
  11. Oct 22, 2023
  13. Oct 20, 2023
  15. Oct 19, 2023
  17. Oct 18, 2023
    • Markus Klein's avatar
      [BUGFIX] Handle missing TCA|ctrl|title in recycler schedule task · 42669735
      Markus Klein authored 
      `$TCA['ctrl']['title']` is optional and may
not be set.

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


Reviewed-by: default avatarAndreas Kienast <a.fernandez@scripting-base.de>
Tested-by: default avatarcore-ci <typo3@b13.com>
Tested-by: default avatarAndreas Kienast <a.fernandez@scripting-base.de>
      42669735
    • Jan Greth's avatar
      [BUGFIX] Adjust config file path in Install Tool password hint · 1c4e8017
      Jan Greth authored 
      The file `settings.php`, which stores the value of
$GLOBALS['TYPO3_CONF_VARS']['BE']['installToolPassword'] is
located under `config/system/` in Composer-mode. If a project
is not set up with composer it is `typo3conf/system/`.

The hint next to the Install Tool's login mask spells the wrong
path, which is corrected with this patch. Also the difference
between legacy and composer setups is taken into account, without
exposing information about the projects file structure.

Resolves: #102166
Releases: main, 12.4
Change-Id: I5b2313516c1af9623a9c8de8f1dca7bb46fb8ce0
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/81456


Tested-by: default avatarNikita Hovratov <nikita.h@live.de>
Tested-by: default avatarcore-ci <typo3@b13.com>
Reviewed-by: default avatarNikita Hovratov <nikita.h@live.de>
      1c4e8017
    • Christoph Lehmann's avatar
      [BUGFIX] Prevent superfluous SELECT DATABASE() statements · 3a62b4ff
      Christoph Lehmann authored 
      They are executed to build a descriptive cache identifier and
the database name is now received from configuration instead
firing an SQL query.

SQLite for example does not have a database name, here 'generic'
is used as fallback.

Resolves: #102174
Releases: main, 12.4

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


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>
      3a62b4ff
    • Georg Ringer's avatar
      [BUGFIX] Allow more TCA types for reaction fields · 0335da49
      Georg Ringer authored 
      More TCA types must be allowed for field mapping of reactions.

Resolves: #102180
Releases: main, 12.4
Change-Id: I33327e7d083f9b31ab8e1764255eb5e7aa111d70
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/81454


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>
      0335da49
    • 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
  19. Oct 17, 2023
  21. Oct 16, 2023
    • Oliver Hader's avatar
      [BUGFIX] Provide CSP ReportRepository ONLY_FULL_GROUP_BY support · 1907d333
      Oliver Hader authored 
      Some database systems like PostgresSQL and MySQL are really
picky if selected columns are not contained in all group and
order selections or no aggregation method is used
(aka 'ONLY_FULL_GROUP_BY').

That may be influenced by server configuration, which makes
it really hard to come up with a minmal grouping query if:

* not all used `ORDER BY` fields are included in
  the `GROUP BY` selection
* not all `GROUP BY` fields are contained in the
  `SELECT` field list
* Fields in the `SELECT` list are not included in
  the `GROUP BY` list OR using a aggregation function
  like `MAX()`, `MIN()`, `AVG(), `SUM()` and similar.

Aggregation function cannot be used for non numeric values like
`uuid like` strings and prevent to group on a field but retrieve
the uinique id (UUID, uid, ) of the `first` or  `last` record per
group in on query.

To get a similar effect through all database vendor and without
requiring specific, mostly not default database settings provided
by many hosting provider or in default configuration for databases,
this change introduces a nested inner join construct with to ensure
the same result across multiple systems.

Resolves: #101913
Releases: main, 12.4
Change-Id: I28fa36db46d8219fc67a5503509e2a92a71ea6a7
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/81435


Tested-by: default avatarOliver Hader <oliver.hader@typo3.org>
Reviewed-by: default avatarOliver Hader <oliver.hader@typo3.org>
Tested-by: default avatarcore-ci <typo3@b13.com>
      1907d333
  23. Oct 15, 2023