- Aug 23, 2022
-
-
Benjamin Franzke authored
Yarn has been added to TYPO3 back in 2017 because npm shrinkwrap files were not stable and package-lock.json and `npm ci` not yet established. By now the yarn version in TYPO3 (v1) got outdated and an update to yarn v3 would be required sooner or later. The update to yarn v3 brings quite some problems for the TYPO3 codebase: - Yarn v3 is executed/proxied through yarn v1 (installed on the developer machine) – therefore the yarn v3 executable needs to be tracked within git. See https://yarnpkg.com/cli/set/version#details - Yarn v3 pulls in @types/node (through the "got" package) for unknown reasons, causing clashes with TypeScript declarations for requirejs (window.require vs node's require()) As package-lock.json is solid thesedays, there is no real need to depend on yarn anymore. We basically switch to npm because that switch is way more straightforward than migrating to yarn v3 and it removes one dependency. Note that `npm install` properly honors `package-lock.json` these days (no implicit version upgrades due to the lock file), but is faster than `npm ci`, therefore it is used in `grunt build` and runTests.sh for all developer oriented build-targets. All CI checks use `npm ci` to enfore a clean install. We set the required npm verson to v8 in order to use the newest package-lock.json v3 format and .nvmrc is updated to suggest the recent nodejs v16 LTS release, as npm v8 is shipped with nodejs v16 by default. Note that node v14 may still be used to compile packages, but npm v8 is needed for dependency installation (installable via `npm install -g npm` in node v14 installations). For that reason the CI docker images are updated to use nodejs v16 instead of nodejs v14, see following ticket for details: https://git.typo3.org/typo3/CI/testing-infrastructure/-/issues/3 Executed Commands: cd Build/ # be sure the node_modules folder dir and is updated yarn install sed -i 's/"yarn": "^1.22.0"/"npm": ">=8.0.0 <9.0.0"/' package.json rm -f package-lock.json # npm install >= v7 can read yarn.lock and will create # package-lock.json as a result npm install git add package-lock.json git rm -f yarn.lock npm remove "jquery-ui" # The use of `git@` in the HTTPS URLs is a workaround for NPM's # auto-rewrite that results in an SSH URL being used instead, # which fails to install in CI. # See npm/cli#2610 for more information. npm install "git+https://git@github.com/jquery/jquery-ui#1.11.4" # Fix fsevents not being installed npm install rollup@~2.32.0 # Explicitly pull in popperjs which would be included by npm's # resolver in npm >8.5 npm install @popperjs/core@^2.11.6 # Let npm build a new, fully clean tree, without old yarn cruft rm -rf node_modules/ npm install grunt default Resolves: #96355 Related: #83038 Releases: main Change-Id: I88c1ecb1b12dcd117ac4200307af72d330c76d27 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/72642 Tested-by:
Benni Mack <benni@typo3.org> Tested-by:
core-ci <typo3@b13.com> Tested-by:
Stefan Bürk <stefan@buerk.tech> Tested-by:
Benjamin Franzke <bfr@qbus.de> Reviewed-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Stefan Bürk <stefan@buerk.tech> Reviewed-by:
Benjamin Franzke <bfr@qbus.de>
-
- Aug 22, 2022
-
-
Kevin Appelt authored
The check if the image has to be processed has been moved to dedicated methods to enhance readability and testability The condition still checks if the image is wider than the defined maximum width. The check if the entire image is used should now be easier to understand. No offset and 100% of the width and height of the image correspond to the full image and negated in its entirety. Resolves: #98118 Releases: main, 11.5 Change-Id: I8283e2f74310654455fb247e84c9e4204f3e1dd4 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75422 Tested-by:
Sascha Egerer <sascha@sascha-egerer.de> Tested-by:
core-ci <typo3@b13.com> Tested-by:
Oliver Hader <oliver.hader@typo3.org> Tested-by:
Benjamin Franzke <bfr@qbus.de> Reviewed-by:
Sascha Egerer <sascha@sascha-egerer.de> Reviewed-by:
Oliver Hader <oliver.hader@typo3.org> Reviewed-by:
Benjamin Franzke <bfr@qbus.de>
-
Oliver Hader authored
Avoid undefined array key warning in case 'config' is not given in TypoScript settings. Resolves: #98145 Releases: main, 11.5 Change-Id: I20df94bd34f9f7197eee7905f5aa1c2af35d0601 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75529 Tested-by:
core-ci <typo3@b13.com> Tested-by:
Oliver Hader <oliver.hader@typo3.org> Reviewed-by:
Oliver Klee <typo3-coding@oliverklee.de> Reviewed-by:
Oliver Hader <oliver.hader@typo3.org>
-
- Aug 21, 2022
-
-
Peter Kraume authored
Resolves: #98183 Releases: main, 11.5 Change-Id: Ib4d123e86a9b158b86e20322fc53ca94ff5b9be7 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75525 Tested-by:
core-ci <typo3@b13.com> Tested-by:
Torben Hansen <derhansen@gmail.com> Tested-by:
Nikita Hovratov <nikita.h@live.de> Reviewed-by:
Oliver Klee <typo3-coding@oliverklee.de> Reviewed-by:
Thomas Löffler <loeffler@spooner-web.de> Reviewed-by:
Torben Hansen <derhansen@gmail.com> Reviewed-by:
Nikita Hovratov <nikita.h@live.de>
-
- Aug 19, 2022
-
-
Andreas Fernandez authored
Previous TYPO3 installations allowed to configure an interface selector in the backend login that gave the authenticating backend user the possibility to choose whether to get redirected to frontend or backend by configuring `$GLOBALS['TYPO3_CONF_VARS']['BE']['interfaces'] = 'backend,frontend'`. If only one option was configured, the redirect to either backend or frontend was enforced, where `backend` was the default configuration. This feature was meaningful once TYPO3 shipped EXT:feedit, but was conceptually broken ever since, as the matter of fact a TYPO3 installation can contain multiple site roots was overseen and a user may get redirected to the wrong frontend. Also, if EXT:adminpanel is not installed, there is no one-click solution to access the TYPO3 backend. Resolves: #98179 Releases: main Change-Id: Ic759e6c1016d70c07dc8862a0b8c21b14c3d904b Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75487 Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
Stefan Bürk <stefan@buerk.tech> Tested-by:
core-ci <typo3@b13.com> Tested-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Stefan Bürk <stefan@buerk.tech> Reviewed-by:
Andreas Fernandez <a.fernandez@scripting-base.de>
-
Andreas Fernandez authored
If a record is edited via single field mode (aka "columnsOnly"), the label field as defined via TCA may be missing, rendering "[No title]" in the notification message. Before compiling the notification message, it is now checked whether the label exists already. If not, the label of the record is fetched from the database, if such label field is configured via TCA at all. Resolves: #98142 Releases: main Change-Id: I2babfcae354b1fad15c653e61449353cd2efb8a4 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75443 Tested-by:
core-ci <typo3@b13.com> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
Stefan Bürk <stefan@buerk.tech> Tested-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Stefan Bürk <stefan@buerk.tech> Reviewed-by:
Andreas Fernandez <a.fernandez@scripting-base.de>
-
Chris Müller authored
If either labels or base are not given, the default values kick in: labels = iec and base = 1024 With the new fallback values in place test ContentObjectRendererTest notAllStdWrapProcessorsAreCallableWithEmptyConfiguration() needs a minor adaption. Resolves: #98154 Releases: main, 11.5 Change-Id: Ib2a242454197be94a75fb3d5bffbb8d0be8a1523 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75484 Tested-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Tested-by:
core-ci <typo3@b13.com> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch>
-
Andreas Fernandez authored
The context menu module now passes the dataset bound to a context menu item to the respective callback action, excluding `callback-action` and `callback-module`. The context menu items bound to `this` in the respective callback actions are not required anymore, allowing to ditch jQuery in the `context-menu-actions` modules. For this reason, binding the context menu item to `this` is deprecated, usages will trigger a deprecation log entry in the browser's console. Resolves: #98168 Releases: main Change-Id: Ibaf3c5b343323dcd29bd9aae3212ebcee91d83ef Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75491 Tested-by:
Benjamin Franzke <bfr@qbus.de> Tested-by:
core-ci <typo3@b13.com> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Reviewed-by:
Benjamin Franzke <bfr@qbus.de> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Andreas Fernandez <a.fernandez@scripting-base.de>
-
Andreas Fernandez authored
The patches #98164 and #98165 conflicted with each other as one made the modal API stricter while the other populated the modal with a soon-to-be invalid configuration. This currently breaks all subsequent builds. The modals received objects of type `Node` which are not consumable by jQuery's `append()` method. To solve this issue, `Node` is now converted to a `DocumentFragment`, which can be consumed by all involved parties. Resolves: #98177 Related: #98164 Related: #98165 Releases: main Change-Id: I4524b383e559d3b1342c0bf95e435caec6d36cc6 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75517 Tested-by:
core-ci <typo3@b13.com> Tested-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch>
-
Larry Garfield authored
Doing so allows us to remove an unnecessary test, as well. 'mixed' type declarations not included to allow backporting. Used command: > ./Build/Scripts/runTests.sh -s phpstanGenerateBaseline Resolves: #98027 Releases: main Change-Id: I3c499e557c5d5bc31bf471e577760f4268fa26cc Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75295 Tested-by:
Stefan Bürk <stefan@buerk.tech> Tested-by:
core-ci <typo3@b13.com> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Stefan Bürk <stefan@buerk.tech> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch>
-
Torben Hansen authored
This patch fixes a warning on PHP 8.1, when a FlexForm has a sheet with no fields in it. Resolves: #98166 Releases: main, 11.5 Change-Id: Iec814a10bb755fb78a8de95b432d8cb6042a07d3 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75490 Tested-by:
core-ci <typo3@b13.com> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Reviewed-by:
Oliver Klee <typo3-coding@oliverklee.de> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Andreas Fernandez <a.fernandez@scripting-base.de>
-
Andreas Fernandez authored
Two usages of jQuery are removed in EXT:dashboard. jQuery was only used to convert a string containing HTML to a jQuery object to be able to render markup in the DOM. Resolves: #98165 Releases: main Change-Id: I54c1f6f2a99a7ccfe63c95e5b2ab84afc7451ff9 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75489 Tested-by:
Benjamin Franzke <bfr@qbus.de> Tested-by:
core-ci <typo3@b13.com> Tested-by:
Frank Nägler <frank.naegler@typo3.com> Tested-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Reviewed-by:
Benjamin Franzke <bfr@qbus.de> Reviewed-by:
Frank Nägler <frank.naegler@typo3.com> Reviewed-by:
Andreas Fernandez <a.fernandez@scripting-base.de>
-
Andreas Fernandez authored
The configuration definition of `content` in the Modal API is extended to accept objects of types `Element` and `DocumentFragment` as well, which allows passing arbitrary DOM nodes to the API, if TypeScript is used. Since jQuery is still the main actor in the Modal API, no further adjustments are required for now as jQuery can consume the added types. In the same run, the API definition got stricter as `Modal.advanced()` allowed to pass any arbitrary configuration not covered by the internal `Configuration` interface. Resolves: #98164 Releases: main, 11.5 Change-Id: Ibf7cc836fcffa870a1eb4c5d4615c44e046cf192 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75488 Tested-by:
core-ci <typo3@b13.com> Tested-by:
Frank Nägler <frank.naegler@typo3.com> Tested-by:
Benjamin Franzke <bfr@qbus.de> Tested-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Reviewed-by:
Frank Nägler <frank.naegler@typo3.com> Reviewed-by:
Benjamin Franzke <bfr@qbus.de> Reviewed-by:
Andreas Fernandez <a.fernandez@scripting-base.de>
-
- Aug 17, 2022
-
-
Benni Mack authored
This change raises the used Symfony Components to at least version Symfony 6.1. The requirement for "typo3/symfony-psr-event-dispatcher-adapter" is removed, as this was for support for allowing symfony4 AND symfony5 with the same TYPO3 major version. A few important highlights: * Symfony DI now only accepts objects or null to be returned by $container->get('myService') * Lots of typehints were added, this is mainly an issue if extensions extend Symfony classes * PHP 8.1+ requirements (which we already have in place for TYPO3 v12) See all features within Symfony 6.1: * https://symfony.com/blog/category/living-on-the-edge/6.1 Symfony 6 is supported until November 2027 (once we upgrade to Symfony 6 LTS, which will happen in November 2023) unlike Symfony 5 LTS which has an EOL on November 2025. Used commands: > composer req composer/composer:^2.3.0 -W --dev > composer remove typo3/symfony-psr-event-dispatcher-adapter > composer remove --no-update -d typo3/sysext/core \ typo3/symfony-psr-event-dispatcher-adapter > composer req --no-update -d typo3/sysext/adminpanel \ symfony/var-dumper:^6.1 > composer req --no-update -d typo3/sysext/core \ psr/container:^2.0 \ symfony/config:^6.1 \ symfony/console:^6.1 \ symfony/dependency-injection:^6.1 \ symfony/event-dispatcher-contracts:^3.1 \ symfony/expression-language:^6.1 \ symfony/filesystem:^6.1 \ symfony/finder:^6.1 \ symfony/http-foundation:^6.1 \ symfony/mailer:^6.1 \ symfony/mime:^6.1 \ symfony/options-resolver:^6.1 \ symfony/rate-limiter:^6.1 \ symfony/routing:^6.1 \ symfony/yaml:^6.1 > composer req --no-update -d typo3/sysext/extbase \ symfony/dependency-injection:^6.1 \ symfony/property-access:^6.1 \ symfony/property-info:^6.1 > composer req --no-update -d typo3/sysext/fluid \ symfony/dependency-injection:^6.1 > composer req --no-update -d typo3/sysext/form \ symfony/expression-language:^6.1 > composer req --no-update -d typo3/sysext/install \ symfony/finder:^6.1 \ symfony/http-foundation:^6.1 > composer req --no-update -d typo3/sysext/redirects \ symfony/console:^6.1 > composer req -W \ psr/container:^2.0 \ symfony/config:^6.1 \ symfony/console:^6.1 \ symfony/dependency-injection:^6.1 \ symfony/event-dispatcher-contracts:^3.1 \ symfony/expression-language:^6.1 \ symfony/filesystem:^6.1 \ symfony/finder:^6.1 \ symfony/http-foundation:^6.1 \ symfony/mailer:^6.1 \ symfony/mime:^6.1 \ symfony/options-resolver:^6.1 \ symfony/property-access:^6.1 \ symfony/property-info:^6.1 \ symfony/rate-limiter:^6.1 \ symfony/routing:^6.1 \ symfony/var-dumper:^6.1 \ symfony/yaml:^6.1 Resolves: #98158 Releases: main Change-Id: Ibfa656fb499003405d1c2cb49570e735698b6a6b Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75427 Tested-by:
core-ci <typo3@b13.com> Tested-by:
Stefan Bürk <stefan@buerk.tech> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Stefan Bürk <stefan@buerk.tech> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch>
-
Torben Hansen authored
Since ext:felogin already uses strict type declarations for function arguments and return types, various parameter- and return-type declarations in PHPDoc comments can safely be removed. With this patch the following changes are applied: * removed superfluous @param type declarations * removed superfluous @return declarations * removed non-thrown @throws annotations * added missing function type declarations in tests Used command: > Build/Scripts/runTests.sh -s phpstanGenerateBaseline Resolves: #98139 Releases: main, 11.5 Change-Id: I47749a748e808f6801928951397ed0bff8d6a115 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75439 Tested-by:
core-ci <typo3@b13.com> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
Stefan Bürk <stefan@buerk.tech> Reviewed-by:
Oliver Klee <typo3-coding@oliverklee.de> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Stefan Bürk <stefan@buerk.tech>
-
Torben Hansen authored
Since the demand object already uses strict types, it is safe to use strict comparison when properties of the demand object are used as operand. Resolves: #98141 Releases: main Change-Id: I6741c022f9d382416be6cab034d793fedfa35477 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75441 Tested-by:
core-ci <typo3@b13.com> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Oliver Klee <typo3-coding@oliverklee.de> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Benni Mack <benni@typo3.org>
-
Andreas Fernandez authored
This patch aims to remove jQuery from the TYPO3 backend login. Since some jQuery magic was used to dynamically adjust the height of the carousel with a nice animation, which is not so easy to solve in pure CSS and JavaScript, the carousel now has a fixed height. To make the approach a little bit more appealing and usable for mobile users who usually don't see a scrollbar, the top and bottom area of the carousel container are faded if text is overflown to indicate a scrollable area. To make sliding to the next slide in the carousel less "jumpy", smooth scrolling is explicitly enabled here. Resolves: #98157 Releases: main Change-Id: I08ecd847d29696fd25f6330cee089a55a03102c0 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75473 Tested-by:
Susanne Moog <look@susi.dev> Tested-by:
core-ci <typo3@b13.com> Tested-by:
Benjamin Franzke <bfr@qbus.de> Reviewed-by:
Susanne Moog <look@susi.dev> Reviewed-by:
Benjamin Franzke <bfr@qbus.de>
-
Tomasz Woldański authored
Patch fixes warning on PHP 8.1 in AbstractItemProvider Resolves: #98151 Releases: main, 11.5 Change-Id: Ic74ec7771be077aa5e6a84e8db3310fc895dcc02 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75476 Reviewed-by:
Oliver Klee <typo3-coding@oliverklee.de> Reviewed-by:
Torben Hansen <derhansen@gmail.com> Reviewed-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
core-ci <typo3@b13.com> Tested-by:
Benni Mack <benni@typo3.org> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch>
-
Tomasz Woldański authored
Patch fixes warning on PHP 8.1 in extbase Backend class. Resolves: #98149 Releases: main, 11.5 Change-Id: I6f32f67672332758cc02708d07481b93edb09b82 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75474 Reviewed-by:
Oliver Klee <typo3-coding@oliverklee.de> Reviewed-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
core-ci <typo3@b13.com> Tested-by:
Benni Mack <benni@typo3.org> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch>
-
Tomasz Woldański authored
Patch fixes warning on PHP 8.1 in MenuProcessor Resolves: #98150 Releases: main, 11.5 Change-Id: I9cee1d6d0adcde22a74e040ac53657db3348c514 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75475 Reviewed-by:
Oliver Klee <typo3-coding@oliverklee.de> Reviewed-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
core-ci <typo3@b13.com> Tested-by:
Benni Mack <benni@typo3.org> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch>
-
Torben Hansen authored
When a FlexForm has an empty data structure, a warning is thrown in PHP8, because it is not checked in FlexFormNoTabsContainer if the resolved sheet name actually exists as key in the flexFormRowData array. This patch uses the null coalescing operator to fix the problem. Resolves: #98147 Releases: main, 11.5 Change-Id: Ie4bde3af79a9a473cc02aff9f1ec299fff1bc259 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75448 Tested-by:
core-ci <typo3@b13.com> Tested-by:
Benni Mack <benni@typo3.org> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Oliver Klee <typo3-coding@oliverklee.de> Reviewed-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch>
-
Christian Kuhn authored
Workspace backend module: With #94935 the "Entire workspace" mass drop down has been placed more prominently by moving it to the first position in the action drop down row. The "Entire workspace" action publishes *all* pending workspace changes of *all* pages at once. Depending on use case, this can be dangerous: There are cases where a workspace is used to prepare a small amount of changes, to then publish everything at once. This is fine. There are also use cases where editors use one big workspace to prepare distinct changes in multiple pages and then publish single pages only. In the latter case, accidently using the "Publish absolutely everything" drop down will publish lots of unwanted changes. To mitigate this risk, admins get a new toggle in the workspace 'publish_access' field of workspace records to hide the "Entire workspace" action drop down of this workspace when checked. Resolves: #98155 Related: #94935 Related: #96468 Releases: main, 11.5 Change-Id: Ia55bf509df17842ad1f6c5fdea031fb633419f08 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75478 Tested-by:
core-ci <typo3@b13.com> Tested-by:
Claus-Peter Eberwein <claus-peter.eberwein@b13.com> Tested-by:
Benni Mack <benni@typo3.org> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Claus-Peter Eberwein <claus-peter.eberwein@b13.com> Reviewed-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch>
-
Chris Müller authored
With #98090 TYPO3_CONF_VARS['SYS']['UTF8filesystem'] was set to true for new installations. This should also be documented in the changelog. Resolves: #98144 Related: #98090 Releases: main Change-Id: Ia18c0347c745967586a47ff5167327bac283051e Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75445 Tested-by:
Stefan Bürk <stefan@buerk.tech> Tested-by:
core-ci <typo3@b13.com> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Stefan Bürk <stefan@buerk.tech> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch>
-
- Aug 16, 2022
-
-
Benni Mack authored
Backend modules which use absolute paths (which do not exist) should not raise an exception / error when using versionNumberInFilename checks. This happens e.g. with EXT:solr backend modules since #97939 was fixed. In the long-term extensions should define proper paths, so they also work in TYPO3 installations within a subfolder but for the time being, this change helps to solve the problem. Resolves: #98152 Related: #98106 Related: #97939 Releases: main, 11.5, 10.4 Change-Id: I071f2e63d4423d157f0f060a1295cb145474ee9d Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75477 Tested-by:
Lina Wolf <112@linawolf.de> Tested-by:
core-ci <typo3@b13.com> Tested-by:
Simon Schaufelberger <simonschaufi+typo3@gmail.com> Tested-by:
David Steeb <david.steeb@b13.com> Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Lina Wolf <112@linawolf.de> Reviewed-by:
Simon Schaufelberger <simonschaufi+typo3@gmail.com> Reviewed-by:
David Steeb <david.steeb@b13.com> Reviewed-by:
Benni Mack <benni@typo3.org>
-
- Aug 15, 2022
-
-
Elias Häußler authored
With #93887 (respectively #92406), a more convenient rendering mechanism for forms was introduced. A new FormRequestHandler centralized all the logic from the <formvh:render> view helper to allow smoother form handling. However, the new implementation used to hide the current ContentObjectRenderer implementation and instead always fetched a new instance with GeneralUtility::makeInstance(). This no longer allows to determine the current content object rendering context from e.g. form finishers. Since the current implementation can be retrieved by the ConfigurationManager, it is now used in the <formvh:render> view helper, falling back to a new ContentObjectRenderer instance in case the ConfigurationManager does not actually provide an instance of ContentObjectRenderer. Resolves: #97977 Related: #93887 Related: #92406 Releases: main, 11.5 Change-Id: Iabf4e93e6aff8da742321958730521ef1696f130 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75247 Tested-by:
core-ci <typo3@b13.com> Tested-by:
waldhacker <hello@waldhacker.dev> Tested-by:
theline <typo3@root-access.de> Tested-by:
Oliver Hader <oliver.hader@typo3.org> Reviewed-by:
waldhacker <hello@waldhacker.dev> Reviewed-by:
theline <typo3@root-access.de> Reviewed-by:
Oliver Hader <oliver.hader@typo3.org>
-
Nikita Hovratov authored
With #88276 a new condition has been implemented to check for current selected pageLayout in FE and BE, example: [tree.pagelayout == "pagets__simple"] This has various bugs. Frontend: * The evaluation stops at the sys_template record that has 'root' flag set. This is not in-line with the backend condition implementation, which goes further up in rootline. * The evaluation does not look for first specified layout up in rootline, but goes from root down to selected page. The condition thus calculates wrong layout when different 'backend_layout_next_level' are nested on rootline pages, it picks the uppermost set, not the lowermost one. This is fixed by using TSFE->rootLine instead of tmpl->rootLine, since TSFE->rootLine provides the full rootline in correct order. Backend: * Similar to FE, the evaluation should go up in rootline, but is processed downwards instead. This is fixed by handing over the 'reversed' full rootline. The v12 version of the patch is slightly different: Patch for issue #97963 introduced yet another bug by accessing TSFE->config['rootLine'], which isn't set at all at this point in the frontend processing chain when the page is not yet cached, or has no USER_INT or COA_INT. Resolves: #98044 Related: #88276 Related: #97963 Releases: main, 11.5 Change-Id: I1dc9a4dfc6aea6bec4d8e2eb65a6919d486f4a99 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75319 Tested-by:
core-ci <typo3@b13.com> Tested-by:
Stefan Bürk <stefan@buerk.tech> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
Nikita Hovratov <nikita.h@live.de> Reviewed-by:
Stefan Bürk <stefan@buerk.tech> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Nikita Hovratov <nikita.h@live.de>
-
Stefan Bürk authored
With the removal of the Font Awesome icon provider in #98089 the corresponding scss/css styling definition for the module name has been removed. This made it impossible to fully collapse the module menu to icons and to a smaller size. Bootstrap 5 replaced `.sr-only` with `.visually-hidden`. However, this does not work for the module menu as the menu entry names are hidden in expanded mode, thus making this a non-usable option. See: https://getbootstrap.com/docs/5.0/migration/#helpers and: https://getbootstrap.com/docs/5.0/helpers/visually-hidden/ This patch re-adds scss/css styling directly for the module menu without using the `@sr-only` or the new `.visually-hidden` definition from bootstrap to restore the module menu collapse behaviour. Used commands: > Build/Scripts/runTests.sh -s clean > Build/Scripts/runTests.sh -s buildCss Resolves: #98138 Related: #98089 Releases: main Change-Id: I200e9a5324be93fdc5119c956cfe432a1ecbc81d Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75436 Tested-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Tested-by:
core-ci <typo3@b13.com> Tested-by:
Simon Schaufelberger <simonschaufi+typo3@gmail.com> Tested-by:
Stefan Bürk <stefan@buerk.tech> Reviewed-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Reviewed-by:
Simon Schaufelberger <simonschaufi+typo3@gmail.com> Reviewed-by:
Stefan Bürk <stefan@buerk.tech>
-
- Aug 13, 2022
-
-
Benni Mack authored
This change removes the support for supporting concatenation and compression of CSS + JS assets in TYPO3 Backend. This feature was actually introduced back in TYPO3 v4.x because of limitations of Internet Explorer (max of 31 CSS files per HTML page), and before the introduction of bundlers + compressors for TYPO3 Core, as well as HTTP/2 support and optimized caching. For this reason, all the functionality within PageRenderer and ResourceCompressor is removed in TYPO3, without any option to activate this. TYPO3 already bundles CSS in one single file, and JS is nowadays loaded with bundlers, and loaders within JS modules in TYPO3 Backend. For TYPO3 Frontend, this functionality is still available for the time being. Resolves: #98100 Releases: main Change-Id: Id45714d4660080da6f4a1d9d6ae277930c0bbc48 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75389 Tested-by:
core-ci <typo3@b13.com> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
Stefan Bürk <stefan@buerk.tech> Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Jörg Bösche <typo3@joergboesche.de> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Stefan Bürk <stefan@buerk.tech> Reviewed-by:
Benni Mack <benni@typo3.org>
-
Nikita Hovratov authored
The former approach in #91808 to fix scoped toggling didn't work with levelLinksPosition "bottom", as the querySelector could find another control container inside another child inline field first. Another solution, which is now possible, works with the ":scope" selector. Only nodes with a direct parent will be found this way. In addition, a new helper class is added for the top control container, as it is wrapped in another div. This enables toggling of both buttons, in case levelLinksPosition "both" is set. Resolves: #97786 Related: #91808 Related: #92382 Releases: main, 11.5 Change-Id: I67146c372d183cd647db847b3e3d83d986585577 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/74928 Tested-by:
core-ci <typo3@b13.com> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
Stefan Bürk <stefan@buerk.tech> Tested-by:
Nikita Hovratov <nikita.h@live.de> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Stefan Bürk <stefan@buerk.tech> Reviewed-by:
Nikita Hovratov <nikita.h@live.de>
-
- Aug 12, 2022
-
-
Ionel-Alex Caizer authored
Omit obsolete type=text/javascript in PageRenderer See: https://html.spec.whatwg.org/multipage/scripting.html#the-script-element Resolves: #97990 Releases: main Change-Id: I4af66f10fd8186817fd66432d96b50de4cad0a5f Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75383 Tested-by:
Nikita Hovratov <nikita.h@live.de> Tested-by:
Stefan Bürk <stefan@buerk.tech> Tested-by:
core-ci <typo3@b13.com> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Nikita Hovratov <nikita.h@live.de> Reviewed-by:
Stefan Bürk <stefan@buerk.tech> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch>
-
Georg Ringer authored
Providing the exception message helps to understand and solve the issue as the exception can also be thrown by a 3rd party extension. Resolves: #97770 Releases: main, 11.5 Change-Id: I53ff25a141c3d3b522d5eabd270309dbdda7709f Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/74967 Tested-by:
core-ci <typo3@b13.com> Tested-by:
Simon Schaufelberger <simonschaufi+typo3@gmail.com> Tested-by:
Felix P. <f.pachowsky@neusta.de> Tested-by:
Stefan Froemken <froemken@gmail.com> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
Stefan Bürk <stefan@buerk.tech> Reviewed-by:
Simon Schaufelberger <simonschaufi+typo3@gmail.com> Reviewed-by:
Jörg Bösche <typo3@joergboesche.de> Reviewed-by:
Oliver Klee <typo3-coding@oliverklee.de> Reviewed-by:
Felix P. <f.pachowsky@neusta.de> Reviewed-by:
Stefan Froemken <froemken@gmail.com> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Stefan Bürk <stefan@buerk.tech>
-
Annett Jähnichen authored
Back in the old and dark days, some filesystems did not know about "special" chars. TYPO3 has the TYPO3_CONF_VARS toggle ['SYS']['UTF8filesystem'] to declare if filesytems are UTF-8 aware. This toggle is 'false' by default since ever. It triggers functionality to rename any file that contains characters like umlauts, or maybe entirely consist of "special" chars only (japanese) to something "safe". This is a usability issue since information is lost and language-specific characters are destroyed. Nowadays, any serious filesystem of course supports UTF-8. There are no issues related to UTF8filesystem=true for years. The patch now sets UTF8filesystem=true for new installations to see if anything still pops up. If that works out, we'll continue with further patches in v13 to further phase out the option entirely. Resolves: #98090 Releases: main Change-Id: Ib448d4f42c23605fd4343bcbbd1f9fdadecadc8b Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75378 Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
Simon Schaufelberger <simonschaufi+typo3@gmail.com> Tested-by:
core-ci <typo3@b13.com> Tested-by:
Stefan Bürk <stefan@buerk.tech> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Simon Schaufelberger <simonschaufi+typo3@gmail.com> Reviewed-by:
Stefan Bürk <stefan@buerk.tech>
-
Michael Hitzler authored
The YouTube helper tries to fetch from highest to lowest image for possible previews. The "sd" and "hq" versions were missing while checking for an available image and got added. Resolves: #98098 Releases: main, 11.5 Change-Id: Idec13fdc5c820e6674f8ccebd610455b50d57895 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75388 Tested-by:
core-ci <typo3@b13.com> Tested-by:
Simon Schaufelberger <simonschaufi+typo3@gmail.com> Tested-by:
Albrecht Köhnlein <ak@koehnlein.eu> Tested-by:
Stefan Bürk <stefan@buerk.tech> Tested-by:
Nikita Hovratov <nikita.h@live.de> Reviewed-by:
Simon Schaufelberger <simonschaufi+typo3@gmail.com> Reviewed-by:
Albrecht Köhnlein <ak@koehnlein.eu> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Stefan Bürk <stefan@buerk.tech> Reviewed-by:
Nikita Hovratov <nikita.h@live.de>
-
Helmut Hummel authored
When using the custom element <typo3-backend-icon> with a JS framework, that renders the DOM (e.g. Vue), it can happen, that they set the properties of the custom element instead of an attribute. Since Lit does not reflect these properties to attributes by default, but the icon-element relies on CSS set on the host element that depends on the size attribute, the icon is not rendered in the correct size. See: https://web.dev/custom-elements-best-practices/ on why reflecting properties to attributes might be a good idea in some cases. Releases: main, 11.5 Resolves: #98121 Change-Id: I8435946ad6e6d92b8ec50dd7e289279261d43d5a Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75414 Tested-by:
Benjamin Franzke <bfr@qbus.de> Tested-by:
core-ci <typo3@b13.com> Tested-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
Stefan Bürk <stefan@buerk.tech> Reviewed-by:
Benjamin Franzke <bfr@qbus.de> Reviewed-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Stefan Bürk <stefan@buerk.tech>
-
Andreas Fernandez authored
The icon identified by `warning-in-use` is rendered when a record is currently edited by another backend user. As one of the last remaining bitmap icons, this should be replaced with an overlay from `@typo3/icons` instead. Resolves: #98128 Releases: main Change-Id: Ifb9a37b835a97bccc7dfcc34a278d3c73e563817 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75424 Tested-by:
core-ci <typo3@b13.com> Tested-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
Stefan Bürk <stefan@buerk.tech> Reviewed-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Stefan Bürk <stefan@buerk.tech>
-
Andreas Fernandez authored
Until now, icon deprecation wasn't possible for extensions as the deprecation handling is internal to the IconRegistry. A new option `deprecated` is introduced that may contain the following data: * `since` - since when is the icon deprecated * `until` - when will the icon be removed * `replacement` - if given, an alternative icon is offered Resolves: #98130 Releases: main Change-Id: Ie95875a1d3b7de444acbd3b30e7b399b4b4f7563 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75425 Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Tested-by:
Stefan Bürk <stefan@buerk.tech> Tested-by:
core-ci <typo3@b13.com> Tested-by:
Nikita Hovratov <nikita.h@live.de> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Reviewed-by:
Stefan Bürk <stefan@buerk.tech> Reviewed-by:
Nikita Hovratov <nikita.h@live.de>
-
Larry Garfield authored
The Serializable interface has been deprecated, and is slated for removal entirely in PHP 9. The preferred serialization tool is the __serialize/__unserialize method pair, which is already implemented and used instead of Serializable. This patch removes the already-deprecated and vestigial Serializable interface. Serializable and __serialize() use a different string format, so the fixture file needed to be updated as well. Resolves: #98032 Releases: main Change-Id: Icd021d7d48252d2955491a97201547f42e4d20e9 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75306 Tested-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
core-ci <typo3@b13.com> Tested-by:
Stefan Bürk <stefan@buerk.tech> Reviewed-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Nikita Hovratov <nikita.h@live.de> Reviewed-by:
Stefan Bürk <stefan@buerk.tech>
-
Stefan Bürk authored
This patch shifts some functional test executions in CI workflows to PHP8.2. Thus enabling test coverage for new PHP8.2 version in a early stage. For nightly we only can active it for `locked` runs, as prophecy/prophecy is not allowed to be installed with PHP8.2 currently. See: https://github.com/phpspec/prophecy/issues/556 Backport to 11.5 is skipped for now due some issues in "doctrine/dbal 2.x" with PHP8.2. Resolves: #98109 Releases: main Change-Id: I02c4dc4bd3cdd589330b038463ed58a384e3d70d Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75404 Tested-by:
core-ci <typo3@b13.com> Tested-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
Stefan Bürk <stefan@buerk.tech> Reviewed-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Stefan Bürk <stefan@buerk.tech>
-
Nikita Hovratov authored
node-sass respectively LibSass is deprecated as stated in https://www.npmjs.com/package/node-sass Since we use Bootstrap v5 since TYPO3 v11, which itself compiles with dart-sass, the native JavaScript based sass solution, we can finally also make the switch. This is also possible, as FontAwesome is now dropped from the core. The sass-migrator was used here to migrate the majority of division operators to math.div or inverse it to a multiplication. See: https://sass-lang.com/documentation/cli/migrator Used commands: > yarn remove node-sass > yarn add sass -D > sass-migrator division **/*.scss > Build/Scripts/runTests.sh -s buildCss Resolves: #97538 Releases: main Change-Id: I17557ed98d6d30421c05b4a7d934a83654606d4f Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75433 Tested-by:
core-ci <typo3@b13.com> Tested-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
Nikita Hovratov <nikita.h@live.de> Tested-by:
Stefan Bürk <stefan@buerk.tech> Reviewed-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Nikita Hovratov <nikita.h@live.de> Reviewed-by:
Stefan Bürk <stefan@buerk.tech>
-
Daniel authored
If a sys_file record is directly deleted from database, some undefined array index warnings are triggered if the file is assigned to another database record. Releases: main, 11.5 Resolves: #97987 Change-Id: I2ce115024e637cffacc512528e79b1bb4059f173 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75254 Reviewed-by:
Oliver Klee <typo3-coding@oliverklee.de> Reviewed-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
core-ci <typo3@b13.com> Tested-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch>
-