- 04 Jan, 2021 2 commits
-
-
With Bootstrap 5, <select> fields make use of the class `form-select`. This patch aims to replace every occurrence of `form-control` used with select fields. Since Bootstrap finally brings proper styling for select boxes, the custom implementation rendering chevrons can be removed. In the same run, the `input-$size` classes are migrated to its new class names and some obsolete classes have been removed. Resolves: #93135 Releases: master Change-Id: I0044127cc380bddfbaec0b9f730123959f7288bd Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67247 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Martin Kutschker <mkutschker-typo3@yahoo.com> Tested-by:
Benjamin Franzke <bfr@qbus.de> Reviewed-by:
Martin Kutschker <mkutschker-typo3@yahoo.com> Reviewed-by:
Benjamin Franzke <bfr@qbus.de>
-
Running a clean installation minimal setup throws a lot of "PHP Notice: Undefined index: " notices. This commit removes the ones from the frontend. Resolves: #91116 Releases: master, 10.4 Change-Id: I1f81150ed48ae170682d68d1169c1de2963e0021 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64238 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>
-
- 22 Dec, 2020 1 commit
-
-
Adds the new parameter in ArrayObject::asort for PHP 8. As an additional parameter it's backwards-compatible with PHP 7.4. Resolves: #92141 Related: #92138 Releases: master Change-Id: I691bad5f19457b7456da1e624cf7289538317495 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67226 Tested-by:
Alexander Schnitzler <git@alexanderschnitzler.de> Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Alexander Schnitzler <git@alexanderschnitzler.de> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch>
-
- 21 Dec, 2020 1 commit
-
-
Bootstrap v5 – introduced in #92616 – was added with CCS from beta1 but JavaScript from alpha2. bootstrap.bundle.js was manually wrapped into a AMD closure, and because bootstrap 5.0.0-beta1 contains alot of changes regarding data tags, it couldn't be updated in the initial patch. Bootstrap is now bundled using rollup using the ES6 sources in order to allow for automatic updates through `grunt build`. popperjs – previously bundled into bootstrap distributed files – is now added as dependency. The bootstap ES6 sources, that we now use through rollup, do not bundle this external dependency (for good reasons). Dependency added with: yarn add @popperjs/core Further adaptions contained in this change to ensure beta1 compatibility: a) Carousel "item" to "carousel-item" class migration b) $.fn.modal(options) does no longer imply $.fn.modal('show') c) Fix panels, both JS and CSS (card-group can't be used here) d) All bootstrap data- tags are migrated to data-bs-. (see https://github.com/twbs/bootstrap/pull/31827) Migrated with # renderes a sed substition with the help of a nested sed from all the # data-bs attributes that where changed in the twbs/bootstrap commit git grep -l data- | xargs sed -i $( \ curl -s \ https://patch-diff.githubusercontent.com/raw/twbs/bootstrap/pull/31827.patch | \ sed 's/data-bs-[a-z-]*/\n&\n/g' | grep "data-bs-[a-z-]" | \ sort | uniq | \ sed 's/data-bs-\(.*\)\([^a-z-]\|$\)/ -e s\/data-\1\\\([^a-z-]\\\)\/data-bs-\1\\1\/g -e s\/data('"'"'\1'"'"')\/data('"'"'bs-\1'"'"')\/g/g' \ ) # Revert false positives from the above auto-replacement git checkout -- typo3/sysext/core/Documentation/Changelog/ \ typo3/sysext/backend/Classes/Form/Container/FlexFormContainerContainer.php \ Build/Sources/TypeScript/backend/Resources/Public/TypeScript/LiveSearch.ts \ Build/Sources/TypeScript/backend/Resources/Public/TypeScript/FormEngineFlexForm.ts \ Build/Sources/TypeScript/install/Resources/Public/TypeScript/Module/Settings/ExtensionConfiguration.ts \ Build/Sources/Sass/typo3/_element_panel.scss (cd Build && grunt build) Resolves: #93126 Resolves: #93123 Resolves: #93132 Related: #92616 Releases: master Change-Id: Ie194d0f87d2c60df7b9e8a6de4893cfaaea55356 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67215 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Martin Kutschker <mkutschker-typo3@yahoo.com> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Martin Kutschker <mkutschker-typo3@yahoo.com> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Benni Mack <benni@typo3.org>
-
- 20 Dec, 2020 1 commit
-
-
This changes removes the frontend framework Bootstrap 3, and adds Bootstrap 5 beta 1 (we expect Bootstrap 5 final by the time we release TYPO3 v11 LTS). Bootstrap v3 is not supported by the Bootstrap team any longer, so an update is critical for TYPO3 Core. Bootstrap v5 adds a few accessibility improvements as well as flexbox for rendering containers and grids throughout TYPO3 Backend. All JS components are not bound to jQuery anymore, and have been reworked. A lot of HTML/CSS changes happened, which we slowly migrate (and not in a huge change) to TYPO3's templates, in order to keep this change managable. A legacy CSS/SCSS file is added to keep some backwards-compatibility classes to ease the migration for extension developers who have built their own backend modules. Key features of Bootstrap 5: * "rem" instead of "px" is used by default * CSS variables are introduced * Improved bootstrap focus outline styling (buttons / inputs / links) * Simplified grid functionality * use new button color mixin to increase contrast: Primary, Success and Warning Button color is now dark instead of white EXT:styleguide was used as a basis for upgrading to keep compatibility as much as possible, but more changes will be coming in the next few minor releases. Resolves: #92616 Releases: master Change-Id: Iec989f39649b5460b055ec879199faf38e424f2b Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66247 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Benjamin Franzke <bfr@qbus.de> Tested-by:
Oliver Hader <oliver.hader@typo3.org> Tested-by:
Oliver Bartsch <bo@cedev.de> Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Benjamin Franzke <bfr@qbus.de> Reviewed-by:
Oliver Hader <oliver.hader@typo3.org> Reviewed-by:
Oliver Bartsch <bo@cedev.de> Reviewed-by:
Benni Mack <benni@typo3.org>
-
- 19 Dec, 2020 1 commit
-
-
This change removes the &route parameter from all Backend URLs, and changes them to speaking URLs like /typo3/main?token=123123123. For this change, it is necessary to adapt the installations' webserver configuration rewrite rules to enable URL rewriting in TYPO3 Backend. An silent upgrader will automatically update existing webserver configuration files like .htaccess or web.config to adapt to the TYPO3 Backend navigation concepts. Further steps will be using the browsers pushState functionality to update the URL when a module changes, and further deep-linking into TYPO3 Backend. Resolves: #93048 Releases: master Change-Id: Icdccfb4dbba71d2ecd08d619ed17ff49f6225b3e Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67083 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Benni Mack <benni@typo3.org>
-
- 18 Dec, 2020 2 commits
-
-
Since #92951 the PSR-7 request used in Core contains the `applicationType` attribute. Because ResetPasswordCommand creates its own "fake" request object, the new attribute must also be added there, to prevent a RuntimeException. Resolves: #93111 Releases: master Change-Id: I29c61edbdb0f8047d3e41ee2bb07a9551f2a2418 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67186 Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Benni Mack <benni@typo3.org>
-
The FormEngine table wizard in the backend is replace by a HTML custom element which allows to avoid server-side round-trips when manipulating table rows and columns. Resolves: #91811 Releases: master Change-Id: I8f9bc5b6c142d7492ff26461b4760eb68e132f2c Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65048 Tested-by:
Richard Haeser <richard@richardhaeser.com> Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Benjamin Franzke <bfr@qbus.de> Reviewed-by:
Richard Haeser <richard@richardhaeser.com> Reviewed-by:
Benjamin Franzke <bfr@qbus.de>
-
- 17 Dec, 2020 1 commit
-
-
To be able to introduce URL rewrites for the backend, the internal handling and registration of the shortcut PHP API is reworked. The Shortcut PHP API previously has the full URL of the shortcut target stored in the database. This lead to many problems such as shortcuts got invalid as soon as their target module changed its route path. Furthermore, this required unnecessary functionality like replacing tokens on URL creation. Therefore, a shortcut record now stores only the route identifier of the module to link to and necessary arguments in two new database columns. A upgrade wizard is in place to migrate existing data. The rework also required to deprecate some methods in the ShortcutButton API and a parameter signature change of the JavaScript function `TYPO3.ShortcutMenu.createShortcut()` which performs the AJAX call to create new shortcuts. Side effect, this also deprecated the last remains of xMOD_alt_doc.php in the core. Resolves: #93093 Releases: master Change-Id: I07666a299651e4953b4adf2987fcd3469094c288 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67143 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Daniel Goerz <daniel.goerz@posteo.de> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Daniel Goerz <daniel.goerz@posteo.de> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch>
-
- 15 Dec, 2020 2 commits
-
-
When a user logs in, the "cache" field "usergroup_cached_list" is updated in the be_users table. This value is used so the groups do not need to be recalculated each time for each user (e.g. in Workspaces when sending notifications and in Log module). However, this has serious flaws: 1) If an admin removes a previously active user from a BE group, the cached list still contains the old group, until the user logs in 2) If a user never logged in before, the list is empty This change removes this conceptual bug, and builds this into the GroupResolver to use direct (optimized) DB queries for these use cases, making the DB field obsolete. Resolves: #79565 Releases: master Change-Id: I9d8fd04cc466906d7f8da43887788f48de81c642 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67137 Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Georg Ringer <georg.ringer@gmail.com> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Georg Ringer <georg.ringer@gmail.com>
-
The following tsconfig configurations have been removed in favor of strong defaults and less configuration options: - `mod.web_layout.disableIconToolbar` - `mod.web_layout.disableSearchBox` Resolves: #93077 Releases: master Change-Id: I01da28e2b3fbc12693c00cb012c3749b4fa4b0c7 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67117 Tested-by:
Markus Klein <markus.klein@typo3.org> Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Reviewed-by:
Markus Klein <markus.klein@typo3.org> Reviewed-by:
Andreas Fernandez <a.fernandez@scripting-base.de>
-
- 14 Dec, 2020 2 commits
-
-
The ShortcutRepository should not deal with generating shortcut titles based on the provided arguments. This can never be reliable, especially for custom extension code. The appropriate title must be set by the calling controller since this is the place where all necessary information, to define such title, are available. Therefore, adding a new shortcut button without defining a display name is deprecated. All Core controllers are adjusted to provide the necessary title themself. Resolves: #93060 Releases: master Change-Id: Ic15fe13769dec841868977a862464f8dd3c73c42 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67096 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Benni Mack <benni@typo3.org>
-
In preparation for Doctrine DBAL 3.0, 1. all usages of Doctrine\DBAL\DBALException have been migrated to Doctrine\DBAL\Exception, because DBAL Exception does not exist in Doctrine 3.0 anymore. 2. Doctrine\DBAL\Platforms\PostgreSqlPlatform has been migrated to Doctrine\DBAL\Platforms\PostgreSQL94Platform because this class does not exist anymore in Doctrine DBAL 3.0, same goes for Doctrine\DBAL\Platforms\SQLServerPlatform which has been replaced by Doctrine\DBAL\Platforms\SQLServer2012Platform 3. Doctrine\DBAL\Driver\PDOException has been renamed to Doctrine\DBAL\Driver\PDO\Exception 4. Doctrine\DBAL\Driver\PDOStatement has been renamed to Doctrine\DBAL\Driver\PDO\Statement Resolves: #93071 Releases: master Change-Id: I05e82f2fca09eb7718a90c09f95e503980ae10ae Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67109 Tested-by:
Oliver Bartsch <bo@cedev.de> Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Oliver Bartsch <bo@cedev.de> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch>
-
- 12 Dec, 2020 1 commit
-
-
Resolves: #93065 Releases: master Change-Id: Ia12c5e6fbec0441bc41508c6985b73347331157d Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67102 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Benni Mack <benni@typo3.org> Tested-by:
Oliver Hader <oliver.hader@typo3.org> Reviewed-by:
Oliver Klee <typo3-coding@oliverklee.de> Reviewed-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Oliver Hader <oliver.hader@typo3.org>
-
- 10 Dec, 2020 3 commits
-
-
This patch avoids further undetected usages of deprecated methods: - ControllerContext::getFlashMessageQueue() - ControllerContext::getUriBuilder() Those methods have been called on a controller context instance obtained by the rendering context. Releases: master Resolves: #93036 Releates: #93019 Releates: #93016 Change-Id: I0634580479f2a814e2644d35cc25abc1ca411d79 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67075 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Benni Mack <benni@typo3.org> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch>
-
Benni Mack authored
The AbstractUserAuthentication class handles way too much of what it should know / do. For this reason, a new UserSession object which contains basic information needed for everything belonging to a non-fixated session, a fixated anonymous session, if a session was evelated, or if a session has expired, is kept in there. The "SessionManager" should not be used anymore publically but slowly dissolve into a SessionBackendManager. Design goals: * UserAuth object should not know about session backends * UserAuth should not store sessionData etc. directly in its own object * Decouple UserSession info from any properties of UserAuth * A UserSessionManager deals with the creation and validation of the UserSession objects. No Session Objects can be created etc outside of this class to maintain persistability * UserSessionManager also encapsulates ipLocking and the responsible SessionBackend Final goals to be tackled later: * Build a user session object from the request object, and not within the UserAuth object * Session Handling can be accessed outside of UserAuth * Cookie Handling and Session Handling are separated from UserAuth * Load Session information from PSR-7 request instead of $_COOKIE Resolves: #93023 Releases: master Change-Id: Ia2d8244e433d0f6adf220d443b2c0947f251b5e9 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66935 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Oliver Bartsch <bo@cedev.de> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Oliver Bartsch <bo@cedev.de> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Benni Mack <benni@typo3.org>
-
Inline JavaScript produced by BackendUtility:viewOnClick is substituted with markup based instructions and static JavaScript event handlers. // basically delivers window.open(generatedUri) BackendUtility::viewOnClick($pageId, $backPath, $rootLine, $section, $viewUri, $getVars, $switchFocus); can be substituted with e.g. \TYPO3\CMS\Backend\Routing\PreviewUriBuilder::create($pageId, $viewUri) ->withRootLine($rootLine) ->withSection($section) ->withAdditionalQueryParameters($getVars) ->serializeDispatcherAttributes([ PreviewUriBuilder::OPTION_SWITCH_FOCUS => $switchFocus, ]); which results in the following HTML data attributes (data can be retrieved as array of complete element as well) data-dispatch-action="TYPO3.WindowManager.localOpen" data-dispatch-args="["https://...",null,"previewWin"]" Resolves: #91123 Releases: master Change-Id: Iedd9bfe60827977677ee68e2c948c63e359abf84 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64243 Tested-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Reviewed-by:
Benni Mack <benni@typo3.org>
-
- 09 Dec, 2020 1 commit
-
-
* Since introduction of class ReferenceIndexUpdater each record is handled only once when updating the reference index. The record runtime cache is obsolete and can be dropped. * The $excludedTables and $excludedColumns properties are non-static now: In normal operation only one instance of ReferenceIndex class is created and used for many records, there is no point in creating hard to evict static state. * A runtime cache has been used for information derived from TCA (no db calls). This is dropped in favor of a class property. Change-Id: I5cf16e38ec8f36dfa838cdbc6591b59b463be3f9 Resolves: #93038 Releases: master Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67076 Tested-by:
Oliver Bartsch <bo@cedev.de> Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Oliver Bartsch <bo@cedev.de> Reviewed-by:
Benni Mack <benni@typo3.org>
-
- 08 Dec, 2020 3 commits
-
-
Keeping relation information for soft deleted records in sys_refindex is quite useless: When records are undeleted, the reference index is updated to recreate rows. Additionally, the deleted handling was incomplete, especially if a record on the 'right' side of the relation got deleted. The patch drops the deleted field from the table and prevents adding relations for soft deleted rows. Furthermore, visibility of a couple of properties and methods is changed to protected and a series of not used methods is removed. Note the hash sums change due to the removal of the deleted field. The CLI command "bin/typo3 referenceindex:update" will update hashes and will drop obsolete deleted rows. Change-Id: I58d7a904a6b4c555529b7c70e45d56ccb498f77f Resolves: #93029 Releases: master Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66968 Tested-by:
Oliver Bartsch <bo@cedev.de> Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Oliver Bartsch <bo@cedev.de> Reviewed-by:
Benni Mack <benni@typo3.org>
-
The method returned the opposite of what the function name defines. It checks whether the current backend route is a public route, and in that case it returned true. But if a public route is requested, then a backend user is actually *not* required. The method was then used inverted, which contervailed this mistake. Therefore there was no functional bug here, just a naming bug. Therefore we now invert the result of this method. Releases: master Resolves: #93021 Change-Id: I4ae585eb9259360cb3975df6654640d18ec45932 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67048 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Benni Mack <benni@typo3.org>
-
In previous TYPO3 versions, AbstractUserAuthentication emitted cookies directly via header() or setcookie() methods. In order to have a better testing scenario, this change builds Cookie objects and keeps them until a PSR-15 middleware asks to apply the cookie information to a PSR-7 Response. This also makes it possible to manipulate the authentication cookies in Middlewares. AbstractUserAuthentication does not actually "remove" or "set" a cookie but rather keeps the information for setting a cookie. Resolves: #93011 Releases: master Change-Id: Iaec0007a1347676bc3ba570b4b5a1da63d58d7e6 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67032 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Oliver Bartsch <bo@cedev.de> Tested-by:
Benjamin Franzke <bfr@qbus.de> Reviewed-by:
Oliver Bartsch <bo@cedev.de> Reviewed-by:
Benjamin Franzke <bfr@qbus.de>
-
- 07 Dec, 2020 2 commits
-
-
The internal methods * BackendUtility::blindUserNames() * BackendUtility::blindGroupNames() * BackendUtility::getBackendScript() are not in use anymore by TYPO3 Core and are removed. Also fix Breaking-91473-DeprecatedFunctionalityRemoved.rst to not reference BackendUtility::getBackendScript() as breaking removal, as it was an internal method. Resolves: #93001 Releases: master Change-Id: Icd280dada15b99266dd6542f8b256f03dc3c992a Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67037 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Oliver Bartsch <bo@cedev.de> Tested-by:
Benjamin Franzke <bfr@qbus.de> Reviewed-by:
Oliver Bartsch <bo@cedev.de> Reviewed-by:
Benjamin Franzke <bfr@qbus.de>
-
In order to allow further manipulation of Response objects, using "throw new ImmediateResponseException" is much more flexible than calling HttpUtility::redirect() which immediately stops the PHP process. This way, it is not even possible for developers to manipulate the response, or even test this behavior in functional tests with TYPO3 Core. The change removes all usages of HttpUtility::redirect(). The method will be deprecated at a later stage. Resolves: #93004 Releases: master Change-Id: I9bd0db2b2ee0c15b39b38168d67e6d78ba4be2db Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67038 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Daniel Gorges <daniel.gorges@b13.com> Tested-by:
Benjamin Franzke <bfr@qbus.de> Reviewed-by:
Daniel Gorges <daniel.gorges@b13.com> Reviewed-by:
Benjamin Franzke <bfr@qbus.de>
-
- 04 Dec, 2020 1 commit
-
-
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/+/66972 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Marcus Schwemer <ms@schwemer.de> Tested-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Reviewed-by:
Marcus Schwemer <ms@schwemer.de> Reviewed-by:
Andreas Fernandez <a.fernandez@scripting-base.de>
-
- 30 Nov, 2020 1 commit
-
-
Drop all usages of TYPO3_MODE and TYPO3_REQUESTTYPE by using the ApplicationType helper class when frontend or backend is detected, and by directly using the applicationType attribute of the request object in a couple of special cases that check for backend ajax or install tool. Resolves: #92953 Related: #92951 Related: #92947 Releases: master Change-Id: I98c9d5ef0e7a6409b01188ddd0bbcf94f159cbcd Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66895 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Simon Gilli <typo3@gilbertsoft.org> Tested-by:
Oliver Bartsch <bo@cedev.de> Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Simon Gilli <typo3@gilbertsoft.org> Reviewed-by:
Oliver Bartsch <bo@cedev.de> Reviewed-by:
Benni Mack <benni@typo3.org>
-
- 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/+/66942 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Tested-by:
Simon Gilli <typo3@gilbertsoft.org> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Reviewed-by:
Simon Gilli <typo3@gilbertsoft.org> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch>
-
- 27 Nov, 2020 1 commit
-
-
Calling `AbstractTreeView::getIcon()` with the records uid as first argument is deprecated. This helps to increase type safety through the core and also properly reflects the expected value for the parameter, as its name is `$row`. Side note: There was no benefit in providing just the records uid since the full record was fetched in that case anyways internally, but without adding any restrictions or respecting any overlays. Because the method returns a string in any case, the return type is furthermore added to the method signature. Resolves: #92922 Releases: master Change-Id: I60ccaf17d8244a2a86fb3b9bc377ce19a6a58e69 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66892 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Georg Ringer <georg.ringer@gmail.com> Tested-by:
Daniel Haupt <mail@danielhaupt.de> Tested-by:
Daniel Goerz <daniel.goerz@posteo.de> Reviewed-by:
Georg Ringer <georg.ringer@gmail.com> Reviewed-by:
Daniel Haupt <mail@danielhaupt.de> Reviewed-by:
Daniel Goerz <daniel.goerz@posteo.de>
-
- 26 Nov, 2020 1 commit
-
-
Benni Mack authored
The UserTsConfig setting `options.lockToIP` is removed, which was only active the global setting $GLOBALS['TYPO3_CONF_VARS']['BE']['enabledBeUserIPLock'] was active. Happy Eyeballs makes this feature very useless, but if this is still needed, it should be rather implemented as an individual AuthenticationService or PSR-15 middleware than evaluated separately. Resolves: #92941 Releases: master Change-Id: I1e2be7784a3c4b54573b3c3118db1fb3109b0ddc Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66640 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Georg Ringer <georg.ringer@gmail.com> Tested-by:
Daniel Haupt <mail@danielhaupt.de> Tested-by:
Oliver Bartsch <bo@cedev.de> Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Georg Ringer <georg.ringer@gmail.com> Reviewed-by:
Daniel Haupt <mail@danielhaupt.de> Reviewed-by:
Oliver Bartsch <bo@cedev.de> Reviewed-by:
Benni Mack <benni@typo3.org>
-
- 25 Nov, 2020 1 commit
-
-
Add missing descriptions to ViewHelpers, improving the usability within the IDE as also on the ViewHelpers docs, since these values are rendered there automatically. Resolves: #92927 Releases: master, 10.4 Change-Id: I9b5506c39f92a65840da0d187f1c7cc7f4a1810b Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66897 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Georg Ringer <georg.ringer@gmail.com> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Sybille Peters <sypets@gmx.de> Reviewed-by:
Georg Ringer <georg.ringer@gmail.com> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch>
-
- 24 Nov, 2020 1 commit
-
-
The feature toggle for `fluidBasedPageModule` is removed to enforce the use of the new fluid based page module. The already deprecated `PageLayoutView` will finally be removed in a separate patch. Resolves: #92870 Releases: master Change-Id: I974a1b010cb14a545e80b7486f5f7c1f0083788e Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66698 Tested-by:
Oliver Bartsch <bo@cedev.de> Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Oliver Bartsch <bo@cedev.de> Reviewed-by:
Benni Mack <benni@typo3.org>
-
- 23 Nov, 2020 1 commit
-
-
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/+/66557 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>
-
- 20 Nov, 2020 3 commits
-
-
Also add aria-expanded and aria-controls arguments for screen readers Resolves: #92682 Releases: master, 10.4 Change-Id: I48d0edcbea4d185d11216048d7847ad3574d704d Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66271 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Michael Telgkamp <michael.telgkamp@mindscreen.de> Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Michael Telgkamp <michael.telgkamp@mindscreen.de> Reviewed-by:
Benni Mack <benni@typo3.org>
-
States of checkboxes defined in the TCA with "invertStateDisplay" enabled are announced in the same way as the visual representation. The underlaying checkbox value is inverted instead of just inverting the corresponding visual representation. The CSS class "checkbox-invert" used for styling these checkboxes has been removed. Resolves: #92678 Releases: master Change-Id: Id35d0cc3b3872a8176f30eee6abdf49287a2c44a Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66282 Tested-by:
Michael Telgkamp <michael.telgkamp@mindscreen.de> Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Michael Telgkamp <michael.telgkamp@mindscreen.de> Reviewed-by:
Benni Mack <benni@typo3.org>
-
Instead of <a href="#" ...> or <span ...>, a <button> tag is used for inline relations to enable proper keyboard navigation. * rename variable and protected method names from "link" to "button" * remove unsed $objectPrefix argument from getLevelInteractionLink (now ...Button) Resolves: #91595 Releases: master, 10.4 Change-Id: I167c175fe9e0fa211e637936e9d777459f892e79 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66233 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Michael Telgkamp <michael.telgkamp@mindscreen.de> Tested-by:
Martin Kutschker <mkutschker-typo3@yahoo.com> Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Michael Telgkamp <michael.telgkamp@mindscreen.de> Reviewed-by:
Oliver Klee <typo3-coding@oliverklee.de> Reviewed-by:
Martin Kutschker <mkutschker-typo3@yahoo.com> Reviewed-by:
Torben Hansen <derhansen@gmail.com> Reviewed-by:
Benni Mack <benni@typo3.org>
-
- 19 Nov, 2020 1 commit
-
-
Frontend, backend and install tool application classes are the main entry points to create a response from a request object. From within a HTTP index.php, run() is called, which creates the request object from globals and feeds that to handle(). But, to retrieve a TYPO3 response from within a different PHP application, or from within TYPO3 itself (eg. a backend calls a frontend), the leading application would want to hand over a given or specially crafted PSR-7 ServerRequest directly. This is exactly what PSR-15 RequestHandlerInterface is for. By implementing this inteface in the application classes, the core increases interoperability significantly and allows to be easily called by a third party PHP application. Resolves: #92884 Releases: master Change-Id: I3047c92de06668db4dd5ef224bafde23f4b8ebd5 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66710 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Georg Ringer <georg.ringer@gmail.com> Reviewed-by:
Benni Mack <benni@typo3.org>
-
- 17 Nov, 2020 1 commit
-
-
If the TSconfig setting is turned on, translations of content elements are bound to the default record in the display. This means that within each column with content elements any translation found for exactly the shown default content element will be shown in the language column next to the translation. This feature has been forgotten during the rewrite and is now readded. Resolves: #92482 Releases: master, 10.4 Change-Id: I408343d3b9a33b3239d1f341f3df36b65d2cd9c8 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66412 Tested-by:
Oliver Bartsch <bo@cedev.de> Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Oliver Bartsch <bo@cedev.de> Reviewed-by:
Benni Mack <benni@typo3.org>
-
- 14 Nov, 2020 2 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/+/65237 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Markus Klein <markus.klein@typo3.org> Tested-by:
Georg Ringer <georg.ringer@gmail.com> Reviewed-by:
Markus Klein <markus.klein@typo3.org> Reviewed-by:
Georg Ringer <georg.ringer@gmail.com>
-
The TSconfig setting `mod.web_layout.disableAdvanced` has been used to disable the "clear cache"-button in the page module. Since this behaviour can be triggered through various other ways, like the context menu or by just saving the page record, this feature is removed completely. Resolves: #92837 Releases: master Change-Id: Ie4c563d89280bc494265611924e2b02727aed644 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66631 Tested-by:
Markus Klein <markus.klein@typo3.org> Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Markus Klein <markus.klein@typo3.org> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch>
-
- 13 Nov, 2020 1 commit
-
-
This change adds the methods * setRequest() * getRequest() * getUriBuilder() to the RenderingContext of EXT:Fluid. The main goal is to reduce the usages of the ControllerContext as much as possible to decouple Extbase from Fluid. When the "setRequest" method is used in the renderingContext, the controllerContext is filled as well, in order to be backwards-compatible. Resolves: #92826 Releases: master Change-Id: I41b8741e947c78895317ef2235959ceb251e103c Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66323 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Markus Klein <markus.klein@typo3.org> Tested-by:
Georg Ringer <georg.ringer@gmail.com> Reviewed-by:
Markus Klein <markus.klein@typo3.org> Reviewed-by:
Georg Ringer <georg.ringer@gmail.com>
-
- 12 Nov, 2020 1 commit
-
-
Benni Mack authored
Creating a new record in a workspace adds two database rows. One that is the "placeholder", which - since v10.4 - contains the same metadata as the other record: * t3ver_wsid = workspaceID * t3ver_oid = 0 (simulating behavior of an "online pendant record") * t3ver_state = 1 And the "versionized" record, identified by: * t3ver_wsid = workspaceID * t3ver_oid = uid of the new placeholder record * t3ver_state = -1 As of TYPO3 v10, the first record is not needed anymore, the versioned record can be queried directly, however, since the relations (except MM) point to the placeholder record, this one is kept. As result, only one record is created from now on: * t3ver_wsid = workspaceID * t3ver_oid = 0 (no online counterpart) * t3ver_state = 1 On reading, the record is queried directly (no overlay needed anymore!) with the existing Database Doctrine Restrictions. On publishing, the record just gets the state/stage/wsid set and is "live". This brings fundamental benefits: * No overlays needed when querying * Fewer database records (placeholders are not helpful) * Conceptual problems with placeholder and shadowed fields are removed Resolves: #92791 Releases: master Change-Id: I0288cc63fe72d8442d586f309bd4054ac44e829b Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65587 Tested-by:
TYPO3com <noreply@typo3.com> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
Oliver Bartsch <bo@cedev.de> Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Oliver Bartsch <bo@cedev.de> Reviewed-by:
Benni Mack <benni@typo3.org>
-