Packages/TYPO3.CMS.git
11 hours ago[!!!][TASK] Remove deprecated constants and runtime activated packages 84/64584/5 master
Benni Mack [Tue, 26 May 2020 14:31:51 +0000 (16:31 +0200)]
[!!!][TASK] Remove deprecated constants and runtime activated packages

This change removes the unneeded public constants

- FILE_DENY_PATTERN_DEFAULT
- PHP_EXTENSIONS_DEFAULT
- TYPO3_copyright_year
- TYPO3_URL_DONATE
- TYPO3_URL_EXCEPTION
- TYPO3_URL_GENERAL
- TYPO3_URL_LICENSE
- TYPO3_URL_WIKI_OPCODECACHE

as well as the runtimeActivatedPackages feature, all of which have
been marked as deprecated in TYPO3 v10.

Resolves: #91477
Related: #91473
Releases: master
Change-Id: I8e98509e2842d7fb116f44c31d4c10957b73a2ca
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64584
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Anja Leichsenring <aleichsenring@ab-softlab.de>
Tested-by: Wouter Wolters <typo3@wouterwolters.nl>
Tested-by: Benni Mack <benni@typo3.org>
Reviewed-by: Anja Leichsenring <aleichsenring@ab-softlab.de>
Reviewed-by: Wouter Wolters <typo3@wouterwolters.nl>
Reviewed-by: Benni Mack <benni@typo3.org>
13 hours ago[!!!][TASK] Remove deprecated TSFE hooks and output functionality 83/64583/4
Benni Mack [Tue, 26 May 2020 14:24:08 +0000 (16:24 +0200)]
[!!!][TASK] Remove deprecated TSFE hooks and output functionality

This change removes deprecated hooks and methods from TSFE
related to output:

* TSFE->isOutputting()
* TSFE->processContentForOutput()
* TSFE->settingLocale()
* $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['hook_eofe']
* $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['pageIndexing']
* $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['isOutputting']
* $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['tslib_fe-contentStrReplace']
* $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['contentPostProc-output']

Resolves: #91476
Releases: master
Change-Id: I2711924dce00ad2cd1ec9a236d8fde9da0105a65
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64583
Tested-by: Wouter Wolters <typo3@wouterwolters.nl>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Anja Leichsenring <aleichsenring@ab-softlab.de>
Reviewed-by: Wouter Wolters <typo3@wouterwolters.nl>
Reviewed-by: Anja Leichsenring <aleichsenring@ab-softlab.de>
14 hours ago[!!!][TASK] Remove deprecated Signals from SignalSlot Dispatcher 78/64578/4
Benni Mack [Tue, 26 May 2020 10:57:11 +0000 (12:57 +0200)]
[!!!][TASK] Remove deprecated Signals from SignalSlot Dispatcher

This change removes all triggers ("SlotReplacement classes") to Signals
that were used until TYPO3 v10 LTS.

The SignalSlot Dispatcher still stay for the time being, but it is unused in
TYPO3 Core now.

Resolves: #91474
Related: #91473
Releases: master
Change-Id: I08867cb5837f605e52a067457a91f40288556fab
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64578
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Andreas Fernandez <a.fernandez@scripting-base.de>
Tested-by: Wouter Wolters <typo3@wouterwolters.nl>
Tested-by: Benni Mack <benni@typo3.org>
Reviewed-by: Andreas Fernandez <a.fernandez@scripting-base.de>
Reviewed-by: Wouter Wolters <typo3@wouterwolters.nl>
Reviewed-by: Benni Mack <benni@typo3.org>
19 hours ago[TASK] Raise friendsoftypo3/typo3-phpstan 81/64581/2
Benni Mack [Tue, 26 May 2020 12:43:02 +0000 (14:43 +0200)]
[TASK] Raise friendsoftypo3/typo3-phpstan

Used composer command:

  composer req "friendsoftypo3/phpstan-typo3:^0.3.0" --dev

Resolves: #91494
Releases: master
Change-Id: I94cc5fe935dd3c48c570cf630d34c0754fcd6d5b
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64581
Tested-by: Benni Mack <benni@typo3.org>
Reviewed-by: Benni Mack <benni@typo3.org>
23 hours ago[BUGFIX] Add FIRST_INSTALL to .gitignore 39/64239/5
Thomas Pronold [Sat, 18 Apr 2020 17:02:49 +0000 (19:02 +0200)]
[BUGFIX] Add FIRST_INSTALL to .gitignore

In order to avoid accidentally committing a FIRST_INSTALL
for developers starting to contribute to TYPO3 Core
and using Core git repository for its basis local development
setup, the FIRST_INSTALL file is ignored from git.

Resolves: #91119
Releases: master, 10.4, 9.5
Change-Id: Iad459240bbc8a68892f03adf547373bc608f6a90
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64239
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Josef Glatz <josefglatz@gmail.com>
Tested-by: Benni Mack <benni@typo3.org>
Reviewed-by: Josef Glatz <josefglatz@gmail.com>
Reviewed-by: Benni Mack <benni@typo3.org>
25 hours ago[TASK] Raise version to 11.0.0-dev 73/64573/3
Benni Mack [Mon, 25 May 2020 18:34:38 +0000 (20:34 +0200)]
[TASK] Raise version to 11.0.0-dev

This change reflects the master branch to be targeted to v11.

Testing framework is raised as well to support v11.

This also means that all bugfixes now need to target "master, 10.4"
or "master, 10.4, 9.5" for critical bugfixes.

All features go into master branch again.

Resolves: #91469
Releases: master
Change-Id: Ife0f9d0fcf5ff13d55acb89dee5138e0e0b781e9
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64573
Tested-by: Andreas Fernandez <a.fernandez@scripting-base.de>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Andreas Fernandez <a.fernandez@scripting-base.de>
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
36 hours ago[BUGFIX] Use proper version range in Git hook 75/64575/2
Oliver Hader [Mon, 25 May 2020 19:16:45 +0000 (21:16 +0200)]
[BUGFIX] Use proper version range in Git hook

Resolves: #91471
Releases: master, 10.4, 9.5
Change-Id: Ib008a46cc2edb368fed3fc937858f1f3870938b5
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64575
Tested-by: Benni Mack <benni@typo3.org>
Reviewed-by: Benni Mack <benni@typo3.org>
40 hours ago[TASK] Cover BackendUserAuthentication->returnWebmounts() with test 57/64557/4
Tymoteusz Motylewski [Wed, 20 May 2020 20:59:59 +0000 (22:59 +0200)]
[TASK] Cover BackendUserAuthentication->returnWebmounts() with test

Also fix misleading comment about permissions.

Resolves: #91454
Releases: 9.5, master
Change-Id: I1a399f1be613f007440bf542441bee60f53e49e0
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64557
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Andreas Fernandez <a.fernandez@scripting-base.de>
Tested-by: Richard Haeser <richard@maxserv.com>
Tested-by: Tymoteusz Motylewski <t.motylewski@gmail.com>
Reviewed-by: Andreas Fernandez <a.fernandez@scripting-base.de>
Reviewed-by: Richard Haeser <richard@maxserv.com>
Reviewed-by: Tymoteusz Motylewski <t.motylewski@gmail.com>
40 hours ago[BUGFIX] Disallow deleting extensions in Composer mode 68/64568/4
Andreas Fernandez [Sun, 24 May 2020 09:50:57 +0000 (11:50 +0200)]
[BUGFIX] Disallow deleting extensions in Composer mode

Deleting an extension in Extension Manager doesn't make much sense in a
Composer-based installation. For this reason, the removal of extensions
is prohibited now.

Resolves: #91456
Releases: master, 9.5
Change-Id: Ia96cf2741fd749d9f50540366351c8b576cac96b
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64568
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Markus Klein <markus.klein@typo3.org>
Tested-by: Benjamin Franzke <bfr@qbus.de>
Reviewed-by: Simon Gilli <typo3@gilbertsoft.org>
Reviewed-by: Mathias Brodala <mbrodala@pagemachine.de>
Reviewed-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by: Oliver Klee <typo3-coding@oliverklee.de>
Reviewed-by: Markus Klein <markus.klein@typo3.org>
Reviewed-by: Benjamin Franzke <bfr@qbus.de>
4 days ago[TASK] Add new file object to AfterFileCopiedEvent 78/64478/4
Benni Mack [Tue, 12 May 2020 19:59:05 +0000 (21:59 +0200)]
[TASK] Add new file object to AfterFileCopiedEvent

The PSR-14 event "AfterFileCopiedEvent" in FAL now also
has the possibility to return the newly created file
and the identifier.

Resolves: #91373
Releases: master
Change-Id: I08a01a0424e37fe2f010d2894d41a14628bdc950
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64478
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Daniel Goerz <daniel.goerz@posteo.de>
Tested-by: Susanne Moog <look@susi.dev>
Reviewed-by: Daniel Goerz <daniel.goerz@posteo.de>
Reviewed-by: Susanne Moog <look@susi.dev>
4 days ago[BUGFIX] Allow to set replyTo email address in ext:felogin 59/64559/2
chris [Thu, 21 May 2020 14:26:06 +0000 (14:26 +0000)]
[BUGFIX] Allow to set replyTo email address in ext:felogin

If the TypoScript variable `plugin.tx_felogin_pi1.replyTo` was set to
an email address, it triggered the following error:
`Symfony\\Component\\Mime\\Exception\\InvalidArgumentException: An address
can be an instance of Address or a string (\"array\") given)`

Releases: master
Resolves: #91458
Change-Id: I4179d42025d0373cd1d7c0938a83ec0c90e25465
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64559
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Susanne Moog <look@susi.dev>
Tested-by: Daniel Goerz <daniel.goerz@posteo.de>
Reviewed-by: Susanne Moog <look@susi.dev>
Reviewed-by: Guido Schmechel <guido.schmechel@brandung.de>
Reviewed-by: Daniel Goerz <daniel.goerz@posteo.de>
4 days ago[TASK] Convert ckeditor4 sources from CRLF to LF in grunt npmcopy 81/64481/7
Benjamin Franzke [Tue, 12 May 2020 21:46:29 +0000 (23:46 +0200)]
[TASK] Convert ckeditor4 sources from CRLF to LF in grunt npmcopy

