- 22 Dec, 2020 1 commit
-
-
Benni Mack authored
Change-Id: Ia7d3aadc005e51418dbb320e48c3aa488be92747 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67235 Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Benni Mack <benni@typo3.org>
-
- 21 Dec, 2020 3 commits
-
-
Benni Mack authored
This reverts commit 844f024a due to some unexpected behaviour when cropping and scaling, see #93090 and related issues in https://forge.typo3.org/issues/91855 for details Change-Id: If3f38cfeeb860e1a13648d239f05d2754f2f9102 Resolves: #93139 Revertes: #91855 Releases: master, 10.4 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67203 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Benni Mack <benni@typo3.org>
-
The value from columns that are marked as "dbType" date(time) fields in TCA configuration are now explicitly interpreted using UTC timezone, when the string value has no timezone specifier given. JS supplied values contain Z as specifier, while records from the database (which are processed during copy operations) do not contain a timezone specifier. Local time was assumed by PHP in the latter case before, as we did not pass an explicit timezone information to the DateTime constructor. Therefore we now assure no timezone conversion will happen and no time/date-offset will be added, by using UTC explicitly. Resolves: #89914 Releases: master, 10.4, 9.5 Change-Id: I8e531ae5f3367c4493ce1e7db4bec0ef02311e24 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67200 Tested-by:
Benjamin Franzke <bfr@qbus.de> Tested-by:
TYPO3com <noreply@typo3.com> Reviewed-by:
Benjamin Franzke <bfr@qbus.de>
-
Since one of the recent security patches, frontend and backend user sessions are stored as HMAC-SHA256 if using redis storage backend, and HMAC-MD5 if using default database storage backend. Reason for using the less collision resistant md5 in database backend over sha256 has been, that the 64 characters of sha256 did not fit into the varchar(32) field of the ses_id fields. This would have led to trouble for users upgrading to the security patch level releases. We now increase the field size to varchar(255) with this patch, and backport this to v10. A second patch will then switch only v11/master to sha256. This way, users can increase db field size in v10 already to prepare for v11 and later upgrade to v11 without being logged out or experiencing db errors. Only users running current master will have to use the standalone install tool once to increase field size. Strictly, a field size of 64 characters would be enough for sha256, we however raise to 255 to never run into this chicken-egg issue again - just in case. Resolves: #93131 Releases: master, 10.4 Change-Id: Ifcafba0c3bae2f27ba0e13e6925007a6e1627d88 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67199 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Benni Mack <benni@typo3.org>
-
- 20 Dec, 2020 3 commits
-
-
Christian Kuhn authored
Change-Id: Ibb646663a899d183f7a55c829ab2acea70838a0c Resolves: #93128 Related: #93084 Releases: master, 10.4, 9.5 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67197 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch>
-
The alternative type stdClass is missing from the type annotation. Also make the return type of createPseudoUser more specific in order to help static analysis. Releases: master, 10.4 Resolves: #93118 Change-Id: I54a4665c9b15434b6a59c217dc61d636faf24dbc Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67196 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Benni Mack <benni@typo3.org>
-
Depending on SQL structure of an MM table, the recent fix for issue #93064 can lead to query errors: It works with core category relations but fails for instance with ext:news 'related news' relations. This is due to an assumption about existence of field 'tablenames', which is bogus. If needed, the according where restriction comes from TCA MM_match_fields already, which is sufficient. Resolves: #93109 Related: #93064 Releases: master, 10.4 Change-Id: Ifcc15989f87119cfb10c2da47c22b42a0dd4558a Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67195 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Benni Mack <benni@typo3.org>
-
- 19 Dec, 2020 2 commits
-
-
The t3editor panel label was removed by accident in https://review.typo3.org/c/Packages/TYPO3.CMS/+/66225 because it was passed via the invalid textarea alt attribute. Re-add this label via data-codemirror-config attribute. Releases: master, 10.4 Resolves: #93115 Related: #92633 Change-Id: Ib743fa28a0249de142ac1d112865b1f2c7bdc216 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67194 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch>
-
Resolves: #93113 Releases: master, 10.4 Change-Id: I472414164c2d0628a7b4d85cdb456c9f89024007 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67193 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch>
-
- 17 Dec, 2020 1 commit
-
-
Because the request was not set for the recovery email, the TYPO3 logo as well as the website URL in the footer were not displayed when using the SystemEmail layout from core. This is now fixed by setting the request, if available. Resolves: #93055 Releases: master, 10.4 Change-Id: I005df28b16bddc9a6105f72e361a07c0b7d15532 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67192 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch>
-
- 16 Dec, 2020 1 commit
-
-
Christian Kuhn authored
Travis CI for core has been flaky for a while - processes tend to die or are queued forever. The only thing travis still executed for us is updating sonar cloud data. This service has been introduced some years ago but did never find significant usage and has never been configured. The patch drops travis along with sonar-cloud. If anyone wants to pick up work with sonar again, it could be added as github action again. Change-Id: I2929bfb1f72d1a6af273692b4f632d90280bf074 Resolves: #93084 Releases: master, 10.4, 9.5 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67152 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Oliver Klee <typo3-coding@oliverklee.de> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch>
-
- 15 Dec, 2020 2 commits
-
-
Change-Id: Ib6ea31fd703a5e71006e71c40f6f53bc4dfff7f4 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67136 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Oliver Hader <oliver.hader@typo3.org> Reviewed-by:
Oliver Hader <oliver.hader@typo3.org>
-
Benni Mack authored
Change-Id: I29e4a48b62d0d700cf7cdab62b9d513fecbfd36b Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67135 Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Benni Mack <benni@typo3.org>
-
- 14 Dec, 2020 3 commits
-
-
Change the implementation of backend deferred image processing to use a file processor, which is only but always used in the backend. By doing so all limitations of the current implementation are resolved, which means, width and height of the image can be set in HTML, to avoid layout shifts and once the images are processed, they will simply be delivered by the web server. Inconsistencies with thumbnail ratio (depending on crop being defined or not) are also tackled on the go. While this changes processing configuration for some files, which triggers a re-generation, it should not matter, as image processing will be done in parallel on request, making such changes viable in a bugfix release. The introduced database field is neither used nor required for the current implementation, but is introduced to provide a possibility for third party processors to replace the current implementation with simple (and persisted) URLs to third party SaaS image processing services. Resolves: #92188 Releases: master, 10.4 Change-Id: I8d1e14324085c5b6ba646475206c8cb10a1fc10d Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66587 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Georg Ringer <georg.ringer@gmail.com> Reviewed-by:
Georg Ringer <georg.ringer@gmail.com>
-
Christian Kuhn authored
A 'true' MM relation (select / group with MM, but not inline with foreign_field - used in core for pages/tt_content table to sys_category via sys_category_record_mm) has two sorting fields: 'sorting' for the local (sys_category) side, and 'sorting_foreign' for the foreign (pages / tt_content) side. When categories are added to a tt_content element, 'sorting_foreign' is set to the given order of sys_category elements. 'sorting' is set to 0. When then opening a sys_category record that has multiple records pointing to it with 0 as sorting, the returned order of records is non-deterministic and depends on implicit DB engine fallbacks. This also confuses the reference index, which checks refindex integrity always from the 'local' side. The patch adds 'uid_foreign' as second order-by field to force deterministic ordering. There is still a possible collision in multi table relations (more than one foreign table uses the mm table like pages AND tt_content to sys_category with foreign records having the same uid) and if the mm table allows "multi" relations. Those scenarios however have no explicit TCA configuration (only implicit via MM_match_fields), need a deeper investigation and possibly further detail patches later. The patch should for now fix a functional test that is flaky with postgres. Change-Id: I3c89d0e67f8a4065354f9df173020ca0080e0d57 Resolves: #93075 Releases: master, 10.4 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67058 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch>
-
Christian Kuhn authored
Makes lit-html loadable in unit tests. composer require --dev typo3/testing-framework ^6.6.0 Change-Id: I4b5cbf0825d12708882e744b10ffa31b78332c25 Resolves: #93074 Releases: master, 10.4 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67114 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Benjamin Franzke <bfr@qbus.de> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Benjamin Franzke <bfr@qbus.de> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch>
-
- 13 Dec, 2020 2 commits
-
-
This patch adds EventDispatcher and Logger support to the various transports where it was missing so far. Now the Mailer API should be compatible to the underlaying Symfony Mailer and all features can be used. Resolves: #93000 Releases: master, 10.4 Change-Id: Iea222586a0f4d3e35e462c3cf27c16eec914b5c4 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67057 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Benjamin Franzke <bfr@qbus.de> Reviewed-by:
Benjamin Franzke <bfr@qbus.de>
-
Ensures client-side function `SecurityUtility.encodeHtml` behaves like `htmlspecialchars(..., ENT_QUOTES)`. The function is used for complete nodes only, but now could be used for parts as well. Resolves: #93068 Releases: master, 10.4, 9.5 Change-Id: I74b09676d0fdb8ddf09e7fc639480742fe645e9b Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67106 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Benni Mack <benni@typo3.org>
-
- 12 Dec, 2020 1 commit
-
-
A first patch towards more reliable workspace-mm scenarios: When a record is discarded that has mm relations, those relations are now deleted along with the deleted "parent" record. Change-Id: Ic2abe8d1c828158cf86abe760aec8766abcd0e71 Resolves: #93064 Releases: master, 10.4 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67101 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Benni Mack <benni@typo3.org> Tested-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Reviewed-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Andreas Fernandez <a.fernandez@scripting-base.de>
-
- 11 Dec, 2020 1 commit
-
-
Showing PDF documents in Safari browsers is blocked due to recent content-security-policy adjustments in `fileadmin/` directory. This change uses a less restrictive approach for PDF documents. Resolves: #93035 Releases: master, 10.4, 9.5 Change-Id: I58065e19c86c0054dc5f155e20d7f6a90baec20e Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67087 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Benni Mack <benni@typo3.org> Tested-by:
Oliver Hader <oliver.hader@typo3.org> Reviewed-by:
Wouter Wolters <typo3@wouterwolters.nl> Reviewed-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Oliver Hader <oliver.hader@typo3.org>
-
- 10 Dec, 2020 5 commits
-
-
Releases: 10.4 Change-Id: Iff0e4344e08973582bc60b1ca6442cfcfe98e201 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67090 Tested-by:
Oliver Hader <oliver.hader@typo3.org> Reviewed-by:
Oliver Hader <oliver.hader@typo3.org>
-
The BackendException class is exported as named (not as default) export in BackendException.ts, and therefore the module consumer needs to access the BackendException property of the module. Fix FormEngine to do so. Releases: master, 10.4 Resolves: #92249 Change-Id: Id416e7ee4753db033301c43482b786c38075e13a Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67056 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Oliver Hader <oliver.hader@typo3.org> Reviewed-by:
Oliver Hader <oliver.hader@typo3.org>
-
Resolves: #92977 Releases: master, 10.4 Change-Id: I222f2e7e1f3772d72e0da2b9b77f74cd86852086 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67003 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Oliver Bartsch <bo@cedev.de> Tested-by:
Oliver Hader <oliver.hader@typo3.org> Reviewed-by:
Oliver Bartsch <bo@cedev.de> Reviewed-by:
Oliver Hader <oliver.hader@typo3.org>
-
With #92682 the method `renderForeignRecordHeader` has been changed which is bad for extensions which xclasses this method. Put the new parameter into the data array to minimize the impact of the accessibility change. Related: #92682 Resolves: #93044 Releases: 10.4 Change-Id: I706bd62d539b9ba69c395e58c511f9f6cbe3e35f Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67079 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Oliver Bartsch <bo@cedev.de> Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Oliver Bartsch <bo@cedev.de> Reviewed-by:
Benni Mack <benni@typo3.org>
-
Page unavailable (e.g. maintenance mode) is a "503 service unavailable" error, not 500 internal server error. If TYPO3 is in maintenance mode then a 503 error is now thrown. Also 503 Error Handlers are taken into account now. Releases: master, 10.4 Resolves: #93032 Change-Id: I8bd013fc202b07263388fc22ec2256262c40b709 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67055 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Benjamin Franzke <bfr@qbus.de> Reviewed-by:
Benjamin Franzke <bfr@qbus.de>
-
- 08 Dec, 2020 3 commits
-
-
Anja Leichsenring authored
Remove usage of $mock->at() matcher and some other deprecated matchers. Following matchers are deprecated in phpunit v9: * at() * assertRegExp() * assertFileNotExists() Those were replaced with their respective replacements. Resolves: #92461 Releases: master, 10.4 Change-Id: Id8373659160c219c2caff8bcbe0bdb9b0da16436 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66941 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Reviewed-by:
Anja Leichsenring <aleichsenring@ab-softlab.de>
-
The template now evaluates the correct variable for checking whether the login message should be displayed on the overview page. Resolves: #92939 Releases: master, 10.4 Change-Id: I54dd4759b3154be5e57cc38df89a52e22c838f63 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67052 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Benni Mack <benni@typo3.org>
-
The composer min stage in nightly tests should respect the PHP version the run is executed with. So the platform.php setting will be the lowest possible PHP version of its own input, not the lowest possible TYPO3 currently supports. Resolves: #93020 Releases: master, 10.4 Change-Id: Id5cd4d4bce5f015ae35303cbcd0d0d561730204a Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66954 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Reviewed-by:
Andreas Fernandez <a.fernandez@scripting-base.de>
-
- 07 Dec, 2020 2 commits
-
-
If a versioned page is inaccessible due to versionOL, the row will be converted to a value of "false". This can be the case for deleted or hidden pages. In those cases, the tree should not include this page. Keeping the page would furthermore result in a type error, as later calls expect $row to be an array. Resolves: #93009 Releases: master, 10.4 Change-Id: I43033e6fe3b403ffc2eebb2cc7080b988425917e Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67016 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Benjamin Franzke <bfr@qbus.de> Reviewed-by:
Benjamin Franzke <bfr@qbus.de>
-
Translation wizard will hang if there are new content elements to translate and there is an element with language "All". This change fixes the problem by disallowing to fetch elements with this language. The fix is contributed by the University of Basel. Resolves: #92751 Releases: master, 10.4, 9.5 Change-Id: Ib018e04f6e95a1dc1a1d1f57631a31b986a10cd5 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67014 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Benni Mack <benni@typo3.org>
-
- 05 Dec, 2020 1 commit
-
-
With #92112, parsing of the pageUid option of the RedirectFinisher has been restricted to accept only strings as option value. Prior to this change, one could also define integer values. The previous behavior has now been restored by explicitly parsing the option value as string and then parsing it back to an integer. Resolves: #92800 Related: #92112 Releases: master, 10.4 Change-Id: I88992b309e09757ae24348c6066294effb209505 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67012 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Daniel Goerz <daniel.goerz@posteo.de> Reviewed-by:
Daniel Goerz <daniel.goerz@posteo.de>
-
- 04 Dec, 2020 3 commits
-
-
Node 14 is the latest LTS version for NodeJS, and yarn v1.22 was the latest version for a long time. Resolves: #92991 Releases: master, 10.4 Change-Id: I7256865717a839cda5ea20be4b67a6a3dca3ede2 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67013 Tested-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Tested-by:
TYPO3com <noreply@typo3.com> Reviewed-by:
Andreas Fernandez <a.fernandez@scripting-base.de>
-
The function is the same as the one in Recycler.ts and is taken from there. The pagination markup is the same, so it also works in the workspaces module. Resolves: #92978 Releases: master, 10.4 Change-Id: If2950c394741061c990f2a28218feada7d87d8fa Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66994 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Reviewed-by:
Benni Mack <benni@typo3.org>
-
Due to a type conflict (int vs bool), nested history records (e.g. for pages) have not been shown anymore. Resolves: #92970 Releases: master, 10.4 Change-Id: Iabe8efe447578586edfe2c32ca4c392a81482a00 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66992 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Andreas Fernandez <a.fernandez@scripting-base.de> 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>
-
- 02 Dec, 2020 1 commit
-
-
The icon of page translation rows in the web_info module "Localization overview" is now also wrapped into a context menu. This furthermore automatically adds the record title as title attribute to the icon, like it's already the case for the default records. Resolves: #92919 Releases: master, 10.4 Change-Id: I6f6ab213bd345d3a3db039c71c548cf7bcc0df56 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66965 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Georg Ringer <georg.ringer@gmail.com> Reviewed-by:
Georg Ringer <georg.ringer@gmail.com>
-
- 01 Dec, 2020 4 commits
-
-
Closing a sub menu in the mobile view of the topbar resulted in closing the whole overlay. This was already fixed in master with #91642, but not backported. Therefore, this patch now fixes this for 10.4, regardless of the actual master patch that has taken care of various issues. Resolves: #89635 Relates: #91642 Releases: 10.4 Change-Id: Ie5fb90bc2175fc4bc9f12e6f80cbe4d43ab7283d Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66325 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch>
-
Releases: master, 10.4, 9.5 Resolves: #92954 Change-Id: Ibbe19a88a603ac1390601c8e23eae566b44ebc92 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66922 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch>
-
Change the from address used in the test task of the scheduler by using the default address configured in `$GLOBALS['TYPO3_CONF_VARS']['MAIL']['defaultMailFromAddress']`. Resolves: #92961 Releases: master, 10.4 Change-Id: Ib4bf998c3180fa1bd2baa5591c340f04198aa026 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66921 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch>
-
Brings an acceptance test stabilization fix and a functional test API method to execute frontend requests as sub request with core v11 / master. composer require --dev typo3/testing-framework ^6.5.0 Resolves: #92965 Releases: master, 10.4 Change-Id: Ic8600d369f436569658e7cc593c428e6eb70db0a Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66961 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Oliver Bartsch <bo@cedev.de> Tested-by:
Georg Ringer <georg.ringer@gmail.com> Reviewed-by:
Oliver Bartsch <bo@cedev.de> Reviewed-by:
Georg Ringer <georg.ringer@gmail.com>
-
- 29 Nov, 2020 1 commit
-
-
Christian Kuhn authored
The cardinal issue with constant 'TYPO3_MODE' is that it's value is NOT constant: It is defined early during bootstrap and derived from information that is hand over from entry point index.php's. Depending on this, value is either 'FE' or 'BE'. Using that constant or the related constant 'TYPO3_REQUESTTYPE' makes it impossible to change scope from backend to frontend in one PHP call. This actively blocks executing sub requests, use cases are for instance executing a frontend request within a running backend call (eg. view module), or executing frontend requests from cli (eg. some indexer). Dropping 'TYPO3_MODE' and its friends is thus a requirement to finally allow such scenarios. We can't get rid of the distinction between 'frontend' and 'backend' altogether since some legit use cases like different paths or security settings depend on it. Looking at TYPO3 bootstrap, the only class that 'knows' if it's frontend or backend are the Application classes of ext:frontend and ext:backend. They are the PSR-15 entry points, they create a first PSR-7 request object if it has not been given, and then call the PSR-15 middleware stack dispatcher to create a PSR-7 response, starting with this first request object. The solution to get rid of 'TYPO3_MODE' is to add the information 'I am a frontend or backend request' as attribute to the request object in the Application classes. To simplify things, the helper class ApplicationType is introduced that answers isFrontend() and isBackend() for a given request object. Documentation changelog files with full details on the impact of this change will be added with an upcoming patch that deprecates the constants in master. This patch targets master and v10: 'TYPO3_MODE' is used in extensions quite often. Having the API in both v10 and v11 helps extension developers to deliver deprecation free extensions that are compatible with both v10 and v11 in one version. Codewise, neither the 'applicationType' attribute nor the helper class harm in v10. Resolves: #92951 Related: #92947 Releases: master, 10.4 Change-Id: Ia4ea637b252b774cf72492402e6be52ee4695242 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66920 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch>
-