- May 31, 2021
-
-
Christian Kuhn authored
A minor raise from 2.6 to 2.7 brings an aria related feature and a cleanup we adapt in core. composer req typo3fluid/fluid:^2.7.0 Resolves: #94242 Releases: master Change-Id: I9b479c33aa5183ea2bad845452dfa8cba52245e6 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69334 Tested-by:
Oliver Bartsch <bo@cedev.de> Tested-by:
core-ci <typo3@b13.com> Tested-by:
Jochen <rothjochen@gmail.com> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Claus Due <claus@phpmind.net> Reviewed-by:
-
Oliver Bartsch authored
Classes and positioning of the recipients checkboxes in the EXT:workspaces "Send to stage" dialog are adjusted to be bootstrap 5 compatible, restoring proper space between checkbox and label. Resolves: #94241 Related: #93119 Releases: master Change-Id: If38f03f8c39c830ee5a1292667e8d942b446daff Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69335 Tested-by:
-
Nikita Hovratov authored
Allow overriding the scheme with forceAbsoluteUrl even if the page is not protected. Also the case is now covered where a scheme of a full URL with a path should be changed. The path in now correctly prepended by a slash. Resolves: #90228 Releases: master, 10.4 Change-Id: I37592838a2026ad0bed0386e44caa7ffac1fb65e Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/63252 Tested-by:
Benni Mack <benni@typo3.org> Tested-by:
Richard Haeser <richard@richardhaeser.com> Reviewed-by:
-
Oliver Bartsch authored
This adds the EXT:seo XML sitemap related constants to the constant editor. Resolves: #94239 Releases: master, 10.4 Change-Id: I8e8ca1d4272b7894e0539dc86953531f6b7fd1c0 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69332 Tested-by:
-
Thomas Löffler authored
Previously the image of a distribution extension was only shown in the extensionmanager, in case the distribution was already installed. In the list view, all distributions therefore displayed the same fallback image. This is now fixed by adding a new field to the extension record, which is filled via the XML parser. As it contains the URL to the image, it can be directly used in the corresponding templates and therefore allows to remove the DistributionImageViewHelper. Instead, a new web component handles the image and ensures a preview image is displayed, even if the distribution image is not available. Resolves: #83465 Releases: master Change-Id: Id249b99833571024e39ed3f5991751e24e2e8d1d Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69099 Tested-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Tested-by:
Thomas Löffler <loeffler@spooner-web.de> Reviewed-by:
-
- May 30, 2021
-
-
Christian Kuhn authored
ext:form is full of ObjectManager usages. This first patch tackles a series of simple cases: Mostly things we know can be created via makeInstance() easily or can be injected and that are easy to test since errors would lead to immediate BE module or FE plugin fatals. Some places benefit by switching to DI, and the patch does this in some cases. Some other parts are harder to switch, for instance because they'd require a bigger test rewrite, or raise b/w compat issues. Those places simply switch from ObjectManager->get() to makeInstance() for now. Change-Id: I400cf5c2e9b384d214ca0921c38c1c135df47cf7 Resolves: #94236 Related: #90803 Releases: master Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69326 Tested-by:
Simon Gilli <typo3@gilbertsoft.org> Tested-by:
Oliver Klee <typo3-coding@oliverklee.de> Reviewed-by:
-
Daniel Goerz authored
* EXT:dashboard * EXT:extbase * EXT:extensionmanager * EXT:filelist Resolves: #94124 Releases: master Change-Id: I57e3f0b390639d2160420e4dc26468c08c6341c9 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69320 Tested-by:
-
Christian Kuhn authored
The BaseViewHelper which renders a base tag is kinda useless in our scope: Fluid based rendering typically takes care of markup within body tag, but base must be in head. In frontend, a base tag is thus almost always set using TypoScript config.baseURL, ending up in PageRenderer. The backend does stuff like this on a different level, usually ending up in the PageRenderer as well. Even with HTML mails, a base tag is uncommon and would usually - at least in the frontend - again render via PageRenderer. The patch deprecates BaseViewHelper. Resolves: #94227 Releases: master Change-Id: I7029dd609ca1f0aa1057b67380c7bd3a46b7ed09 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69315 Tested-by:
-
Andreas Fernandez authored
The modal stack handling is slightly changed to update the instance stack when a modal was requested to get closed already and not once a modal has been destroyed anymore. This fixes an issue in case a closing modal triggers a new modal which resulted in the new modal being broken. Resolves: #94219 Releases: master, 10.4 Change-Id: Idbc16ac08e95d8b3fed896783672b58ff062cafe Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69305 Tested-by:
Markus Klein <markus.klein@typo3.org> Reviewed-by:
-
Christian Kuhn authored
Did you know there's supposed to be a context menu entry on pages in 'more' section that jumps to the edit access view of the permission module? No? Well, it's broken since the v8 context menu rewrite and never rendered due to insufficient initialization. forge doesn't have a single bug report about this, it seems nobody ever missed that entry. This is probably due to its limited use - the access module is used by admins rather seldom, as soon as the basic access rights system has been done for an instance and some pageTS settings take care of setting proper access for new pages, there is little need to fiddle with it often. And if it's used, it's accessed via the main module. Let's drop the implementation of the context menu entry instead of fixing it, to not bloat the 'more' section with an entry nobody missed. Resolves: #94237 Related: #78192 Releases: master Change-Id: I6c87ad8b9f4f2945b29b540e800811ab607bdadd Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69329 Tested-by:
-
Christian Kuhn authored
The next step towards a PSR-7 compatible request object in extbase is to get rid of getRequestUri() and setRequestUri(). The strategy is similar to getBaseUri() from issue #94223: The Internal method setRequestUri() is dropped and the unused getRequestUri() is deprecated. Resolves: #94228 Related: #94223 Releases: master Change-Id: I99f74ac989fd697404b63c90c3ee8843abb80626 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69316 Tested-by:
Daniel Goerz <daniel.goerz@posteo.de> Tested-by:
-
Torben Hansen authored
Change method name for doc header button registration to `registerDocHeaderButtons`, since it strictly follows the PSR-1 camelCase naming. Resolves: #94235 Releases: master Change-Id: Ib6bc5af33c11ec96db4aeb77364a2683f52bccf8 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69325 Tested-by:
-
- May 29, 2021
-
-
Christian Kuhn authored
makeInstance() can be used as straight substitution for now. Do this and clean up the test case a bit along the way. Resolves: #94233 Releases: master Change-Id: I1e802d405fd161501e10beea35848eebba397d83 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69323 Tested-by:
Torben Hansen <derhansen@gmail.com> Tested-by:
-
Christian Kuhn authored
ext:beuser BackendUserRepository extends ext:extbase BackendUserGroupRepository, which is of course bogus. It triggers an unneeded call of extbase BackendUserGroupRepository->initializeObject(), which explicitely sets respectStoragePage(false) on query settings. This is redundant since [ctrl][rootLevel] = 1 of the be_user table TCA triggers the same call via the DataMapper. Change-Id: Id809f83fae549e859a426a615c0865d84a5c7250 Resolves: #94229 Releases: master Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69317 Tested-by:
-
Oliver Bartsch authored
To further prepare towards a PSR-7 Request in extbase we have to get rid of the setMethod() method. Therefore, the internal method setMethod() is dropped, while the public getMethod() is adjusted to use the PSR-7 Request. Additionally, the now unused InvalidRequestMethodException is deprecated. Resolves: #94231 Related: #94231 Related: #94223 Releases: master Change-Id: I1298cd049cf6fc1d44cf46ec3cbb3bd588b3bb7a Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69319 Tested-by:
-
Christian Kuhn authored
Both settings are useless: * The storagePid = 0 setting is ignored for be_users and be_groups queries since the extbase DataMapper sets setRespectStoragePage(false) automatically because both tables have TCA ctrl rootLevel = 1. * The check for this funny 'dummy = foo' has been removed from the controller years ago. Change-Id: Ic5ee3207ae1a7bbe17de640e5dbe61a39492a844 Resolves: #94232 Releases: master Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69322 Tested-by:
Georg Ringer <georg.ringer@gmail.com> Tested-by:
-
Christian Kuhn authored
Extbase tends to become a victim of its own magic. In this case, whenever a repository method like initializeObject() uses setDefaultQuerySettings(), it fully overrides potentially useful settings created by the factory. Developers struggle here since all of a sudden things like storagePid restrictions from configuration are no longer applied. We can't change this behavior easily - it would require some awful dirty handling in QuerySettingsInterface, leading to even more opaque complexity in this area. The change adds comments to the property and the setter hinting about the behavior. Resolves: #89295 Releases: master, 10.4 Change-Id: I3b99dfa6d5a7881caaa952672386c00ebfa0166c Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69324 Tested-by:
Christian Wolff <chris@wolffc.de> Reviewed-by:
-
- May 28, 2021
-
-
Christian Kuhn authored
The fluid backend ContainerViewHelper is very similar to the PageRenderViewHelper, with the exception that container VH adds a default and empty ModuleTemplate leading to a default and thus pretty useless docheader. The main ModuleTemplate logic of backend modules should be done within controllers and resource registration like CSS can be done with PageRenderer VH. The patch deprecates the ContainerViewHelper. Resolves: #94225 Releases: master Change-Id: I69f06313f7ba1d647b702572e58eed1394dd1f2c Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69312 Tested-by:
-
Christian Kuhn authored
typo3/sysext/backend/Resources/Private/Templates/helper_javascript_css.html is an unused left over since FormEngine rewrite in v7 and can be dropped. Resolves: #94226 Releases: master Change-Id: Ic8eccade663e380c37f9abb045f14c3a5992adb4 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69313 Tested-by:
-
Christian Kuhn authored
To further prepare extbase towards a extbase Request object compatible with PSR-7 ServerRequestInterface, we need some solution for those methods within existing extbase Request that prevent immutability. One relatively straight case are setBaseUri() and getBaseUri(): The setter has been marked @internal in v10 already and can be dropped, and the getter is used just in a couple of cases. The patch adapts usages of getBaseUri() to implement the uri retrieval on their own based on the PSR-7 request (global access as temporary solution) and deprecates the method. The setter is dropped. Change-Id: Ifc224ecb8ab1a9d2b6f789fe8b92b692187614b7 Resolves: #94223 Releases: master Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69310 Tested-by:
-
Christian Kuhn authored
typo3/sysext/backend/Resources/Private/Templates/blank.html is unused since the removal of DocumentTemplate and can be dropped. Resolves: #94224 Related: #91514 Releases: master Change-Id: I3fd2e8f1eec25981f69fdcf26e7f8ac1932002d8 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69311 Tested-by:
-
Oliver Bartsch authored
Both, the recordlist as well as the backend user module already check the currently logged in user when evaluating the available record actions, e.g. disable or delete. Since disabling / deleting the currently logged in user will result in a completely broken state, which can only be fixed with direct database access, those checks are now also implemented in FormEngine and the ContextMenu. Furthermore, a new DisplayCond is added to hide the "disable" field in the current user record. Resolves: #94216 Releases: master, 10.4 Change-Id: Iebb7c5c685dc4c4aad489b73ee59fd9ac62cab4c Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69304 Tested-by:
-
Benni Mack authored
The Extbase action controller does not worry about clearing cache or changing plugins from USER to USER_INT as this is now handled within Extbase Bootstrap, reducing logic within Extbase controllers. Future iterations in this area then allow to a) have Extbase in BE not depend on an active cObject anymore b) have Extbase Bootstrap be sending headers to its parent object. Resolves: #94217 Releases: master Change-Id: Iff1608ecbc37ce7e6461f9e67c73d183354ebc4a Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69110 Tested-by:
-
Christian Kuhn authored
When dealing with TER extensions in the extension manager, the TER provides an XML file with extension details that are parsed and loaded into a database table. When this has been added a long time ago, two XML parsers have been added together with a factory to select one. Since PHP extension 'xml' is a required TYPO3 extension since a lot of core versions, always the first parser did the job. The patch removes the legacy parser and the factory, injects the parser via DI to the consuming class, merges the abstract parser class into the now single parser, moves the namespace, and refactors the class towards PHP strict typing. This leads to a significantly simplified codebase, much easier to maintain and adapt. Change-Id: I5f64370f943964686717dccb4e39cda1ae9511c9 Resolves: #94220 Releases: master Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69307 Tested-by:
-
- May 27, 2021
-
-
Volker Diels-Grabsch authored
For complex validators, it often makes sense that a custom validator can attribute an error to a specific property or sub property, even though it is validating a whole class. This is already possible by accessing a validator's $this->result directly, but that is cumbersome and in no way obvious, as this requires deep knowledge of the Result and Error classes. So this commit adds a convenience method addErrorForProperty() similar to addError() that takes a property path in addition to the error details. Resolves: #93835 Related: #93836 Releases: master Change-Id: I52f2b4cebaa8b4b4a91e47e983ce47533b63c6d5 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/68658 Tested-by:
-
Albrecht Koehnlein authored
If a canonical URL is set in the page properties, this will always be used before checking the other options for defining the canonical URL. Resolves: #94201 Releases: master Change-Id: I200a086952cd70d0659692f144b2fae93173a8f4 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69271 Tested-by:
Riny van Tiggelen <info@online-gamer.nl> Reviewed-by:
-
Christian Kuhn authored
A while after the PHP based ModuleTemplate API has been introduced back in 2015, a couple of fluid view helpers have been added to ext:backend as a second way to handle full backend module content like the doc header. It found an example use in ext:beuser. Development however stopped at this point, the provided view helpers are only a sub set of the PHP based API and they didn't find broader use within the core - all other backend modules stick to the ModuleTemplate based API. On a structural level, those view helpers are questionable: They move functionality to the view component which is arguably more a controller task. The ext:beuser module proofes this since it had to assign controller knowledge like the current action and controller name to the view in order to render the doc header module down and shortcut buttons. The patch drops usages of these view helpers in ext:beuser, plus the minor usages of the outer ModuleLayout view helper in ext:install and ext:belog, substitutes them with the PHP ModuleTemplate API within controllers, and deprecates the full set of ModuleLayout view helpers. The change sharpens our separation between controller and view: The "outer" module handling like doc header buttons and menus are tied to controller logic and should be located there, while the module body is rendered by a fluid view. As a bonus, a couple of issues within ext:beuser are fixed along the way, since they can now be easily solved and were rather hard to tackle with the view helper based approach: * The beuser module now remembers state and jumps to for instance the group sub module when a user selected this last. This is now in line with many other backend modules that do the same. * Shortcuts to single user details work. * The main doc header drop down can now contain all possible sub modules, including those that are available only indirectly, for instance the single user details view. This is good when calling these from shortcuts. Change-Id: Idef3aa6975e97677c1da0cef57f70c855bd2ea9f Resolves: #94209 Releases: master Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69269 Tested-by:
-
Jochen Roth authored
In order to ease usage, icon and text are now both linked in toolbar sections of open docs, user switch and bookmark dropdown, in contrast to only text before. Resolves: #94215 Releases: master Change-Id: I494d82e2f2cd90e904241c9c5a4c24aee9664bb1 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69302 Tested-by:
-
Oliver Bartsch authored
This patch adds a new field information which displays the actually used backend layout for the current page, in case the `backend_layout` field is empty and a parent page defines `backend_layout_next_level`. This will help editors to determine the actually used backend layout. This was previously often difficult. Especially in case multiple backend layouts used the same columns config, but differed in their frontend representation. Resolves: #94210 Releases: master Change-Id: I8ebe2182f8e943a76def233d3fe5f64f94ea79c8 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69298 Tested-by:
-
Andreas Fernandez authored
Calling `FormEngineValidation.validate()` on a passed section resets the overall validation state which may cause to mark fields as valid albeit they aren't. To solve this issue, the validation state is reset only in case no specific section was given. Resolves: #94110 Releases: master, 10.4 Change-Id: I7ed236c1e20fa2f1cdba07c58b64d943cf40700b Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69265 Tested-by:
-
Helmut Hummel authored
During refactoring of LateBootService (in install tool) to BootService (in core) a usage of LateBootService in extension manager was forgotten and is cleaned up now. Releases: master Resolves: #94213 Change-Id: I8c5013b0f51fd8a250a8a7b6b4eb9822ee536d9c Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69301 Tested-by:
-
Christian Kuhn authored
The method containing the call is unused and can be dropped. Change-Id: Ia4e233bd1d15b2bb2deb6f03a29e5ae873bb829b Resolves: #94211 Related: #90803 Releases: master Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69299 Tested-by:
-
Andreas Fernandez authored
Bootstraps modals are not designed to have multiple instances opened at once, which was workarounded in TYPO3 a while ago. If a modal overlays another modal AND is smaller, its backdrop does not overlay the "lower" modal due to hardcoded z-index values. With this patch the z-index of both, the modal and its backdrop are re-calculated depending on the amount of open modals. We use "1000" as an overall base to circumvent a stuttering UI as Bootstrap uses a z-index of "1040" for backdrops on initial rendering. However, this will clash again when at least four modals are open, which is fine and should never happen - if it does, it at least reveals a bad UX. Resolves: #94155 Releases: master Change-Id: Ia15d0cdba903d9ec6a9ebe8518b07daf5e52e59f Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69181 Tested-by:
-
Benni Mack authored
This change moves the detection of USER/USER_INT from the FrontendRequestHandler to Extbase Bootstrap->run(), allowing custom extbase request handlers to now be converted to USER_INT to run uncached. This further separates the TSFE/cObj logic from Extbase into the main entrypoint (Bootstrap), making Extbase less aware of cObjects and their internal cacheable logic. Resolves: #94132 Releases: master Change-Id: I76e4268df65897fc3b10e6c1828d34f465e435c6 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69136 Tested-by:
-
Oliver Bartsch authored
Resolves: #94212 Releases: master Change-Id: I785cc3d5a286274ad4b09d1de3fe55adced878c5 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69300 Tested-by:
-
Larry Garfield authored
Resolves: #94057 Releases: master Change-Id: I238a98d5161417465c02ae8683aef83f55a05ecc Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69255 Tested-by:
-
Jochen Roth authored
This aligns the height of the input field and the associated datepicker button in the edit task form of EXT:scheduler. Resolves: #94205 Releases: master Change-Id: I19f1d8fb6d5901b94a5d2a01bf532ac6ec7d22e6 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69295 Tested-by:
-
Oliver Bartsch authored
To prevent information disclosure, the password reset process does not reveal if an email was sent or not. The corresponding methods just return void. However, the ResetPasswordCommand always displayed a success message, which claims an email was sent, even though this was not the case. An example would be a password reset request which affects an admin user, while "passwordResetForAdmins" is disabled. In such cases, the message is highly misleading. To fix this, the message now only informs about the successfully initiated password reset process and not whether an email was sent or not. This is now consistent with the message in the backend user module. Resolves: #94200 Releases: master, 10.4 Change-Id: I99d33d0a55be48c7f5ee51e24fea3f85baf36b26 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69270 Tested-by:
-
Oliver Bartsch authored
Resolves: #94204 Related: #90803 Releases: master Change-Id: I3da93d84ddc9caa9922ac65c6f7a99acdede6606 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69294 Tested-by:
-
Oliver Bartsch authored
Since #93853, RequestBuilder->build() expects a PSR-7 Request to be passed. Because the FLUIDTEMPLATE content object was not adjusted accordingly, an exception is triggered as soon as extbase variables are defined for the content object. This is fixed by passing the current PSR-7 Request to the method. The PSR-7 Request is available in any content object since #92984. Resolves: #94203 Related: #93853 Releases: master Change-Id: Ife3b9a076757e4af8b384e49ab00c945411d47c6 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69293 Tested-by:
-
