- Aug 24, 2022
-
-
Oliver Bartsch authored
InlineControlContainer allows to add custom controls via a userFunc (hook). However, since the resultArray was not passed to the userFunc, e.g. no JS module could be added for the custom control. This is now fixed by passing the resultArray by reference to the userFunc. Resolves: #98199 Releases: main, 11.5 Change-Id: I404d2673a65bb40cf7f389fb5c0f7bec7dcd7c4c Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75543 Tested-by:
core-ci <typo3@b13.com> Tested-by:
Benjamin Franzke <bfr@qbus.de> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
Oliver Bartsch <bo@cedev.de> Reviewed-by:
-
Tobias Jungmann authored
If a preview page is already open, clicking on the "view" button in the content editor window would not reload the page. That means, that the preview page would not show changes if the preview page url and the target url are similar (e.g. only differentiate in hash/query or are exactly the same). This patch looks if a window with the given windowName is already open (looking in `this.windows` did not work well because the existing windows aren't saved in a global context, yet) and compares the URL of an open window (if there's one) with the given URL. If the URLs are similiar (i.e. the origin and the path name are the same) the page will be reloaded. Resolves: #93706 Releases: main, 11.5 Change-Id: Ib3d9e49f56e6ef45df1cd7d82fa58dffb74a3750 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75164 Tested-by:
Stefan Bürk <stefan@buerk.tech> Reviewed-by:
-
Stefan Bürk authored
With #95819 the detection of Domain Object properties was changed to use ClassSchema in order to support uninitialized properties is models. This was not possible with `DomainObjectInterface::_getProperties()` which used `get_object_vars()` under the hood. However, with mentioned change, other properties which had been ignored by `get_object_vars()` were now propagated to persistence, even if those properties were not configured in TCA. The change in behavior is considered a regression and is now addressed: The retrieval of the property value is delayed until after it is ensured that the property is a persistable property (which asserts that we are not reading from private properties). Resolves: #98148 Related: #95819 Releases: main, 11.5 Change-Id: I94d41715a49953045d32361a00bc274c15112a1e Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75534 Reviewed-by:
theline <typo3@root-access.de> Reviewed-by:
Alexander Schnitzler <git@alexanderschnitzler.de> Reviewed-by:
Oliver Hader <oliver.hader@typo3.org> Reviewed-by:
-
Stefan Frömken authored
Releases: main Resolves: #98196 Change-Id: I55b2c082c96e580d345c32f04bc47d941e50425a Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75540 Tested-by:
Oliver Klee <typo3-coding@oliverklee.de> Tested-by:
-
Torben Hansen authored
The constant `TODAYS_SPECIAL` has never been used in TYPO3 core and also 3rd party extensions in TER do not make use of it. The constant can therefore be removed safely from the class. Resolves: #98195 Releases: main Change-Id: I187817b2641d97c48832e757ad0de710e49ce31f Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75538 Tested-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Tested-by:
-
- 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 `...
-
- 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:
-
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:
-
- 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:
Torben Hansen <derhansen@gmail.com> Tested-by:
Nikita Hovratov <nikita.h@live.de> Reviewed-by:
Thomas Löffler <loeffler@spooner-web.de> Reviewed-by:
-
- 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:
-
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:
-
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 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:
-
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:
-
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:
-
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:
-
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:
Frank Nägler <frank.naegler@typo3.com> Tested-by:
-
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:
-
- 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: -
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:
-
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:
Benni Mack <benni@typo3.org> Reviewed-by:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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:
Claus-Peter Eberwein <claus-peter.eberwein@b13.com> Tested-by:
-
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:
-
- 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:
Simon Schaufelberger <simonschaufi+typo3@gmail.com> Tested-by:
David Steeb <david.steeb@b13.com> Tested-by:
-
- 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:
waldhacker <hello@waldhacker.dev> Tested-by:
-
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:
-
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:
-
- 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:
Jörg Bösche <typo3@joergboesche.de> Reviewed-by:
-
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:
-
- 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:
-
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:
Felix P. <f.pachowsky@neusta.de> Tested-by:
Stefan Froemken <froemken@gmail.com> Tested-by:
-
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:
-
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:
Albrecht Köhnlein <ak@koehnlein.eu> Tested-by:
-
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:
Anja Leichsenring <aleichsenring@ab-softlab.de> Tested-by:
-
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:
-
