- Aug 24, 2024
-
-
Jasmina Ließmann authored
Resolves: #104666 Releases: main Change-Id: I4bcd8cfd82c9aa4837c2eb9e683d9626180077da Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85682 Tested-by:
Andreas Nedbal <andy@pixelde.su> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Jasmina Ließmann <minapokhalo+typo3@gmail.com> Reviewed-by:
core-ci <typo3@b13.com> Tested-by:
-
- Aug 23, 2024
-
-
Andreas Kienast authored
TYPO3 still uses the infamous position maps (lists with arrow icons) to allow an user to re-arrange content elements. The position maps are used in two places: * "New Page Content" wizard in record list * "Re-position content element" in record list This commit aims to improve the styling of position maps and streamline them with the page module, without the need of major refactorings. Theoretically, TYPO3 has API to render a "page module"-alike grid anywhere, but it is currently coupled too tight to page module behavior and its needs. Resolves: #104618 Releases: main Change-Id: I6aa25e60e8ae95a88f6e73a86a910442bda722f8 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85624 Reviewed-by:
Simon Schaufelberger <simonschaufi+typo3@gmail.com> Tested-by:
Andreas Kienast <a.fernandez@scripting-base.de> Reviewed-by:
Ayke Halder <mail@ayke-halder.de> Tested-by:
-
Benni Mack authored
With #104309 in place, TYPO3 is finally prepared to allow any date configuration, as long it is supported in PHP. This commit adjusts the last missing bits: the date format configured in `TYPO3_CONF_VARS/SYS/ddmmyy` is now respected at every place that configures a date time format for the JavaScript date picker component. To achieve this, an internal method is introduced that converts the PHP date format to a fomat that luxon understands, which appears to be "inspired" by ICU date format tokens. Resolves: #104192 Related: #103496 Related: #104309 Releases: main, 12.4 Change-Id: Ie5a103dc2bf455ec29616f6ae4b0a06063cc6937 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/84880 Reviewed-by:
Benjamin Franzke <ben@bnf.dev> Reviewed-by:
-
Andreas Kienast authored
This commit updates `luxon` to version 3.5.0, along with the related development package `@types/luxon`. Executed commands: npm install --save-dev @types/luxon@^3.4.2 npm install --save luxon@^3.5.0 npm run build Resolves: #104701 Releases: main, 12.4 Change-Id: Ia11a6d017fae9a91541923cc62198c9b20312dd2 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85729 Reviewed-by: -
Andreas Kienast authored
The Install Tool sections "Remove Temporary Assets" and "Clear Persistent Database Tables" have been re-structured a bit to have a cleaner look. Resolves: #104704 Releases: main Change-Id: I12b85b072e8b0675acbe624d1a036d12f0d061bf Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85709 Tested-by:
Garvin Hicking <gh@faktor-e.de> Tested-by:
-
Garvin Hicking authored
With #101128 a few more RTE plugins for CKEditor have been added, now supporting the "mark" HTML tag. This tag is now also allowed in the default parseFunc_RTE definitions for EXT:fluid_styled_content and the RteHtmlParser default. Also the missing "s" tag was treated similarly. Please note that custom sitepackages or themes like the Bootstrap package may need adoption like the following, if `denyTags` might otherwise remove the definition: lib.parseFunc_RTE { allowTags := addToList(mark,s) } The HTML frontend styling of the `<mark>` classes needs to be done by integrators, no CSS definitions are provided by default. Resolves: #104617 Related: #101128 Releases: main, 12.4 Change-Id: I9118274e9908dcb3fef44ec271973dde46a6d01c Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85639 Tested-by:Stefan Bürk <stefan@buerk.tech> Tested-by:
-
Christian Kuhn authored
There is little reason to use ext:fluid TemplateView instead of fluid standalone TemplateView in functional tests. ext:fluid TemplateView is about to be phased out. The test switches existing test usages to use fluid standalone TemplateView. Resolves: #104711 Related: #104708 Related: #104710 Releases: main Change-Id: Ie50c908b4b69cbd691cd7957fc0793d1ddaa9050 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85741 Reviewed-by:
Simon Praetorius <simon@praetorius.me> Reviewed-by:
-
Christian Kuhn authored
`EscapeChildrenRenderingTest` and `EscapeChildrenRenderingStandaloneTest` are identical, except that the 'standalone' variant does not actively use StandaloneView, but fluid standalone TemplateView, and the other one use ext:fluid TemplateView, which is identical in this use case. Combine the tests and let it work on fluid standalone TemplateView only. Resolves: #104710 Releases: main Change-Id: I71e9f8438dc016a55e1cb99c268b69c5bcebc791 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85740 Tested-by:
-
Simon Praetorius authored
FluidViewAdapter->setRenderingContext() sets itself as view for inner renderings. This was thought to be a good solution to trigger deprecations for methods of different view implementions (StandaloneView & friends). However, custom fluid views are being phased out, which will then trigger their own deprecations. We can thus remove this quirk. Also, renderPartial() and renderSection() may return mixed. This was wrong in fluid standalone as well, and is fixed in there, too. Resolves: #104709 Related: #101559 Releases: main Change-Id: I381e6a26ce8b6757fc59068742cf6a09d64f8f71 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85738 Tested-by:
-
- Aug 22, 2024
-
-
Christian Kuhn authored
We're starting with patches to phase out ext:fluid StandaloneView to introduce a general core view factory. A straight preparation is to reduce StandaloneView usages in functional fluid view helper tests with the native fluid standalone TemplateView as is used in most other functional view helper tests already. Resolves: #104708 Releases: main Change-Id: I6361f901af5372ee76cf948c3725a297aadc261b Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85739 Tested-by:
-
Ayke Halder authored
The FileClipboardCest waits for a button to become 'enabled' before clicking it. Disabled buttons use `class="disabled"` with CSS `pointer-events: none`. This might not be handled properly by `$I->waitForElementClickable()`. Resolves: #104702 Related: #104585 Releases: main, 12.4, 11.5 Change-Id: If0677eb445207612f43b624c2889d7ef6651ae71 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85732 Tested-by:
-
Andreas Kienast authored
This commit updates `lit` to version 3.2, along with some friend libraries. Executed commands: npm install --save \ @lit/task@^1.0.1 \ lit@^3.2.0 \ lit-element@^4.1.0 \ lit-html@^3.2.0 npm run build Resolves: #104700 Releases: main, 12.4 Change-Id: Ic0e37dc306955be8f4b495838c30c1440fe207fd Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85728 Tested-by: -
Benjamin Kott authored
Resolves: #104698 Releases: main Change-Id: I62cf1f89cd980cb453b990435223a45a90b1e0df Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85726 Reviewed-by:
-
Benjamin Kott authored
Resolves: #104523 Releases: main Change-Id: Ia331af805a4837f227289319b44f4f911463299a Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85724 Tested-by:
-
Benjamin Kott authored
Resolves: #104696 Releases: main Change-Id: If3de4c3aa0bed97ad7cb5886ca9b464cb077f720 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85723 Tested-by:
-
Andreas Kienast authored
Previously, the content of the table header in the backend user/group comparison view was misaligned, the title was moved below the action buttons. This commit changes the alignment to have the title and the action buttons next to each other. Additionally, the items are vertically centered. Resolves: #104691 Related: #104635 Releases: main Change-Id: I577ee142ab6efade51810b3f72d1b2ae8d346a97 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85720 Reviewed-by:
Benjamin Kott <benjamin.kott@outlook.com> Reviewed-by:
-
Benjamin Kott authored
We are dropping the Bootstrap CSS definitions for all table to have more control about the styling of the table elements. From now on we are shipping custom css adapted to our needs. The new table element styling is context aware and adapts to light and dark color schemes. Resolves: #104688 Releases: main Change-Id: I9e74a98d575460c00fd55045f990e32a134658d4 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85717 Tested-by:
-
Christian Kuhn authored
fix() is annotated to return an array of FlashMessages, the test setup returns an array of strings instead. Adapt the tests. Resolves: #104689 Releases: main Change-Id: I352d111e76e782ca4a6f05a6025d054343f11c8c Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85718 Reviewed-by:
Thomas Hohn <tho@gyldendal.dk> Reviewed-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Tested-by:
-
Andreas Kienast authored
The Install Tool templates now incorporate `<template>` tags that replace the previously used hidden `<div>` elements that served the same purpose: have re-usable templates. Using `<template>` allows us to remove some more quirks in the code, e.g. removing the template identifier classes (which wasn't done everywhere) and the requirement for valid markup within the templates, as `<template>.content` resolves to a `DocumentFragment` in JavaScript. Resolves: #104678 Releases: main Change-Id: Id35bc52c7a317402b1ad52a7ed64675b50e748a4 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85707 Tested-by:
-
Andreas Kienast authored
In early development, the max value of a progress bar was limited to being `100`, which changed later on. This was not respected when clamping the actual value, the value was limited to being `100`. This commit fixes the issue by taking the actual `max` value into account. Resolves: #104685 Releases: main Change-Id: I20ebeb217990ed59eada397d312ceb1d937a3296 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85713 Reviewed-by:
-
- Aug 21, 2024
-
-
Karsten Nowak authored
Fix not cklickable `+` sign for the nested properties in debugger tree in frontend. The css selector for input fields of type checkbox are not strong enough if the website css defines own css rules and select checkboxes with input[type="checkbox"] the selector in DebuggerUtility loses and properties are overriden. Height, width, z-index and other properties were used to hide the default appearance of checkboxes and make those form elements looking nice. Therefore, DebuggerUtilitys selector should be a bit more stronger. Resolves: #104681 Releases: main, 12.4 Change-Id: Id6964e0dbf19b83318f1e5de5f3763c6be6652a0 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85710 Tested-by:
-
Oliver Bartsch authored
Renaming resources via the ResourceController, called via AJAX, does now also properly log the performed action to be consistent with the use of the ExtendedFileUtiltiy. Resolves: #104569 Releases: main, 12.4 Change-Id: Icc2a5effcfa06269c2ad2f96cfa844206232ac60 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85696 Tested-by:
-
Christian Kuhn authored
ext:fluid RenderingContext is in the bad habit of extending fluid standalone RenderingContext with the two methods setRequest() and getRequest() that are not part of fluid standalone RenderingContextInterface. This is ugly with type hinting and can't be changed in a good way due to liskov collisions on method signatures in view helpers. Fluid standalone also does not want to add these methods itself since it - as a view - wants to avoid dependencies to PSR-7. Fluid standalone instead added setAttribute(), hasAttribute() and getAttribute() to RenderingContextInterface. This allows adding "arbitrary" objects. The patch makes use of this: On the setter side, the RenderingContextFactory->create() is extended to accept the request and set it as attribute, on the has/getter side all consumers are adapted. This deprecates setRequest() and getRequest(), which are changed to transparently work with the attribute instead. Resolves: #104684 Releases: main Change-Id: Id096073765c00e06e0437539f963f59a69e3fba0 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85708 Tested-by:
-
Christian Kuhn authored
Various ext:extbase functional tests set $GLOBALS['TYPO3_REQUEST']. The extbase codebase still has various places that access the global. We can still reduce some usages in tests which are obsolete meanwhile, or can be improved by setting the request on ConfigurationManager instead, which is one of the main callers to the $GLOBALS['TYPO3_REQUEST'] fallback in tests. Resolves: #104677 Related: #104675 Releases: main Change-Id: I8672cad869e64545c482664e5d995bc1ef02bd64 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85706 Tested-by:
Oliver Bartsch <bo@cedev.de> Reviewed-by:
-
Benjamin Kott authored
We are dropping the Bootstrap CSS definitions for all form stylings to have more control about the styling of the form elements. From now on we are shipping custom css adapted to our needs. The new form element styling is context aware and adapts to light and dark color schemes. Resolves: #104676 Releases: main Change-Id: I0da5017c961e9712c027f09a34f4cf91a7b11a45 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/83047 Tested-by:
-
- Aug 20, 2024
-
-
Oliver Bartsch authored
There might be the case that the same flag icon is used for different languages. Due to iconFactory using a cache for generated icons, record list needs to set the title explicitly to prevent using a wrong title on reusing the flag icons. Resolves: #104663 Releases: main, 12.4 Change-Id: I1eea6a608f1ce243cc0437de39c5b5ca323f2be1 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85693 Reviewed-by:
-
Christian Kuhn authored
Various ext:fluid functional tests set $GLOBALS['TYPO3_REQUEST']. There are three scenarious fixed with this change: * A VH uses ContentObjectRenderer that is fetched from request attribute 'currentContentObject'. If the request has not been set up correctly, it falls back to globals. Set those properly. * Setting $GLOBALS['TYPO3_REQUEST'] is not needed at all. * The VH triggers extbase request dependent ConfigurationManager, which is not set up properly. Set up those. Resolves: #104675 Releases: main Change-Id: I9155de89aa2799710f3453977473c58e8382fa7b Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85701 Reviewed-by:
-
Christian Kuhn authored
View helpers link.typolink and uri.typolink fail to set the given request on ContentObjectRenderer, so it falls back to $GLOBALS['TYPO3_REQUEST']. The patch sets the request (if given), and adapts the tests to rely on it, which avoid setting the global. Resolves: #104674 Releases: main Change-Id: Iac5d28eac3adce5632e70794f38956c244545509 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85702 Tested-by:
-
Christian Kuhn authored
Next change in the "Tame extbase ConfigurationManager" series. ext:form comes with an add-on class of extbase ConfigurationManager: It extends the class with an own feature to load the relevant YAML configuration from the extensions TypoScript. This is accompanied by an own interface. This is not a great idea from a structural point of view: The ext:form ConfigurationManager should be decoupled from extbase ConfigurationManager. It may decorate it, but should not extend it. Or - even better - not have a dependency to extbase ConfigurationManager at all, but get the required extbase ConfigurationManager state hand over. The latter option is preferred since extbase ConfigurationManager is this evil injectable stateful singleton, that hides required state away. Turning this around in ext:form forces consumers to hand over state directly, making the dependency to extbase ConfigurationManager state explicit in callers of ext:form ConfigurationManager. The patch does this: ext:form ConfigurationManager no longer extends extbase ConfigurationManager, but is turned into a standalone and stateless service with an own signature that actively receives needed state from consumers. Resolves: #104670 Related: #104514 Releases: main Change-Id: If6073eb50df788d45a7f4d73e95cbd2d54a8c5fe Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85638 Tested-by:
-
Oliver Bartsch authored
Resolves: #104639 Releases: main, 12.4, 11.5 Change-Id: I74a0cd9e856283d26a382582cc5d6b8e99887cd4 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85694 Tested-by:
Oliver Klee <typo3-coding@oliverklee.de>
-
Christian Kuhn authored
The FormPersistenceManager is a central class of ext:form that takes care of .form.yaml writing and loading. This includes overloading with form specific TypoScript settings and sanitation of storage locations based on module.tx_form TypoScript. Since ext:form is designed as an extbase extension, FormPersistenceManager relies on extbase ConfigurationManager to retrieve TypoScript. The ext:form internal own variant of extbase ConfigurationManager has this dependency as well. This wouldn't be a huge problem if FormPersistenceManager is only used from within the extbase bootstrapped extension context only. FormPersistenceManager however is used 'out-of-context' in three places: It is used within the BE FormEngine related flex form data structure handling hook, within the BE page module related content element preview rendering, and by the formvh:render view helper. These three places do not have an extbase context, so extbase, and especially the extbase related stateful injectable singleton ConfigurationManager, has not been configured at these points. Extbase ConfigurationManager, and in turn the ext:form extended variant as well, have a dependency to the request to work properly and thus rely on the request being set up correctly. To deal with this, FormPersistenceManager configures extbase ConfigurationManager within __construct() by handing over the request from $GLOBALS['TYPO3_REQUEST']. This is bad for a series of reasons, one being obviously the access to $GLOBALS['TYPO3_REQUEST'] within __construct() in the first place. Also, FormPersistenceManager is quite often used *within* properly configured extbase context as well, for instance from within the extbase based ext:form controllers, so FormPersistenceManager then reconfigures extbase ConfigurationManager with the (non-extbase) global request and thus messes up its state. The problem is here that FormPersistenceManager does not and can not know wether its used 'out-of-context'. To deal with this, the patch removes use of ConfigurationManager to retrieve TypoScript within FormPersistenceManager, and forces consumers to hand it over to those methods that need it. The idea is that only the callers know their context and can take care of setting up ConfigurationManager as needed on their own. This approach makes the dependency to the request object explicit: Two of the three 'out-of-context' places are "ok" with that: The BE page module preview rendering has the request available, the formvh:render view helper as well. The third one will be harder to resolve: The flex form related data structure handling has not been designed to have the request, there may or may not be CLI situations in this low level handling where no request is available. This needs further analysis, the patch outlines various options for now. The patch forces FormPersistenceManagerInterface to be adapted, which should not be a huge issue since the overall functionality is ext:form internal, and there shouldn't be extensions that use it directly. The patch is thus *not* considered breaking and FormPersistenceManagerInterface is now declared @internal along the way to reflect this. Also, as usual when working in this area, the related tests receive an overhaul to deal with the new signatures and internal handling, and to be more easy to maintain. Also, class ext:form ConfigurationService suffers from similar issues as outlined above and will probably need a revamp as well. This one however is only used in combination with FormPersistenceManager when used 'out-of-context', so the changes for FormPersistenceManager relax this situation as well. Still, and @todo is left in it. Resolves: #104667 Related: #92408 Related: #102558 Releases: main Change-Id: I555aa6445f1fad577253cf90065df540a5830bd7 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85669 Reviewed-by:
-
Daniel Siepmann authored
TCEforms were removed with #97126 in v12. Still there was a usage within EditPopup leading to an Exception when editing a record with FlexForm via edit form control. Resolves: #104658 Releases: main, 12.4 Change-Id: Ie7110367922a99ca088b416da4c11a025efcde00 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85676 Reviewed-by:
-
Oliver Bartsch authored
Resolves: #104665 Related: #103783 Releases: main Change-Id: I60bb7561f25a0c25068064890ee5deb474c183e4 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85681 Reviewed-by:
Jochen Roth <rothjochen@gmail.com> Reviewed-by:
-
Andreas Kienast authored
The date picker used in EXT:styleguide -> Components -> Form needs another format to be functional again. Resolves: #104660 Releases: main Change-Id: Iec506bbdbb68d3f41c6e9c0fb5701fc5ba0522d3 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85678 Tested-by:
-
- Aug 19, 2024
-
-
Lina Wolf authored
Documents https://review.typo3.org/c/Packages/TYPO3.CMS/+/85472 Resolves: #104647 Releases: main Change-Id: Ifb41959a20001664e39eadbd13d85cfbc153a783 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85663 Tested-by:
Chris Müller <typo3@brotkrueml.dev> Reviewed-by:
-
Oliver Hader authored
This change introduces the following enhancements: * `Map::keys(): array` resolves all keys of a map * `Map::values(): array` resolves all values of a map * `Map::assign(?Map): void` incorporates entries of other map Resolves: #104656 Releases: main, 12.4 Change-Id: Ifc358c83275128c52f8f195b06c1b36f54227f86 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85673 Reviewed-by:
Oliver Hader <oliver.hader@typo3.org> Tested-by:
-
- Aug 18, 2024
-
-
Jasmina Ließmann authored
The backend module "Backend Users" lists all backend users and backend user groups in the system. A detailed view can be called up for each backend user, which shows all compiled rights and settings for the backend user. This view has been revised to increase the UX and user-friendliness. The backend module also offers the option of comparing individual backend users or backend user groups with each other. These comparison views have also been slightly adjusted to improve clarity. Resolves: #104635 Releases: main Change-Id: I2f118ea49783e99c2b174dd33a7d58847338e183 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85543 Reviewed-by:
Guido Schmechel <guido.schmechel@brandung.de> Tested-by:
-
- Aug 17, 2024
-
-
Lina Wolf authored
As prepatch for https://forge.typo3.org/issues/104597 Only syntax changes and a changed headline. Layout will be addressed via https://github.com/TYPO3-Documentation/render-guides/issues/707. Resolves: #104644 Related: #104597 Releases: main, 12.4 Change-Id: Ibe9ee56d522c6eb1b337d38ed61bd004124fee6e Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85661 Tested-by:
-
Lina Wolf authored
References: https://github.com/TYPO3-Documentation/Changelog-To-Doc/issues/982 Releases: main Resolves: #104649 Related: #101391 Change-Id: I525d6fe5172b5bab110882140137601e7d508a83 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85665 Tested-by:
-
Lina Wolf authored
references: https://github.com/TYPO3-Documentation/Changelog-To-Doc/issues/982 Releases: main Resolves: #104648 Related: #101391 Change-Id: I6182144b7f18486813fc8236d58e0c53921cd6b9 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/85664 Reviewed-by:
-