Git converts CRLF to LF when plaintext files are staged. The existing
copies of the rte_ckeditor Contrib/* sources have therefore already been
converted to LF by git [1]. Initially these files had been copied as CRLF
from the ckeditor4 sources in node_modules by grunt npmcopy.

Now, when `yarn build` is executed, the copy operation is performed again,
which means the files are reverted back to CRLF. Git therefore needs to
perform the CRLF to LF conversion again. (Which itself needs to be
triggered by the developer by staging the changed files)

We do now mimic git`s autocrlf behaviour and replace CRLF by LF in the
files copied from ckeditor Contrib/* folders to prevent the files
from clobbering the `git status` or `git diff` output.

By passing `encoding: null` to the grunt.file.copy options we ensure
that binary files will be copied as is.

Also configure *.svg files to be checked out as LF on all platforms
(namely windows) like we do for other plaintext files as well.
This ensures svg files do not show up (in windows) as changed because
their original from node_modules was stored as LF.
*.patch is added as patching jquery on windows would fail otherwise.

[1] https://git-scm.com/docs/gitattributes#_end_of_line_conversion

Resolves: #91374
Releases: master, 9.5
Change-Id: I2977a6d44f96f6593152bfe698ba5d35f32b131f
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64481
Tested-by: Andreas Fernandez <a.fernandez@scripting-base.de>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Susanne Moog <look@susi.dev>
Reviewed-by: Andreas Fernandez <a.fernandez@scripting-base.de>
Reviewed-by: Susanne Moog <look@susi.dev>
4 days ago[BUGFIX] Do not mark repeatable wizards executed during install 26/64326/5
Helmut Hummel [Mon, 27 Apr 2020 20:53:38 +0000 (22:53 +0200)]
[BUGFIX] Do not mark repeatable wizards executed during install

The point of repeatable update wizards is that they are not
marked executed and thus always checked for possible updates.

They therefore must not be marked executed during installation.

Resolves: #91211
Releases: master, 9.5
Change-Id: Ic4e98b95711433705f77899d664cc7cf2c7a42ba
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64326
Reviewed-by: Andreas Fernandez <a.fernandez@scripting-base.de>
Reviewed-by: Daniel Goerz <daniel.goerz@posteo.de>
Reviewed-by: Markus Klein <markus.klein@typo3.org>
Reviewed-by: Josef Glatz <josefglatz@gmail.com>
Reviewed-by: Susanne Moog <look@susi.dev>
Tested-by: Daniel Goerz <daniel.goerz@posteo.de>
Tested-by: Markus Klein <markus.klein@typo3.org>
Tested-by: Susanne Moog <look@susi.dev>
Tested-by: TYPO3com <noreply@typo3.com>
4 days ago[BUGFIX] Respect showHiddenFiles in filelist module 24/64424/4
Stefan Froemken [Wed, 6 May 2020 09:19:42 +0000 (11:19 +0200)]
[BUGFIX] Respect showHiddenFiles in filelist module

Activating "showHiddenFilesAndFolders" in BE User
settings shows hidden files and folders also when
navigating through the files in filelist module.

Resolves: #91309
Releases: master, 9.5
Change-Id: I8f04b43a2cc0df93b6e77290caed2b33c6951e44
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64424
Tested-by: Daniel Goerz <daniel.goerz@posteo.de>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Susanne Moog <look@susi.dev>
Reviewed-by: Daniel Goerz <daniel.goerz@posteo.de>
Reviewed-by: Guido Schmechel <guido.schmechel@brandung.de>
Reviewed-by: Susanne Moog <look@susi.dev>
4 days ago[TASK] Clean up admin panel types 58/64558/2
Susanne Moog [Thu, 21 May 2020 13:33:36 +0000 (15:33 +0200)]
[TASK] Clean up admin panel types

Resolves: #91457
Releases: master
Change-Id: I29009a9498b050942e34a27815acdf996e6f0539
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64558
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Daniel Goerz <daniel.goerz@posteo.de>
Tested-by: Andreas Fernandez <a.fernandez@scripting-base.de>
Reviewed-by: Daniel Goerz <daniel.goerz@posteo.de>
Reviewed-by: Andreas Fernandez <a.fernandez@scripting-base.de>
4 days ago[TASK] Move iconFactory initialization out of loop 61/64561/2
Oliver Bartsch [Fri, 22 May 2020 09:26:18 +0000 (11:26 +0200)]
[TASK] Move iconFactory initialization out of loop

Resolves: #91459
Relates: #91302
Releases: master
Change-Id: Ic4af3247d7557a6c12a8d538e85795c507eab69a
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64561
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Benni Mack <benni@typo3.org>
Tested-by: Daniel Goerz <daniel.goerz@posteo.de>
Reviewed-by: Benni Mack <benni@typo3.org>
Reviewed-by: Andreas Fernandez <a.fernandez@scripting-base.de>
Reviewed-by: Oliver Klee <typo3-coding@oliverklee.de>
Reviewed-by: Daniel Goerz <daniel.goerz@posteo.de>
4 days ago[BUGFIX] Bring back record type icons for select items 60/64560/2
Oliver Bartsch [Thu, 21 May 2020 19:17:13 +0000 (21:17 +0200)]
[BUGFIX] Bring back record type icons for select items

With the removal of `selicon_field_path` in #87937 also the
automatic record type icon mapping was removed.

As a result the record icon of a select item based on `foreign_table`
is not resolved anymore. In addition, the `selectIcons` list is therefore
no longer displayed.

The previous functionality is now restored.

Resolves: #91302
Relates: #87937
Releases: master
Change-Id: If62f4ba65ef54ec2345131f6c117ce4336e76c4c
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64560
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Benni Mack <benni@typo3.org>
Tested-by: Daniel Goerz <daniel.goerz@posteo.de>
Reviewed-by: Markus Klein <markus.klein@typo3.org>
Reviewed-by: Benni Mack <benni@typo3.org>
Reviewed-by: Daniel Goerz <daniel.goerz@posteo.de>
5 days ago[TASK] Improve descriptions of the rootline related methods 54/64554/4
Tymoteusz Motylewski [Tue, 19 May 2020 22:13:34 +0000 (00:13 +0200)]
[TASK] Improve descriptions of the rootline related methods

To highlight difference between BackendUtility::BEgetRootLine()
and RootlineUtility->get()

Resolves: #91455
Releases: 9.5, master
Change-Id: I63d7ca395d5a052d29d718316474b69d6519ebc9
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64554
Tested-by: Daniel Goerz <daniel.goerz@posteo.de>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Richard Haeser <richard@maxserv.com>
Reviewed-by: Daniel Goerz <daniel.goerz@posteo.de>
Reviewed-by: Oliver Klee <typo3-coding@oliverklee.de>
Reviewed-by: Richard Haeser <richard@maxserv.com>
5 days ago[BUGFIX] Prevent null pointer exception in LocalizationUtility 08/64508/2
Oliver Bartsch [Sun, 17 May 2020 11:46:11 +0000 (13:46 +0200)]
[BUGFIX] Prevent null pointer exception in LocalizationUtility

Resolves: #91345
Releases: master
Change-Id: I54ab67e85b3bf24b06916b674765ed22fb5de76c
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64508
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Georg Ringer <georg.ringer@gmail.com>
Tested-by: Josef Glatz <josefglatz@gmail.com>
Tested-by: Daniel Goerz <daniel.goerz@posteo.de>
Reviewed-by: Georg Ringer <georg.ringer@gmail.com>
Reviewed-by: Oliver Klee <typo3-coding@oliverklee.de>
Reviewed-by: Josef Glatz <josefglatz@gmail.com>
Reviewed-by: Daniel Goerz <daniel.goerz@posteo.de>
5 days ago[BUGFIX] Disable trigger buttons in Install Tool when actions are executed 07/64207/11
Andreas Fernandez [Fri, 17 Apr 2020 06:55:54 +0000 (08:55 +0200)]
[BUGFIX] Disable trigger buttons in Install Tool when actions are executed

If an action in the Install Tool is executed that is related to an
inline module or an interactable module (a.k.a "modal"), its trigger
button(s) get now properly disabled and enabled to avoid executing the
same actions consecutively while any request is still pending.

Resolves: #91076
Releases: master
Change-Id: I9a61063819f21a33ac8ede644fa8f998212b342b
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64207
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Jonas Eberle <flightvision@googlemail.com>
Tested-by: Anja Leichsenring <aleichsenring@ab-softlab.de>
Tested-by: Susanne Moog <look@susi.dev>
Reviewed-by: Anja Leichsenring <aleichsenring@ab-softlab.de>
Reviewed-by: Susanne Moog <look@susi.dev>
6 days ago[BUGFIX] Fix handling of deprecated cache configuration 07/64407/6
Markus Klein [Tue, 5 May 2020 11:33:19 +0000 (13:33 +0200)]
[BUGFIX] Fix handling of deprecated cache configuration

When initializing the configuration for a cache any existing
configuration under its old name (cache_ prefixed) is applied
as an additive override now. This ensures that basic configuration
like groups are preserved and not removed with the formerly correct
way to adjust cache-config.

Resolves: #91306
Releases: master
Change-Id: Ic862f80263f410688d2dffb7c13948c1c40488a3
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64407
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Johannes Kasberger <johannes.kasberger@reelworx.at>
Tested-by: Georg Ringer <georg.ringer@gmail.com>
Tested-by: Benjamin Franzke <bfr@qbus.de>
Reviewed-by: Johannes Kasberger <johannes.kasberger@reelworx.at>
Reviewed-by: Georg Ringer <georg.ringer@gmail.com>
Reviewed-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by: Benjamin Franzke <bfr@qbus.de>
6 days ago[BUGFIX][DOCS] Clarify lowlevel cleanup commands 30/64530/2
Benni Mack [Tue, 19 May 2020 14:19:07 +0000 (16:19 +0200)]
[BUGFIX][DOCS] Clarify lowlevel cleanup commands

The documentation for lowlevel commands are optimized so they make
more sense:

* Nightly checks are run with a --dry-run command
* cleanup:versions info is removed (the command is gone)
* Checks have a --dry-run command

Resolves: #88874
Releases: master, 9.5
Change-Id: If82ab67f7aec48c1b533e84d70ecdadc94e528bd
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64530
Reviewed-by: Tobias Gaertner <tobias.gaertner@benaja-websolutions.com>
Reviewed-by: Georg Ringer <georg.ringer@gmail.com>
Reviewed-by: Benni Mack <benni@typo3.org>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Georg Ringer <georg.ringer@gmail.com>
Tested-by: Benni Mack <benni@typo3.org>
6 days ago[BUGFIX] Correctly evaluate PageTS in TemplateModule 53/64553/2
Helmut Hummel [Tue, 19 May 2020 21:13:13 +0000 (23:13 +0200)]
[BUGFIX] Correctly evaluate PageTS in TemplateModule

Set the current page id early, so that PageTS is fetched
from the correct page instead of id 0.

Releases: 9.5, master
Resolves: #91445
Change-Id: I95a50b6c9d45be54291f27828d9f35cb62b3b4dd
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64553
Reviewed-by: Daniel Siepmann <coding@daniel-siepmann.de>
Reviewed-by: Thomas Hohn
Reviewed-by: Benni Mack <benni@typo3.org>
Reviewed-by: Helmut Hummel <typo3@helhum.io>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Benni Mack <benni@typo3.org>
Tested-by: Helmut Hummel <typo3@helhum.io>
7 days ago[TASK] Set TYPO3 version to 10.4.4-dev 29/64529/2
Oliver Hader [Tue, 19 May 2020 13:17:39 +0000 (15:17 +0200)]
[TASK] Set TYPO3 version to 10.4.4-dev

Change-Id: I22eb57766cd6ddd8aa31447ccd374e52920c2010
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64529
Tested-by: Oliver Hader <oliver.hader@typo3.org>
Tested-by: TYPO3com <noreply@typo3.com>
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
7 days ago[RELEASE] Release of TYPO3 10.4.3 28/64528/2 v10.4.3
Oliver Hader [Tue, 19 May 2020 13:16:03 +0000 (15:16 +0200)]
[RELEASE] Release of TYPO3 10.4.3

Change-Id: Ifd8e3cc62c5b0a27b0bc938e5dbc8cb136a1d07c
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64528
Tested-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
7 days ago[BUGFIX] Loosen site check for records not stored in site context 20/64520/5
Helmut Hummel [Tue, 19 May 2020 10:09:55 +0000 (12:09 +0200)]
[BUGFIX] Loosen site check for records not stored in site context

When saving a record on a page that is not part of a site,
the slug field of this record, despite being set to "uniqueInSite"
is not checked for uniqueness, as it is assumed unique enough.

This assumption needs to be applied as well when resolving
the record, instead of assuming the resolved record is not part
of the current site.

Releases: master, 9.5
Resolves: #91438
Change-Id: I347909b9b4caa523de3ad8e5d84c465e5d57b052
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64520
Reviewed-by: Benni Mack <benni@typo3.org>
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Oliver Hader <oliver.hader@typo3.org>
7 days ago[BUGFIX] Re-add initialization of PageRepository::$where_groupAccess 16/64516/3
Thomas Hohn [Mon, 18 May 2020 12:48:08 +0000 (14:48 +0200)]
[BUGFIX] Re-add initialization of PageRepository::$where_groupAccess

Re-added `$this->where_groupAccess` to init method.

Resolves: #91429
Releases: master, 9.5
Change-Id: Ibd9b169e8d11e358023d8cfbd2085995769d16cc
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64516
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Benni Mack <benni@typo3.org>
Tested-by: Georg Ringer <georg.ringer@gmail.com>
Reviewed-by: Benni Mack <benni@typo3.org>
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Georg Ringer <georg.ringer@gmail.com>
7 days ago[BUGFIX] Fixed order-by while querying old realurl table for slugs 85/64085/3
Riny van Tiggelen [Mon, 6 Apr 2020 08:57:30 +0000 (10:57 +0200)]
[BUGFIX] Fixed order-by while querying old realurl table for slugs

The old tx_realurl_pathcache does not have a uid field, but uses the
field cache_id. The order-by now uses a different field depending on
the table.

Resolves: #90957
Releases: master, 9.5
Change-Id: I5efc62cb8a7cc1d96a503043d268fdacb3564e4b
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64085
Reviewed-by: Richard Haeser <richard@maxserv.com>
Reviewed-by: Guido Schmechel <guido.schmechel@brandung.de>
Reviewed-by: Daniel Siepmann <coding@daniel-siepmann.de>
Reviewed-by: Benni Mack <benni@typo3.org>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Richard Haeser <richard@maxserv.com>
Tested-by: Benni Mack <benni@typo3.org>
8 days ago[BUGFIX] Allow referrer refresh in install tool 19/64519/2
Oliver Hader [Mon, 18 May 2020 21:29:40 +0000 (23:29 +0200)]
[BUGFIX] Allow referrer refresh in install tool

With TYPO3-CORE-SA-2020-006 (SSRF via XSS) a strict referrer handling
has been introduced to avoid the install tool being called from other
non same-origin locations. In case a HTTP referrer header was empty
the system tried to refresh the view - otherwise the request was
denied completely.

Changes of issue #91396 using refresh-always are applied as well.

Resolves: #91433
Related: #91396
Releases: master, 9.5
Change-Id: I2a570da4f2a933e709d653b54f1d53d5055ef3f7
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64519
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
8 days ago[BUGFIX] Use checksum of frontend groups in cache identifier 12/64512/3
Andreas Fernandez [Mon, 18 May 2020 09:25:25 +0000 (11:25 +0200)]
[BUGFIX] Use checksum of frontend groups in cache identifier

The generated cache identifier may get very long in case a page has many
frontend groups configured and may exceeds the limit of the caching
frontend (which is 250 characthers per definition in
FrontendInterface::PATTERN_ENTRYIDENTIFIER). To bypass this issue, the
group list is hashed now.

Resolves: #91413
Related: #91208
Releases: master, 9.5
Change-Id: Id44ae862eb5d45afbd49dc3f833c101c6acb5f5b
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64512
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Frank W Blank <blank@wiro-consultants.com>
Tested-by: Benjamin Franzke <bfr@qbus.de>
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Benjamin Franzke <bfr@qbus.de>
8 days ago[BUGFIX] Fix serialization of ObjectManager 89/64489/3
Benjamin Franzke [Wed, 13 May 2020 15:11:52 +0000 (17:11 +0200)]
[BUGFIX] Fix serialization of ObjectManager

The PSR-11 container instance was not cleared upon serialization which
caused an exception when Closures in the container where tried to be
serialized.

__wakeup() does already contain code to reset the container instance,
therefore we only need to clear the entire object manager properties
in __sleep().

Releases: master
Resolves: #91398
Related: #88689
Change-Id: I58202752577b58cd882d13f471af1e045c9a4187
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64489
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Alexander Schnitzler <git@alexanderschnitzler.de>
Tested-by: Andreas Fernandez <a.fernandez@scripting-base.de>
Reviewed-by: Alexander Schnitzler <git@alexanderschnitzler.de>
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Susanne Moog <look@susi.dev>
Reviewed-by: Andreas Fernandez <a.fernandez@scripting-base.de>
8 days ago[TASK] Add missing documentation for BackendUserConfigurationUpdate 02/64502/3
Oliver Hader [Sat, 16 May 2020 10:49:55 +0000 (12:49 +0200)]
[TASK] Add missing documentation for BackendUserConfigurationUpdate

Resolves: #91417
Releases: master, 9.5
Change-Id: I690cf19965310cdb8612dca3b34f751aafb4c550
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64502
Reviewed-by: Susanne Moog <look@susi.dev>
Reviewed-by: Daniel Siepmann <coding@daniel-siepmann.de>
Reviewed-by: Daniel Goerz <daniel.goerz@posteo.de>
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
Tested-by: Daniel Siepmann <coding@daniel-siepmann.de>
Tested-by: Daniel Goerz <daniel.goerz@posteo.de>
Tested-by: Oliver Hader <oliver.hader@typo3.org>
8 days ago[BUGFIX] Set controller object name for widget request 05/64505/5
Alexander Schnitzler [Sat, 16 May 2020 17:32:19 +0000 (19:32 +0200)]
[BUGFIX] Set controller object name for widget request

While introducing the fully qualified controller class names
in the extbase plugin configuration the originally used setter
\TYPO3\CMS\Extbase\Mvc\Request::setControllerObjectName() has
no longer been used to guess extension name, subpackage key and
controller name from the class name since all that information
is known. Said setter has been kept nevertheless and it was
overlooked that it was still used by fluid widgets. This leads
to property \TYPO3\CMS\Extbase\Mvc\Request::$controllerObjectName
being empty in widget requests which then leads to an exception
when trying to create a ClassSchema for the controller object
name "".

To fix this, the widget request is now created with the controller
object name as constructor argument.

Releases: master
Resolves: #91418
Change-Id: I6abcdb8c68e831459228cc35c3263cec83d16f67
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64505
Tested-by: Susanne Moog <look@susi.dev>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Susanne Moog <look@susi.dev>
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
8 days ago[BUGFIX] Properly (un)serialize ReflectionService 94/64494/8
Alexander Schnitzler [Thu, 14 May 2020 17:00:32 +0000 (19:00 +0200)]
[BUGFIX] Properly (un)serialize ReflectionService

The ReflectionService usually doesn't get serialized by users
directly but since Extbase has an unclean dependency chain, the
serialization of the ReflectionService is triggered in user land
code when serializing a LazyObjectStorage e.g.

Since it's no problem to implement a clean serialization and
unserialization of the ReflectionService it is implemented with
this patch and will no longer cause any troubles.

There is just one thing to mention. The ReflectionService usually
comes with a cache which cannot be restored during wakeup of the
serialized service. It's unlikely but it's possible that the
absense of the cache can cause a performance hit.

Releases: master, 9.5
Resolves: #91404
Change-Id: I8c64968f0f329528c9f578ba0ef76437ada40ac0
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64494
Tested-by: Susanne Moog <look@susi.dev>
Tested-by: Benjamin Franzke <bfr@qbus.de>
Tested-by: TYPO3com <noreply@typo3.com>
Reviewed-by: Susanne Moog <look@susi.dev>
Reviewed-by: Benjamin Franzke <bfr@qbus.de>
8 days ago[BUGFIX] Allow arbitrary objects in widget context 01/64501/7
Oliver Hader [Sat, 16 May 2020 10:05:11 +0000 (12:05 +0200)]
[BUGFIX] Allow arbitrary objects in widget context

TYPO3-CORE-SA-2020-005 caused side-effects on Fluid AJAX widgets which
unfortunatelly support any class instance to be temporarily stored in
the current user-session. With mentioned change to address an insecure
deserialization vulnerability it was limited to items that could be
JSON-serialized.

This limitation is removed again by switching back to `unserialize()`,
but using an encryption-key-based HMAC signature on the payload.
Due to its architecture there is no better approach available.

This partially reverts commit e4fb92a85bed8067d45d2c25c4b559642f206248.

Resolves: #91382
Releases: master, 9.5
Change-Id: I68cbd15e7df2f536180f174fa63cf27f8a19cfcd
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64501
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Jonas Götze <jonnsn@gmail.com>
Tested-by: Alexander Schnitzler <git@alexanderschnitzler.de>
Tested-by: Andreas Fernandez <a.fernandez@scripting-base.de>
Tested-by: Susanne Moog <look@susi.dev>
Reviewed-by: Alexander Schnitzler <git@alexanderschnitzler.de>
Reviewed-by: Andreas Fernandez <a.fernandez@scripting-base.de>
Reviewed-by: Susanne Moog <look@susi.dev>
8 days ago[DOCS] Fix table syntax in changelog 10/64510/2
Daniel Siepmann [Mon, 18 May 2020 06:53:00 +0000 (08:53 +0200)]
[DOCS] Fix table syntax in changelog

Resolves: #91411
Releases: master
Change-Id: If9850f683e1f6e72e62fcfdb41802430d1888f69
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64510
Reviewed-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by: Josef Glatz <josefglatz@gmail.com>
Reviewed-by: Benjamin Franzke <bfr@qbus.de>
Reviewed-by: Daniel Siepmann <coding@daniel-siepmann.de>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Josef Glatz <josefglatz@gmail.com>
Tested-by: Daniel Siepmann <coding@daniel-siepmann.de>
8 days ago[BUGFIX] Allow multiple referrer types in backend main route 92/64492/4
Oliver Hader [Thu, 14 May 2020 14:47:04 +0000 (16:47 +0200)]
[BUGFIX] Allow multiple referrer types in backend main route

With TYPO3-CORE-SA-2020-006 (SSRF via XSS) a strict referrer handling
has been introduced to avoid the TYPO3 backend being called from other
non same-origin locations. In case a HTTP referrer header was empty
the system tried to refresh the view - otherwise the request was
denied completely.

It turned out that this scenario was probably too strict, disabling
feature `security.backend.enforceReferrer` was the only work-around
for site administrators.

This change adds new options for handling referrers in backend routes:
* refresh-empty (existed already): refresh in case referrer is empty
* refresh-same-site: refresh in case referrer is on same site, like
  `https://example.org/?eID=auth` calling `https://example.org/typo3/`
* refresh-always: refresh always in case there is not valid referrer

TYPO3's main backend route is using `refresh-always` now to be more
relaxed on handling same-site and cross-site referrers as well.

The term "refreshing" relates to trigger a reload in the browser to
get the referrer of the current location. This still block direct
CSRF/SSRF requests since the refreshing HTML instructions are
delivered back to the client. Besides that, cross-site requests are
covered by the `same-site` cookie policy, and existing CSRF tokens.

Resolves: #91396
Releases: master, 9.5
Change-Id: Ib3756671fa60c6f41ba992d0e645f03da1730d19
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64492
Tested-by: Susanne Moog <look@susi.dev>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Richard Haeser <richard@maxserv.com>
Reviewed-by: Susanne Moog <look@susi.dev>
Reviewed-by: Richard Haeser <richard@maxserv.com>
9 days ago[BUGFIX] Use SystemEmail layout in felogin password recovery 98/64498/3
Andreas Fernandez [Fri, 15 May 2020 12:49:14 +0000 (14:49 +0200)]
[BUGFIX] Use SystemEmail layout in felogin password recovery

The PasswordRecovery template misses a layout which results in an empty
HTML part being rendered. This patch adds the layout and renders our
marvellous HTML mails again.

The plaintext part missed the layout as well, which caused to miss some
additional information available in the mails.

Resolves: #91412
Related: #90729
Releases: master
Change-Id: Ic883aefa5ae88783d0c74d2c7843d1e8445461ab
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64498
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Annett Jähnichen <jaehnichen@webit.de>
Tested-by: Oliver Bartsch <bo@cedev.de>
Tested-by: Josef Glatz <josefglatz@gmail.com>
Tested-by: Andreas Fernandez <a.fernandez@scripting-base.de>
Reviewed-by: Annett Jähnichen <jaehnichen@webit.de>
Reviewed-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by: Josef Glatz <josefglatz@gmail.com>
Reviewed-by: Andreas Fernandez <a.fernandez@scripting-base.de>
9 days ago[DOCS] Correctly close tags in changelogs 88/64488/3
ayacoo [Thu, 14 May 2020 10:37:06 +0000 (10:37 +0000)]
[DOCS] Correctly close tags in changelogs

Releases: master
Resolves: #91395
Change-Id: If1c5c896c519aa5cf5ff35072bb101f718f8cdcb
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64488
Tested-by: Oliver Bartsch <bo@cedev.de>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Josef Glatz <josefglatz@gmail.com>
Tested-by: Tymoteusz Motylewski <t.motylewski@gmail.com>
Reviewed-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by: Oliver Klee <typo3-coding@oliverklee.de>
Reviewed-by: Josef Glatz <josefglatz@gmail.com>
Reviewed-by: Tymoteusz Motylewski <t.motylewski@gmail.com>
11 days ago[TASK] Namespaces for PSR-14 events corrected 97/64497/3
jdoe-dev [Fri, 15 May 2020 10:46:15 +0000 (10:46 +0000)]
[TASK] Namespaces for PSR-14 events corrected

The namespaces for the PSR-14 events are not working. Removed /Login -
path since this is not existing.

Releases: master
Resolves: #91411
Change-Id: I25209c739f1f55b8c375a9f58ad4ce551344ae5d
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64497
Tested-by: Mathias Brodala <mbrodala@pagemachine.de>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Susanne Moog <look@susi.dev>
Reviewed-by: Mathias Brodala <mbrodala@pagemachine.de>
Reviewed-by: Susanne Moog <look@susi.dev>
12 days ago[BUGFIX] Set changed state of FormEngine when null placeholder fields are changed 44/64444/3
Andreas Fernandez [Sun, 10 May 2020 13:36:54 +0000 (15:36 +0200)]
[BUGFIX] Set changed state of FormEngine when null placeholder fields are changed

When a null placeholder checkbox is changed, the linked form field is
now marked as "changed", which triggers the confirmation when leaving
the form while being unsaved.

Resolves: #91351
Releases: master, 9.5
Change-Id: I1b3ac08223a4a4c588a980abe70f22ff9814b13f
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64444
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Josef Glatz <josefglatz@gmail.com>
Tested-by: Xavier Perseguers <xavier@typo3.org>
Tested-by: Susanne Moog <look@susi.dev>
Reviewed-by: Josef Glatz <josefglatz@gmail.com>
Reviewed-by: Xavier Perseguers <xavier@typo3.org>
Reviewed-by: Susanne Moog <look@susi.dev>
12 days ago[BUGFIX] Check for existence of `t3js-login-url` id in Login dialog 84/64484/3
Oliver Hader [Wed, 13 May 2020 14:29:48 +0000 (16:29 +0200)]
[BUGFIX] Check for existence of `t3js-login-url` id in Login dialog

HTML element with identifier `t3js-login-url` is used to check whether
referrer handling is activated and suported. In case the `Login.html`
template has been overridden, mentioned element might not be given at
all - which leads to a corresponding JavaScript error.

Resolves: #91385
Releases: master, 9.5
Change-Id: Ie986a94209809c32cdfb217aa00b42f4369c525a
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64484
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Susanne Moog <look@susi.dev>
Tested-by: Andreas Fernandez <a.fernandez@scripting-base.de>
Reviewed-by: Susanne Moog <look@susi.dev>
Reviewed-by: Andreas Fernandez <a.fernandez@scripting-base.de>
12 days ago[BUGFIX] Fix SMTP encryption migration when plaintext was used before 90/64490/2
Benjamin Franzke [Thu, 14 May 2020 11:57:37 +0000 (13:57 +0200)]
[BUGFIX] Fix SMTP encryption migration when plaintext was used before

The SMTP SSL/TLS migration introduced in #91070 does not take the case
into account when no SMTP encryption was used at all (that means insecure
plaintext authentication). This could be configured by specifying an empty
string for `transport_smtp_encrypt` in TYPO3 v9.

We do now check for this third option and adapt the migration
to set the value to false, which means symfony/mailer will allow
connection without encryption. Note: symfony/mailer will still try to
start a STARTTLS connection if the server supports that capability.
(That is now default in symfony/mailer and can't be deactivated)

We also fix the default configuration of transport_smtp_encrypt
to be a boolean value. The setting was switched to boolean in #90295
but was forgotten to be adapted here.

Releases: master
Resolves: #91391
Related: #91070
Related: #90295
Change-Id: I16f0f19cf91b92b3a252d2a52c7226dd0eb23296
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64490
Reviewed-by: Josef Glatz <josefglatz@gmail.com>
Reviewed-by: Torben Hansen <derhansen@gmail.com>
Reviewed-by: Benjamin Franzke <bfr@qbus.de>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Josef Glatz <josefglatz@gmail.com>
Tested-by: Torben Hansen <derhansen@gmail.com>
Tested-by: Benjamin Franzke <bfr@qbus.de>
12 days ago[BUGFIX] Use correctly terminated HTML block elements 79/64479/2
Oliver Hader [Tue, 12 May 2020 20:11:27 +0000 (22:11 +0200)]
[BUGFIX] Use correctly terminated HTML block elements

Using `<div />` as template to be used in jQuery worked previously,
but is not supported with jQuery 3.5.x anymore. Occurences are now
using correct expanded tags like `<div></div>`.

Resolves: #91367
Releases: master, 9.5
Change-Id: I088481e607b4621e28550f79f065496c89b409d1
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64479
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Susanne Moog <look@susi.dev>
Tested-by: Sebastien Convers <sebastien.convers@agrosupdijon.fr>
Tested-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Daniel Goerz <daniel.goerz@posteo.de>
Reviewed-by: Susanne Moog <look@susi.dev>
Reviewed-by: Helmut Hummel <typo3@helhum.io>
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
12 days ago[BUGFIX] Exclude current record when checking slug's uniqueness 82/64482/3
Xavier Perseguers [Wed, 13 May 2020 09:52:20 +0000 (11:52 +0200)]
[BUGFIX] Exclude current record when checking slug's uniqueness

The current record constraint was forgotten in the
implementation of uniqueInTable and is now added.

Resolves: #91378
Related: #91235
Releases: master, 9.5
Change-Id: Ie7862b22a06996a9d7ca484a01d7a1859c8f7276
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64482
Tested-by: Helmut Hummel <typo3@helhum.io>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Benni Mack <benni@typo3.org>
Reviewed-by: Helmut Hummel <typo3@helhum.io>
Reviewed-by: Susanne Moog <look@susi.dev>
Reviewed-by: Benni Mack <benni@typo3.org>
12 days ago[BUGFIX] Relax constraints on serializing objects 86/64486/4
Oliver Hader [Wed, 13 May 2020 14:49:09 +0000 (16:49 +0200)]
[BUGFIX] Relax constraints on serializing objects

With security advisory TYPO3-CORE-SA-2020-004 new
`BlockSerializationTrait` has been introduced blocking serialization
and deserialization for a couple of classes (see advisory for details).
Since this caused a couple of side-effects for valid use-cases, the
restriction on serialize() is removed - which is fine from a security
point of view.

Resolves: #91387
Releases: master, 9.5
Change-Id: I9a9d415deab80badc3c1517f2e0c0c3336d3d936
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64486
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Markus Klein <markus.klein@typo3.org>
Tested-by: Georg Ringer <georg.ringer@gmail.com>
Tested-by: Oliver Bartsch <bo@cedev.de>
Tested-by: Andreas Fernandez <a.fernandez@scripting-base.de>
Reviewed-by: Markus Klein <markus.klein@typo3.org>
Reviewed-by: Georg Ringer <georg.ringer@gmail.com>
Reviewed-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by: Andreas Fernandez <a.fernandez@scripting-base.de>
13 days ago[BUGFIX] Open CSH with selected context provided by links 77/64477/4
Daniel Siepmann [Tue, 12 May 2020 15:40:58 +0000 (17:40 +0200)]
[BUGFIX] Open CSH with selected context provided by links

A context can be provided, when opening the CSH (Context Sensitive Help).

E.g. when opening the CSH for a backend module or specific table field,
the help entry for that module or field will be opened.

This patch restores the described functionality by adding the action
to the link opened via JavaScript.

The "see also" links, used for cross referencing different CSH entries
are fixed as well. Cross referencing links are now build using the proper
ViewHelper to use backend module routing, instead of extbase routing.
This ensures arguments are not moved into an arbitrary extbase plugin
namespace.

Resolves: #91370
Releases: master
Change-Id: Ib6361e5a5f4ef441e098a595fa344f484a07ddc0
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64477
Reviewed-by: Daniel Goerz <daniel.goerz@posteo.de>
Reviewed-by: Josef Glatz <josefglatz@gmail.com>
Reviewed-by: Sebastian Klein <laitnin@gmx.net>
Reviewed-by: Georg Ringer <georg.ringer@gmail.com>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Sebastian Klein <laitnin@gmx.net>
Tested-by: Josef Glatz <josefglatz@gmail.com>
Tested-by: Georg Ringer <georg.ringer@gmail.com>
13 days ago[BUGFIX] Remove wrong MethodCallStaticMatchers 51/64451/2
Markus Klein [Sun, 10 May 2020 20:28:55 +0000 (22:28 +0200)]
[BUGFIX] Remove wrong MethodCallStaticMatchers

Some methods have been added for this matcher,
which are actually not deprecated/removed as a
whole. Only the usage of those methods has been
adjusted.

The extension scanner is not capable of detecting
such usages only, hence there is no sense in
reporting every usage of those functions, albeit
these usages might be valid.

The matcher entries are removed therefore.

Resolves: #91355
Releases: master
Change-Id: I9da87ecb320f65d4fe5df168d788bb2ba8547f84
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64451
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Alexander Schnitzler <git@alexanderschnitzler.de>
Tested-by: Benjamin Franzke <bfr@qbus.de>
Reviewed-by: Alexander Schnitzler <git@alexanderschnitzler.de>
Reviewed-by: Benjamin Franzke <bfr@qbus.de>
2 weeks ago[TASK] Don't use GeneralUtility::getContainer in functional tests 56/64456/4
Benjamin Franzke [Mon, 11 May 2020 18:36:07 +0000 (20:36 +0200)]
[TASK] Don't use GeneralUtility::getContainer in functional tests

As GeneralUtility::getContainer is marked internal, we do now avoid
to use this method in core tests in order to demonstrate best
practices for third party extensions that may use core tests as
inspiration.

This change requires an update for typo3/testing-framework which now
provides a getContainer() method as API in functional tests:

  composer require --dev typo3/testing-framework:^6.2.5

Releases: master
Resolves: #91363
Change-Id: I844973ddd3355d15c72307ac9533429333a396da
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64456
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Susanne Moog <look@susi.dev>
Tested-by: Benni Mack <benni@typo3.org>
Reviewed-by: Susanne Moog <look@susi.dev>
Reviewed-by: Benni Mack <benni@typo3.org>
2 weeks ago[TASK] Set TYPO3 version to 10.4.3-dev 75/64475/2
Oliver Hader [Tue, 12 May 2020 10:42:49 +0000 (12:42 +0200)]
[TASK] Set TYPO3 version to 10.4.3-dev

Change-Id: I6e8b59634266786e07a0d80a6271914a26a7d7e4
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64475
Tested-by: Benni Mack <benni@typo3.org>
Reviewed-by: Benni Mack <benni@typo3.org>
2 weeks ago[RELEASE] Release of TYPO3 10.4.2 74/64474/2 v10.4.2
Oliver Hader [Tue, 12 May 2020 10:41:30 +0000 (12:41 +0200)]
[RELEASE] Release of TYPO3 10.4.2

Change-Id: I22d5494ecd9cf12efbd6a7acec0b23b000340905
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64474
Tested-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
2 weeks ago[SECURITY] Escape shortened placeholder text in HTML output 71/64471/2
Markus Klein [Tue, 12 May 2020 09:29:09 +0000 (11:29 +0200)]
[SECURITY] Escape shortened placeholder text in HTML output

Prevent XSS by escaping the shortened placeholder text for various
Backend form elements properly.

Resolves: #90817
Releases: master, 9.5
Change-Id: I58f61b2d3d902dd3cb07e97acf974156f100a8aa
Security-Bulletin: TYPO3-CORE-SA-2020-002
Security-References: CVE-2020-11064
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64471
Tested-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
2 weeks ago[SECURITY] Mitigate bypassing CSRF token via XSS 70/64470/2
Oliver Hader [Tue, 12 May 2020 09:22:17 +0000 (11:22 +0200)]
[SECURITY] Mitigate bypassing CSRF token via XSS

Cross-site scripting in same-site/same-origin context most probably
allows bypassing tokens that usually protects against cross-site
request forgery - basically that is obvious when focusing on
"cross-site" and "same-site" terminology.

To mitigate these scenarios, same-site requests from outside`/typo3/`
URI path - which is used to access the backend user interface - now
have to provide an HTTP `Referer` header which is enforced for global
routes potentially containing CSRF tokens.

In general all routes that switch their state internally from
`public` to `restricted` are relevant in this scenario. If really
necessary, the behavior can be disabled using corresponding feature
switch `security.backend.enforceReferrer` in TYPO3_CONF_VARS.

Resolves: #90681
Releases: master, 9.5
Change-Id: Id410fa73f1029cb131356e44b64637a5f12381e5
Security-Bulletin: TYPO3-CORE-SA-2020-006
Security-References: CVE-2020-11069
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64470
Tested-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
2 weeks ago[SECURITY] Avoid insecure deserialization of $BE_USER->uc properties 69/64469/2
Oliver Hader [Tue, 12 May 2020 09:22:10 +0000 (11:22 +0200)]
[SECURITY] Avoid insecure deserialization of $BE_USER->uc properties

General and unscoped collection of user settings in $BE_USER->uc is
vulnerable to insecure deserialization, triggered by lots of different
consumers invoking `unserialize()`.

Class deserialization is denied by using option
`['allowed_classes' => false]`.

Resolves: #90313
Releases: master, 9.5
Change-Id: Ic969441bcd4e85fcdbbde23f539bfbcb629ffbb4
Security-Bulletin: TYPO3-CORE-SA-2020-005
Security-References: CVE-2020-11067
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64469
Tested-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
2 weeks ago[SECURITY] Prevent destructors with side-effects from being unserialized 68/64468/2
Oliver Hader [Tue, 12 May 2020 09:22:04 +0000 (11:22 +0200)]
[SECURITY] Prevent destructors with side-effects from being unserialized

Deserialization of objects could lead to arbitrary removal of resources
as well as sending out message via mail.

Resolves: #88573
Resolves: #90316
Releases: master, 9.5
Change-Id: I3f77928203f4929bc715f548fb9bfdc0cd749e93
Security-Bulletin: TYPO3-CORE-SA-2020-004
Security-References: CVE-2020-11066
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64468
Tested-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
2 weeks ago[SECURITY] Ensure decoded entities are encoded for HTML again 67/64467/2
Oliver Hader [Tue, 12 May 2020 09:21:57 +0000 (11:21 +0200)]
[SECURITY] Ensure decoded entities are encoded for HTML again

HTML entities being used in link tags created with `typolink` have
to be encoded correctly again after entities have been decoded for
internal processing.

Resolves: #91161
Releases: master, 9.5
Change-Id: Ifc4d2da669aab01f2b3041bb32c0a24a727634b4
Security-Bulletin: TYPO3-CORE-SA-2020-003
Security-References: CVE-2020-11065
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64467
Tested-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
2 weeks ago[SECURITY] Prevent time based information disclosure 66/64466/2
Frank Naegler [Tue, 12 May 2020 09:21:38 +0000 (11:21 +0200)]
[SECURITY] Prevent time based information disclosure

To prevent a time based information disclosure in backend password reset,
this patch adds a random delay between 200 milliseconds and 3 seconds
before sending the response to the client.

Resolves: #91243
Releases: master
Change-Id: I0362db283145e0bed414ecdb06fff81b2cff0d4b
Security-Bulletin: TYPO3-CORE-SA-2020-001
Security-References: CVE-2020-11063
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64466
Tested-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
2 weeks ago[TASK] Integrate server response security checks 50/64450/9
Oliver Hader [Sun, 10 May 2020 18:56:30 +0000 (20:56 +0200)]
[TASK] Integrate server response security checks

In order to evaluate potential server misconfigurations and to reduce
the potential of security implications in general, a new HTTP response
check is integrated to "Environment Status" and the "Security" section
in the reports module.

It is evaluated whether non-standard file extensions lead to unexpected
handling on the server-side, such as `test.php.wrong` being evaluated
as PHP or `test.html.wrong` being served with `text/html` content type.

Resolves: #91354
Releases: master, 9.5
Change-Id: Ie6584692f39706aad2a25bad27bb201f4c1045e9
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64450
Tested-by: Benjamin Franzke <bfr@qbus.de>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
2 weeks ago[TASK] Incorporate changes of jQuery version 3.5.0 59/64459/2
Andreas Fernandez [Tue, 21 Apr 2020 06:44:23 +0000 (08:44 +0200)]
[TASK] Incorporate changes of jQuery version 3.5.0

This commit introduces live-patching of node_modules, which applies
patch files to specific modules (similar to composer-patches).

Patch files for fixing security issues are provided and applied after
installing the modules via `yarn install`.

http://blog.jquery.com/2020/05/04/jquery-3-5-1-released-fixing-a-regression/

The patches are based on
https://github.com/DanielRuf/snyk-js-jquery-565129.

Resolves: #91334
Releases: master, 9.5
Change-Id: I85555e9a21d6121e1a39c057b777a9250d56a781
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64459
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
2 weeks ago[BUGFIX] Revert PageReadPermission check for TreeController 31/64431/4
Benni Mack [Thu, 7 May 2020 12:35:37 +0000 (14:35 +0200)]
[BUGFIX] Revert PageReadPermission check for TreeController

In order to allow non-admins to fetch nodes which have no "pid=0"
the change to only fetch pages with access, the change to
check on a DB query basis is reverted.

Additionally a functional tests is extended to cover the problematic case.

Resolves: #91348
Related: #90880
Releases: master, 9.5
Change-Id: I3f737c92c8164c572f7e58335d92a82a4a5aa4dc
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64431
Tested-by: Tymoteusz Motylewski <t.motylewski@gmail.com>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Benni Mack <benni@typo3.org>
Reviewed-by: Tymoteusz Motylewski <t.motylewski@gmail.com>
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Benni Mack <benni@typo3.org>
2 weeks ago[BUGFIX] Fix internal + external links with URLs fragment 11/64411/10
Benni Mack [Mon, 11 May 2020 19:45:15 +0000 (21:45 +0200)]
[BUGFIX] Fix internal + external links with URLs fragment

Internal and external links have been incorrectly processed
by the legacy link notation converter which removed the
fragment from the URL before checking whether
the link is actually a legacy (file) link.

The change is now narrowed down to only append the fragment to
file links.

Resolves: #90916
Resolves: #91357
Related: #75213
Releases: master, 9.5
Change-Id: Ibdbfae4ac2ca0caa6710fb944810336e875e8929
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64411
Reviewed-by: Benjamin Franzke <bfr@qbus.de>
Reviewed-by: Benni Mack <benni@typo3.org>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Benni Mack <benni@typo3.org>
2 weeks ago[BUGFIX] Allow more characters for MySQL / MariaDB database name 12/64312/3
Manuel Selbach [Fri, 24 Apr 2020 12:21:11 +0000 (14:21 +0200)]
[BUGFIX] Allow more characters for MySQL / MariaDB database name

With this change it is possible to use a wider set of characters.
Please have a look at the official documentation of MySQL / MariaDB.

e.g.:

https://dev.mysql.com/doc/refman/5.5/en/identifiers.html
https://dev.mysql.com/doc/refman/5.6/en/identifiers.html
https://dev.mysql.com/doc/refman/5.7/en/identifiers.html
https://dev.mysql.com/doc/refman/8.0/en/identifiers.html
https://mariadb.com/kb/en/identifier-names/

The mentioned characters in chapter "Quoted" (ASCII and Extended) are
supported by now.

Furthermore the database name is quoted during the installation process
for creating / dropping a database.

If, for example a `.` is used in the name, a notification will be shown.

e.g.:

```
Unable to create database
Database with name "foo.test@bla123" could not be created. Either your database name contains a reserved keyword or your database user does not have sufficient permissions to create it or the database already exists. Please choose an existing (empty) database, choose another name or contact administration.
```

Resolves: #91167
Releases: master
Change-Id: I2df93f5c2238c2f0ca5ab8020ca8eebd10fdf58f
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64312
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Benni Mack <benni@typo3.org>
Tested-by: Manuel Selbach <manuel_selbach@yahoo.de>
Reviewed-by: Benni Mack <benni@typo3.org>
Reviewed-by: Andreas Fernandez <a.fernandez@scripting-base.de>
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Manuel Selbach <manuel_selbach@yahoo.de>
2 weeks ago[DOCS] ext:dashboard presets feature 35/64435/5
Daniel Siepmann [Thu, 7 May 2020 16:03:08 +0000 (18:03 +0200)]
[DOCS] ext:dashboard presets feature

The system extension ext:dashboard provides a way to register presets of
dashboards.
These presets can be configured via User TSconfig, if the user doesn't
have a dashboard yet.

Resolves: #91341
Releases: master
Change-Id: I174d6ee4a931bbe32f0cbed87db1545ee2785946
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64435
Tested-by: Richard Haeser <richard@maxserv.com>
Tested-by: Koen Wouters <koen.wouters@maxserv.com>
Tested-by: Daniel Siepmann <coding@daniel-siepmann.de>
Reviewed-by: Richard Haeser <richard@maxserv.com>
Reviewed-by: Koen Wouters <koen.wouters@maxserv.com>
Reviewed-by: Daniel Siepmann <coding@daniel-siepmann.de>
2 weeks ago[BUGFIX] Enable Enhancer support for MountPoints 03/64403/3
Benni Mack [Mon, 4 May 2020 14:47:23 +0000 (16:47 +0200)]
[BUGFIX] Enable Enhancer support for MountPoints

When using e.g. PageTypeDecorator in conjunction with mountpoints
and other Enhancers, the MP parameter was not added to the
resulting PageArguments object.

In addition, when building up a RouteCollection internally, the
same page was used multiple times but was overridden with a
MountPoint argument, adding to the "last principle wins" concept.

The patch adapts the needed changes.

Resolves: #90731
Releases: master, 9.5
Change-Id: Ic8c70dd51dc37617ba97cace3b9bec63512ecad6
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64403
Tested-by: Jan Kornblum <jan.kornblum@gmx.de>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Oliver Hader <oliver.hader@typo3.org>
Tested-by: Benni Mack <benni@typo3.org>
Reviewed-by: Jan Kornblum <jan.kornblum@gmx.de>
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Benni Mack <benni@typo3.org>
2 weeks ago[BUGFIX] Only call getMovePlaceholder for MOVE_POINTER records 53/64453/3
Benni Mack [Mon, 11 May 2020 12:49:54 +0000 (14:49 +0200)]
[BUGFIX] Only call getMovePlaceholder for MOVE_POINTER records

Since isInWebMount now calls BEgetRootline with workspace overlays,
an additional query for ALL requested pages in rootline is made, because
getMovePlaceholder() is called every time and does not know the
actual record - getMovePlaceholder should only be called on MOVE_POINTER
records.

An additional check makes the Page tree work again for editors in workspaces.

Resolves: #91360
Releases: master, 9.5
Change-Id: I1822a9824a0c9aacf4f3e1a900cbd19bd95ed9b9
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64453
Tested-by: Achim Fritz <af@achimfritz.de>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Benni Mack <benni@typo3.org>
Reviewed-by: Achim Fritz <af@achimfritz.de>
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Benni Mack <benni@typo3.org>
2 weeks ago[BUGFIX] Consistently fetch SiteConfiguration from DI 86/64386/4
Helmut Hummel [Fri, 1 May 2020 17:42:26 +0000 (19:42 +0200)]
[BUGFIX] Consistently fetch SiteConfiguration from DI

SiteConfiguration is available from the DI container (both in failsafe and
symfony DI), therefore no constructor arguments MUST be passed to
GeneralUtility::makeInstance when fetching the SiteConfiguration singleton
instance, or a new instance will be created.

There are however multiple places where this object is still created
by passing constructor arguments to GeneralUtility::makeInstance
(this bypasses proxying to the container).
This leads to the situation that two different objects are created and
retrieved, depending on how it is fetched.

This is now fixed by changing each remaining retrieval via makeInstance
to NOT provide constructor arguments, which in turn results in a call to
the container to fetch the SiteConfiguration object.

Additionally the ServiceProvider introduced in #89892 is changed to allow
providing an alternative implementation using XCLASS. Although XCLASSES
are generally discouraged in favor of Services.yaml overwrites, there is
no other way to provide an alternative for this class, as it is registered
in an internal service provider.

Resolves: #91260
Releases: master
Change-Id: I8af1cafd737feccff9e06eacb23d6991105238d0
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64386
Tested-by: Benjamin Franzke <bfr@qbus.de>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Helmut Hummel <typo3@helhum.io>
Reviewed-by: Benjamin Franzke <bfr@qbus.de>
Reviewed-by: Daniel Goerz <daniel.goerz@posteo.de>
Reviewed-by: Helmut Hummel <typo3@helhum.io>
2 weeks ago[BUGFIX] Correctly evaluate "unique" eval for slug fields 28/64428/10
David König [Thu, 7 May 2020 00:04:41 +0000 (02:04 +0200)]
[BUGFIX] Correctly evaluate "unique" eval for slug fields

TYPO3 v9.5.16, fixed functionality for URL resolving
for records with slug fields defined as "uniqueInSite".
With such setting, it is important to limit URL resolving
to the site the slugs are generated for. Because we currently
don't support records to be stored within one site, but
generating slugs for another one, this change enforced the storage
of news records to be in the same site as the detail page.

This however led to not working installations, where a record storage
folder is available in a site where other sites are fetching this
information from, which is a quite common use case.

To cover such use case, TCA needs to be adapted to the existing configuration
eval=unique, which diables the site check in URL frontend resolving.
However the current implementation of DataHandler only checks uniqueness
of fields of type "input".

This means for slug fields, the functionality of 'unique'
is currently not taken into account when generating the slug,
which can lead to duplicate slugs.
To fix this problem, a check for the unique eval setting is added to
DataHandler and FormSlugAjaxController. SlugHelper is adapted
to correctly generate slugs for this use case.

Resolves: #91235
Releases: master, 9.5
Change-Id: Id6e5c1d27860b09604787132f2cd83976418baa4
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64428
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Benni Mack <benni@typo3.org>
Tested-by: Helmut Hummel <typo3@helhum.io>
Reviewed-by: Benni Mack <benni@typo3.org>
Reviewed-by: Henrik Ziegenhain <henrik@ziegenhain.me>
Reviewed-by: Helmut Hummel <typo3@helhum.io>
2 weeks ago[BUGFIX] Disable new content buttons until module is loaded 07/64307/3
Andreas Fernandez [Thu, 23 Apr 2020 05:44:35 +0000 (07:44 +0200)]
[BUGFIX] Disable new content buttons until module is loaded

Each link triggering the "New content element" wizard is now initially
disabled and gets enabled once the according module has been loaded and
initialized.

Resolves: #91165
Releases: master
Change-Id: Ic4073faa5bd97f9b50bb8c3ada6864539c0ae63f
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64307
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Josef Glatz <josefglatz@gmail.com>
Tested-by: Chris Müller <typo3@krue.ml>
Tested-by: Daniel Goerz <daniel.goerz@posteo.de>
Reviewed-by: Josef Glatz <josefglatz@gmail.com>
Reviewed-by: Chris Müller <typo3@krue.ml>
Reviewed-by: Daniel Goerz <daniel.goerz@posteo.de>
2 weeks ago[BUGFIX] Fix HMENU special=directory when site language is in free mode 36/64436/3
Benni Mack [Thu, 7 May 2020 20:07:42 +0000 (22:07 +0200)]
[BUGFIX] Fix HMENU special=directory when site language is in free mode

When setting a site language into free mode for translations, then
"$cObj->exec_getQuery()" only returns the pages without overlays.
HMENU however always expects sys_language_uid=0 records, as it does a
MountPoint + overlay again. Doing an getPageOverlay of a translated page
results in an empty result.

The change now modifies the HMENU directory resolving
to fetch the original record (cached in PageRepository), and do
the overlay information as well.

This also fixes the same issue in HMENU.special = updated

Big Kudos to Jones for great support on tackling this issue!

Resolves: #91292
Releases: master, 9.5
Change-Id: Ifc0faddb6562c2b83dc95aa84ed40f37b5a1a0e9
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64436
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Jonas Temmen <jonas.temmen@artundweise.de>
Tested-by: Benni Mack <benni@typo3.org>
Reviewed-by: Wouter Wolters <typo3@wouterwolters.nl>
Reviewed-by: Jonas Temmen <jonas.temmen@artundweise.de>
Reviewed-by: Benni Mack <benni@typo3.org>
2 weeks ago[BUGFIX] Do not deprecate $GLOBALS[TYPO3_REQUEST] 39/64439/2
Benni Mack [Fri, 8 May 2020 17:00:31 +0000 (19:00 +0200)]
[BUGFIX] Do not deprecate $GLOBALS[TYPO3_REQUEST]

The global object $GLOBALS[TYPO3_REQUEST] holding the
current PSR-7 request object was introduced in TYPO3 v9.2.

However, it was also marked as deprecated as we thought we
were able to remove all usages again by the end of TYPO3 v9.5
development, which shows that we have more problems in various
areas like hooks and Extbase where we heavily rely on this object.

For this reason, it is kept but the original Feature RST still contains
the information that it is considered bad practice.

Removing the deprecation will result in better result for the
ExtensionScanner.

Resolves: #91347
Releases: master, 9.5
Change-Id: I97bb16cf7f4e7149c5c3a3528a015701f60c2628
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64439
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Benni Mack <benni@typo3.org>
Reviewed-by: Benni Mack <benni@typo3.org>
2 weeks ago[BUGFIX] Fix typo in frontend usergrops CSH details text 52/64452/2
Marcin Sągol [Sun, 10 May 2020 22:14:19 +0000 (00:14 +0200)]
[BUGFIX] Fix typo in frontend usergrops CSH details text

This commit fixes small typo in CSH text for frontend usergroups where instead of
"of" word "or" was used, changing sens of this statement.

Resolves: #91356
Releases: master, 9.5
Change-Id: Ic4f9e7544875f5d7a8d1f89e732955769041653e
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64452
Tested-by: Riccardo De Contardi <erredeco@gmail.com>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Josef Glatz <josefglatz@gmail.com>
Tested-by: Andreas Fernandez <a.fernandez@scripting-base.de>
Reviewed-by: Riccardo De Contardi <erredeco@gmail.com>
Reviewed-by: Josef Glatz <josefglatz@gmail.com>
Reviewed-by: Andreas Fernandez <a.fernandez@scripting-base.de>
2 weeks ago[BUGFIX] Include composer dumpautoload in Test Plan Jobs 40/64440/2
Anja Leichsenring [Fri, 8 May 2020 19:22:51 +0000 (21:22 +0200)]
[BUGFIX] Include composer dumpautoload in Test Plan Jobs

Resolves: #91349
Releases: master
Change-Id: I60ffcb35a82d7e890590f836dcfd9e0739c8db03
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64440
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Georg Ringer <georg.ringer@gmail.com>
Tested-by: Anja Leichsenring <aleichsenring@ab-softlab.de>
Reviewed-by: Georg Ringer <georg.ringer@gmail.com>
Reviewed-by: Anja Leichsenring <aleichsenring@ab-softlab.de>
2 weeks ago[TASK] Use getElementById where feasible 84/64384/3
Andreas Fernandez [Fri, 1 May 2020 11:36:34 +0000 (13:36 +0200)]
[TASK] Use getElementById where feasible

It's safe to use getElementById() instead of querySelector() in case an
element is fetched by its ID.

Numbers for nerds:
getElementById() is nearly 1.5x faster than querySelector(). To be fair,
both functions are really fast with executing multiple million operations
per second, thus nobody will notice a performance impact.
See https://www.measurethat.net/Benchmarks/ShowResult/106740

Resolves: #91254
Related: #91183
Releases: master
Change-Id: I2ed590d20c9af66ce818f012ac73ec45c5c9fa55
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64384
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Benjamin Franzke <bfr@qbus.de>
Tested-by: Daniel Goerz <daniel.goerz@posteo.de>
Reviewed-by: Benjamin Franzke <bfr@qbus.de>
Reviewed-by: Daniel Goerz <daniel.goerz@posteo.de>
2 weeks ago[TASK] Improve backend module Form description 42/64442/2
Marcin Sągol [Sat, 9 May 2020 10:47:54 +0000 (12:47 +0200)]
[TASK] Improve backend module Form description

This commit improves description text for backend module Form by replacing
reference to "Mail Form" content element with just "Form" as this name is
used in TYPO3.

Resolves: #91352
Releases: master, 9.5
Change-Id: I3348d2766afad6a2c06ce7b323df775a9bf9c33b
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64442
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Björn Jacob <bjoern.jacob@tritum.de>
Tested-by: Josef Glatz <josefglatz@gmail.com>
Tested-by: Daniel Goerz <daniel.goerz@posteo.de>
Reviewed-by: Björn Jacob <bjoern.jacob@tritum.de>
Reviewed-by: Josef Glatz <josefglatz@gmail.com>
Reviewed-by: Daniel Goerz <daniel.goerz@posteo.de>
2 weeks ago[BUGFIX] Remove obsolete period in scheduler label 37/64437/2
Daniel Goerz [Fri, 8 May 2020 08:15:32 +0000 (10:15 +0200)]
[BUGFIX] Remove obsolete period in scheduler label

Resolves: #91343
Releases: master, 9.5
Change-Id: I1d5c48c5ba7a8d6ff977b7e0ca5d3f96d7e1963d
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64437
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Tymoteusz Motylewski <t.motylewski@gmail.com>
Tested-by: Georg Ringer <georg.ringer@gmail.com>
Reviewed-by: Guido Schmechel <guido.schmechel@brandung.de>
Reviewed-by: Oliver Klee <typo3-coding@oliverklee.de>
Reviewed-by: Tymoteusz Motylewski <t.motylewski@gmail.com>
Reviewed-by: Georg Ringer <georg.ringer@gmail.com>
2 weeks ago[TASK] Clarify replacement for TSFE->storeSessionData() 72/64372/4
Mathias Brodala [Thu, 30 Apr 2020 16:13:01 +0000 (16:13 +0000)]
[TASK] Clarify replacement for TSFE->storeSessionData()

Releases: master
Related: #85878
Resolves: #91248
Change-Id: I8eb19a7e7f2ac4527beb9befafc6b16cf79e99cd
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64372
Tested-by: Björn Jacob <bjoern.jacob@tritum.de>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Alexander Schnitzler <git@alexanderschnitzler.de>
Tested-by: Benjamin Franzke <bfr@qbus.de>
Reviewed-by: Björn Jacob <bjoern.jacob@tritum.de>
Reviewed-by: Alexander Schnitzler <git@alexanderschnitzler.de>
Reviewed-by: Benjamin Franzke <bfr@qbus.de>
2 weeks ago[BUGFIX] Add recipient to FluidEmail Test cases to avoid errors 38/64438/4
Anja Leichsenring [Fri, 8 May 2020 17:25:50 +0000 (19:25 +0200)]
[BUGFIX] Add recipient to FluidEmail Test cases to avoid errors

The to header is mandatory by now, so we need to supply the recipient
in our testcases now.

Resolves: #91346
Releases: master
Change-Id: Ic1a3197a8412b27eb5cebb00a1443f10021b9326
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64438
Reviewed-by: Markus Klein <markus.klein@typo3.org>
Reviewed-by: Andreas Fernandez <a.fernandez@scripting-base.de>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Andreas Fernandez <a.fernandez@scripting-base.de>
2 weeks ago[BUGFIX] Use correct constant for email templateName in felogin 32/64432/3
Sebastian Iffland [Thu, 7 May 2020 13:42:43 +0000 (13:42 +0000)]
[BUGFIX] Use correct constant for email templateName in felogin

Releases: master
Resolves: #91337
Relates: #90729
Change-Id: I564f488dd653448046599a9bb1099dd05c4211f7
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64432
Reviewed-by: Daniel Goerz <daniel.goerz@posteo.de>
Reviewed-by: Wouter Wolters <typo3@wouterwolters.nl>
Reviewed-by: Alexander Grein <alexander.grein@gmail.com>
Reviewed-by: Josef Glatz <josefglatz@gmail.com>
Reviewed-by: Guido Schmechel <guido.schmechel@brandung.de>
Reviewed-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by: Benjamin Franzke <bfr@qbus.de>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Alexander Grein <alexander.grein@gmail.com>
Tested-by: Benjamin Franzke <bfr@qbus.de>
2 weeks ago[BUGFIX] Fix detection of plugin name by action 88/64388/2
Alexander Schnitzler [Sat, 2 May 2020 11:16:17 +0000 (13:16 +0200)]
[BUGFIX] Fix detection of plugin name by action

While switching from controller class aliases to fully
qualified controller class names (internally), the structure
of framework configuration slightly changed.

This unfortunately broke the detection of the plugin name
by action because the new structure had not been checked for.

Also, there was a unit test which hasn't been adjusted to the
new structure as well because it was simply overlooked.

With this patch the bug is fixed and the fix is also covered
again by a unit test.

Releases: master
Resolves: #91249
Change-Id: I9acdaeb66010563d82c818ddf0a73e2adab780db
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64388
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Susanne Moog <look@susi.dev>
Tested-by: Daniel Goerz <daniel.goerz@posteo.de>
Reviewed-by: Helmut Hummel <typo3@helhum.io>
Reviewed-by: Susanne Moog <look@susi.dev>
Reviewed-by: Daniel Goerz <daniel.goerz@posteo.de>
2 weeks ago[BUGFIX] Correctly consider nested tags in frontend HTML parser 09/64409/3
Joschi Kuphal [Tue, 5 May 2020 13:28:03 +0000 (15:28 +0200)]
[BUGFIX] Correctly consider nested tags in frontend HTML parser

Nested tags starting with the same literals, like `<s><span>...`
or `<a ...><abbr>...` are not correctly nested due to a flaw in
identifying proper start and end of HTML tags.

Resolves: #91194
Releases: master
Change-Id: I2029c8e01d66e5286790fd04a259153cd130c753
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64409
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Oliver Hader <oliver.hader@typo3.org>
Tested-by: Markus Klein <markus.klein@typo3.org>
Tested-by: Susanne Moog <look@susi.dev>
Reviewed-by: Markus Klein <markus.klein@typo3.org>
Reviewed-by: Helmut Hummel <typo3@helhum.io>
Reviewed-by: Daniel Goerz <daniel.goerz@posteo.de>
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Susanne Moog <look@susi.dev>
2 weeks ago[TASK] Improve file rename duplicate warning message 27/64427/4
Marcin Sągol [Wed, 6 May 2020 17:42:45 +0000 (19:42 +0200)]
[TASK] Improve file rename duplicate warning message

Improve the warning message presented to the user when a file is renamed
through the Filelist module and a file with the new name already exists.

Resolves: #91299
Releases: master
Change-Id: If1ff921396f782c1f560fdb092755e306344d0f3
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64427
Reviewed-by: Markus Klein <markus.klein@typo3.org>
Reviewed-by: Wouter Wolters <typo3@wouterwolters.nl>
Reviewed-by: Daniel Goerz <daniel.goerz@posteo.de>
Reviewed-by: Benjamin Franzke <bfr@qbus.de>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Daniel Goerz <daniel.goerz@posteo.de>
Tested-by: Benjamin Franzke <bfr@qbus.de>
2 weeks ago[BUGFIX] Use correct slug for access restricted translated pages 63/63963/5
Benni Mack [Sat, 2 May 2020 19:13:26 +0000 (21:13 +0200)]
[BUGFIX] Use correct slug for access restricted translated pages

Access restricted, translated pages currently always have the slug from the
default language instead of their translated slug in the frontend.
To generate correct urls, while using the "linkAccessRestrictedPages"
option, the $disableGroupAccessCheck parameter needs to also take into
account for
 * PageRepository::getPageOverlay()
when setting the option in PageRepository::getPage().

This "hack" is currently similar to what HMENU is doing, however
this public property should not be used with the Context API instead.

This change however needs more refactoring on the Context API,
which is why this solution is chosen for the time being (and also
for v9 backport).

Resolves: #90842
Resolves: #87969
Resolves: #91185
Releases: master, 9.5
Change-Id: I99a34ca7fceacba7218c6b7132781805a6b59ac9
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/63963
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Jonas Eberle <flightvision@googlemail.com>
Tested-by: Benni Mack <benni@typo3.org>
Reviewed-by: Jonas Eberle <flightvision@googlemail.com>
Reviewed-by: Helmut Hummel <typo3@helhum.io>
Reviewed-by: Benni Mack <benni@typo3.org>
2 weeks ago[BUGFIX] Respect disabled flag in render method of LinkButton 93/64393/4
Frank Naegler [Sun, 3 May 2020 10:43:50 +0000 (12:43 +0200)]
[BUGFIX] Respect disabled flag in render method of LinkButton

Resolves: #91244
Releases: master
Change-Id: I107cb96ff416211028f9da524500f1ca15c3297c
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64393
Tested-by: Daniel Goerz <daniel.goerz@posteo.de>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Josef Glatz <josefglatz@gmail.com>
Tested-by: Georg Ringer <georg.ringer@gmail.com>
Reviewed-by: Daniel Goerz <daniel.goerz@posteo.de>
Reviewed-by: Josef Glatz <josefglatz@gmail.com>
Reviewed-by: Georg Ringer <georg.ringer@gmail.com>
2 weeks ago[BUGFIX] Show correct language title for inconsistent content 16/64416/2
Georg Ringer [Tue, 5 May 2020 20:18:18 +0000 (22:18 +0200)]
[BUGFIX] Show correct language title for inconsistent content

Show the correct language title in the new fluid page module if an
inconsistent content state has been detected. The title of the
problematic language must be shown instead of the default language
title.

Furthermore a not needed sprintf call is removed as the message itself
doesn't contain any placeholder which needs to be replaced.

Resolves: #91313
Releases: master
Change-Id: Ie1082bee58cb04068e2cea3b4f18c2b6f2b516f1
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64416
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Benni Mack <benni@typo3.org>
Tested-by: Daniel Goerz <daniel.goerz@posteo.de>
Reviewed-by: Benni Mack <benni@typo3.org>
Reviewed-by: Josef Glatz <josefglatz@gmail.com>
Reviewed-by: Daniel Goerz <daniel.goerz@posteo.de>
2 weeks ago[BUGFIX] Change 3rd argument of calls to callUserFunction() 15/64415/4
Georg Ringer [Tue, 5 May 2020 19:59:43 +0000 (21:59 +0200)]
[BUGFIX] Change 3rd argument of calls to callUserFunction()

The third argument of `GeneralUtility::callUserFunction` must be either
an object or null.
Ensure the argument is always null instead of false to avoid
triggering a deprecation log entry.

Resolves: #91184
Releases: master
Change-Id: I5ee0a58d812de737bd631e5c1986895e69c158af
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64415
Tested-by: Josef Glatz <josefglatz@gmail.com>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Markus Klein <markus.klein@typo3.org>
Tested-by: Benni Mack <benni@typo3.org>
Reviewed-by: Josef Glatz <josefglatz@gmail.com>
Reviewed-by: Andreas Fernandez <a.fernandez@scripting-base.de>
Reviewed-by: Markus Klein <markus.klein@typo3.org>
Reviewed-by: Benni Mack <benni@typo3.org>
2 weeks ago[TASK] Avoid superfluous reference operator on objects 21/64421/2
Oliver Hader [Wed, 6 May 2020 08:40:51 +0000 (10:40 +0200)]
[TASK] Avoid superfluous reference operator on objects

Legacy left-overs using references on class instances can be removed.

Resolves: #91319
Releases: master, 9.5
Change-Id: Iad33e9e155f538fd1787d16c21e1b7d8e15bdd26
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64421
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
2 weeks ago[BUGFIX] Lift restriction for restricted records in Routing Aspects 08/64408/3
Benni Mack [Tue, 5 May 2020 13:28:09 +0000 (15:28 +0200)]
[BUGFIX] Lift restriction for restricted records in Routing Aspects

Since TYPO3 v9.5.16 it is not possible anymore to resolve URLs with an
Aspect that contains records with fe_group restrictions. This is due to
a legacy solution that the Frontend User is actually initialized early enough
but the groups are resolved within $TSFE->determineId() at a later point.

For this reason, Routing does not handle fe_group restrictions, but the
plugin should take care of that for the time being.

Future TYPO3 versions can decide to resolve the fe_group restrictions earlier,
but this would be a breaking change of behaviour of the Frontend
Request Workflow for TYPO3 v10 + v9.

Resolves: #91049
Releases: master, 9.5
Change-Id: I0e57768f5358dc06101acdca374b9c872a65c865
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64408
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Krystian Szymukowicz <k.szymukowicz@gmail.com>
Tested-by: Oliver Hader <oliver.hader@typo3.org>
Tested-by: Benni Mack <benni@typo3.org>
Reviewed-by: Markus Klein <markus.klein@typo3.org>
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Benni Mack <benni@typo3.org>
3 weeks ago[BUGFIX] Fix typo in identifier exists validation message in site configuration 17/64417/2
Marcin Sągol [Tue, 5 May 2020 21:03:57 +0000 (23:03 +0200)]
[BUGFIX] Fix typo in identifier exists validation message in site configuration

This commit fixes small typo at the end of the identifier exists validation message
used in site configuration controller.

Resolves: #91314
Releases: master, 9.5
Change-Id: Iccda594038a30a277d1c45255f6de564aa3dda5f
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64417
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Georg Ringer <georg.ringer@gmail.com>
Tested-by: Oliver Bartsch <bo@cedev.de>
Tested-by: Josef Glatz <josefglatz@gmail.com>
Tested-by: Andreas Fernandez <a.fernandez@scripting-base.de>
Reviewed-by: Georg Ringer <georg.ringer@gmail.com>
Reviewed-by: Joerg Kummer <typo3@enobe.de>
Reviewed-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by: Josef Glatz <josefglatz@gmail.com>
Reviewed-by: Andreas Fernandez <a.fernandez@scripting-base.de>
3 weeks ago[BUGFIX] Add 10.4.x changelogs to index as well 10/64410/2
Andreas Fernandez [Tue, 5 May 2020 14:28:22 +0000 (16:28 +0200)]
[BUGFIX] Add 10.4.x changelogs to index as well

Resolves: #91308
Releases: master
Change-Id: I1dc74ba54e11f35e0d4b99ebcc68e1ee77ea8598
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64410
Reviewed-by: Benjamin Franzke <bfr@qbus.de>
Reviewed-by: Helmut Hummel <typo3@helhum.io>
Reviewed-by: Daniel Siepmann <coding@daniel-siepmann.de>
Tested-by: Helmut Hummel <typo3@helhum.io>
Tested-by: Daniel Siepmann <coding@daniel-siepmann.de>
3 weeks ago[TASK] Add rel="noreferrer" to external links of widgets 01/64401/5
Chris Müller [Mon, 4 May 2020 11:14:26 +0000 (13:14 +0200)]
[TASK] Add rel="noreferrer" to external links of widgets

Clicking on external links (with target="_blank") in RSS widgets and buttons
of Dashboard widgets can leak the referrer of the linked page. This is mostly
not wanted because it reveals the URL of the TYPO3 backend. Additionally, the
other page can access the "window.opener" property, which exposes security
issues. Also if the other page is running a lot of JavaScript, the performance
of the TYPO3 backend may also suffer, because the other page may run on the
same process as the TYPO3 backend.

To mitigate this behaviour rel="noreferrer" is added to external links
in the according widgets.

"noreferrer" also implies the "noopener" behaviour, so this is sufficient.

See also:
- https://html.spec.whatwg.org/multipage/links.html#link-type-noreferrer
- https://developers.google.com/web/tools/lighthouse/audits/noopener

Resolves: #91290
Releases: master
Change-Id: Ie53b543e39bc716a5437d9a7364691de3ec7346f
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64401
Reviewed-by: Josef Glatz <josefglatz@gmail.com>
Reviewed-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by: Richard Haeser <richard@maxserv.com>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Josef Glatz <josefglatz@gmail.com>
Tested-by: Oliver Bartsch <bo@cedev.de>
Tested-by: Richard Haeser <richard@maxserv.com>
3 weeks ago[BUGFIX] Fix URLs to RSS feeds in Dashboard Widgets 05/64405/4
Richard Haeser [Mon, 4 May 2020 15:39:58 +0000 (17:39 +0200)]
[BUGFIX] Fix URLs to RSS feeds in Dashboard Widgets

As the www prefix is not used anymore on typo3.org, the
URLs of the RSS feeds are updated in the Dashboard Widgets.

Resolves: #91297
Releases: master
Change-Id: I4ffff83035967b0ba9b7233c82df01651599f103
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64405
Tested-by: Josef Glatz <josefglatz@gmail.com>
Tested-by: Oliver Bartsch <bo@cedev.de>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Richard Haeser <richard@maxserv.com>
Reviewed-by: Josef Glatz <josefglatz@gmail.com>
Reviewed-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by: Richard Haeser <richard@maxserv.com>
3 weeks ago[BUGFIX] Make rendering of priority option optional in XML sitemaps 97/64397/2
Georg Ringer [Mon, 4 May 2020 07:57:43 +0000 (09:57 +0200)]
[BUGFIX] Make rendering of priority option optional in XML sitemaps

According to https://www.sitemaps.org/de/protocol.html the option
`priority` is optional. If a SitemapProvider doesn't provide a priority
information the tag must be avoided to have a valid XML structure.

Resolves: #91286
Releases: master, 9.5
Change-Id: I0bd4379633359321ad39726e4357773880c15638
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64397
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Christian Eßl <indy.essl@gmail.com>
Tested-by: Josef Glatz <josefglatz@gmail.com>
Tested-by: Oliver Bartsch <bo@cedev.de>
Tested-by: Richard Haeser <richard@maxserv.com>
Reviewed-by: Christian Eßl <indy.essl@gmail.com>
Reviewed-by: Andreas Fernandez <a.fernandez@scripting-base.de>
Reviewed-by: Josef Glatz <josefglatz@gmail.com>
Reviewed-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by: Richard Haeser <richard@maxserv.com>
3 weeks ago[BUGFIX] Reset `window.opener` in backend and load modules if authenticated 94/64394/4
Andreas Fernandez [Sun, 3 May 2020 12:21:37 +0000 (14:21 +0200)]
[BUGFIX] Reset `window.opener` in backend and load modules if authenticated

This patch resets the `window.opener` for the entire TYPO3 backend and
loads modules using this only in an authenticated environment. This
solves an issue when `window.opener` is accessed and the login or
backend were opened from a link, e.g. the password reset mail.

Resolves: #91270
Resolves: #91205
Releases: master, 9.5
Change-Id: I83bdbfa7dfb80fbcd92ac4a000a6479aad22a73a
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64394
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Oliver Hader <oliver.hader@typo3.org>
Tested-by: Josef Glatz <josefglatz@gmail.com>
Tested-by: Andreas Fernandez <a.fernandez@scripting-base.de>
Reviewed-by: Susanne Moog <look@susi.dev>
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Josef Glatz <josefglatz@gmail.com>
Reviewed-by: Andreas Fernandez <a.fernandez@scripting-base.de>
3 weeks ago[BUGFIX] Harden deprecation log handling 77/56077/11
Helmut Hummel [Thu, 1 Mar 2018 14:45:16 +0000 (15:45 +0100)]
[BUGFIX] Harden deprecation log handling

Because TYPO3's DefaultConfiguration is recursively
merged with settings from LocalConfiguration, it was
impossible to change or remove log writers that are
defined in DefaultConfiguration. One would have had
to use AdditionalConfiguration for that.

A simpler way to disable individual log writers is added now.
It is simpler, because it allows to disable log writers
directly in LocalConfiguration.

To avoid misconfiguration regarding deprecation logging,
E_USER_DEPRECATED is now enforced in SYS/errorHandlerErrors.

E_USER_DEPRECATED needs to be enforced to avoid,
that the default PHP error handler is called, which would cause
these errors to be added to the output or filling up log files,
depending on the global PHP configuration (php.ini).

Because all other values from DefaultConfiguration.php resemble
production settings and logging deprecation messages in production
are not desired, the deprecation logger is now disabled by default.

Last but not least, deprecation logging is now enabled/disabled in
the Live and Debug presets in the install tool UI.

Resolves: #84105
Resolves: #89934
Resolves: #88444
Releases: master, 9.5
Change-Id: I52a6f9c70ad13e6e0bad6a6b06b6fbfe7abc623c
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/56077
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Markus Klein <markus.klein@typo3.org>
Tested-by: Benjamin Franzke <bfr@qbus.de>
Reviewed-by: Markus Klein <markus.klein@typo3.org>
Reviewed-by: Benjamin Franzke <bfr@qbus.de>
3 weeks ago[BUGFIX] Remove wrong-spelled/not existing class from Services.yaml 98/64398/2
Chris Müller [Mon, 4 May 2020 09:12:04 +0000 (11:12 +0200)]
[BUGFIX] Remove wrong-spelled/not existing class from Services.yaml

As the class TYPO3\CMS\Dashboard\DasboardRegistry is wrong-spelled and
does not exist, it is removed.

Resolves: #91287
Releases: master
Change-Id: I016aeb4839ed62ae7d23f011c9a87c104bb2b138
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64398
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Josef Glatz <josefglatz@gmail.com>
Tested-by: Georg Ringer <georg.ringer@gmail.com>
Reviewed-by: Richard Haeser <richard@maxserv.com>
Reviewed-by: Josef Glatz <josefglatz@gmail.com>
Reviewed-by: Georg Ringer <georg.ringer@gmail.com>
3 weeks ago[BUGFIX] Improve label of cache clearing message 96/64396/2
Georg Ringer [Mon, 4 May 2020 07:35:55 +0000 (09:35 +0200)]
[BUGFIX] Improve label of cache clearing message

Improve the cache clearing label added with #88718.

Resolves: #91284
Releases: master
Change-Id: I8c1036af1428453a6f9cc7a801dbbf0f747011cc
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64396
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Benni Mack <benni@typo3.org>
Reviewed-by: Benni Mack <benni@typo3.org>
3 weeks ago[BUGFIX] Cache various where clauses of PageRepository 21/64321/13
Stefan Froemken [Mon, 27 Apr 2020 13:29:59 +0000 (15:29 +0200)]
[BUGFIX] Cache various where clauses of PageRepository

Since TYPO3 v9, PageRepository works independently
from TSFE and can and should be instantiated on its
own, depending on the context.

This leads to multiple initializiation calls which can
and should be cached, as a page with 100 links will
re-trigger the properties all the time, even if they
are not needed (groupWhereClause for instance).

Caching these values reduces the time needed for
typolink generation a lot.

Resolves: #91208
Releases: master, 9.5
Change-Id: Ied7e2b78519754af2e10eeb4e9c1c9fcbbffe2e8
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64321
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Benni Mack <benni@typo3.org>
Tested-by: Georg Ringer <georg.ringer@gmail.com>
Reviewed-by: Markus Klein <markus.klein@typo3.org>
Reviewed-by: Benni Mack <benni@typo3.org>
Reviewed-by: Georg Ringer <georg.ringer@gmail.com>
3 weeks ago[TASK] Respect disabled ElementBrowser also in TableList 76/64076/6
Oliver Bartsch [Sat, 4 Apr 2020 17:20:10 +0000 (19:20 +0200)]
[TASK] Respect disabled ElementBrowser also in TableList

The ElementBrowser which is typically used for type=group,
can be disabled via the `fieldControl`.

This configuration is now also respected by the TableList
buttons, which are also links for the ElementBrowser.

Resolves: #88979
Releases: master, 9.5
Change-Id: Ib48586207480e4e61403ad6b0b694b51ee6e38c2
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64076
Tested-by: Josef Glatz <josefglatz@gmail.com>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Oliver Bartsch <bo@cedev.de>
Tested-by: Benni Mack <benni@typo3.org>
Reviewed-by: Josef Glatz <josefglatz@gmail.com>
Reviewed-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by: Benni Mack <benni@typo3.org>
3 weeks ago[TASK] Enhance custom event dispatching in modal dialog 11/64311/2
Oliver Hader [Fri, 24 Apr 2020 11:39:17 +0000 (13:39 +0200)]
[TASK] Enhance custom event dispatching in modal dialog

* allows custom events to bubble up in DOM tree
* ensures that custom events are dispatched at those elements
  that initially contained the `data-event-name` attributes

Resolves: #91186
Releases: master
Change-Id: I0c5951a573bba0bbe73967ffcecf5dcfeae2e2f2
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64311
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Susanne Moog <look@susi.dev>
Tested-by: Andreas Fernandez <a.fernandez@scripting-base.de>
Reviewed-by: Benni Mack <benni@typo3.org>
Reviewed-by: Susanne Moog <look@susi.dev>
Reviewed-by: Andreas Fernandez <a.fernandez@scripting-base.de>
3 weeks ago[BUGFIX] Use class instead of HTML comment to determine loading state of IRRE element 85/64385/3
Andreas Fernandez [Fri, 1 May 2020 14:08:54 +0000 (16:08 +0200)]
[BUGFIX] Use class instead of HTML comment to determine loading state of IRRE element

IRRE relied on the HTML comment `<!--notloaded-->` to detect whether a
record is already loaded or not. As this might collide with HTML
minification, the comment has been replaced with a class placed in the
panel.

Resolves: #91258
Releases: master
Change-Id: Ibe890317bdcb9707a71de1168de0d404fb3c67a4
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64385
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Xavier Perseguers <xavier@typo3.org>
Tested-by: Susanne Moog <look@susi.dev>
Tested-by: Andreas Fernandez <a.fernandez@scripting-base.de>
Reviewed-by: Xavier Perseguers <xavier@typo3.org>
Reviewed-by: Susanne Moog <look@susi.dev>
Reviewed-by: Andreas Fernandez <a.fernandez@scripting-base.de>