- May 30, 2021
-
-
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:
core-ci <typo3@b13.com> Tested-by:
Daniel Goerz <daniel.goerz@posteo.de> Tested-by:
Simon Gilli <typo3@gilbertsoft.org> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-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:
Oliver Klee <typo3-coding@oliverklee.de> Reviewed-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 <bo@cedev.de> 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:
Anja Leichsenring <aleichsenring@ab-softlab.de> 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:
Benni Mack <benni@typo3.org> 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:
Jochen <rothjochen@gmail.com> 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:
Richard Haeser <richard@richardhaeser.com> 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:
-
- May 26, 2021
-
-
Christian Eßl authored
The FileDumpController is extended for two new options: - `dl`: Force download of the file - `fn`: Use of an alternative filename To ease the use for extension authors, also a new view helper is introduced, which allows to create a link to a file (FAL), while using the new options. This effectively allows to easily create (download) links for non-public files within fluid. Resolves: #92518 Resolves: #67111 Releases: master Change-Id: Ic771c90e07b382e95f31945f58052739ae853d17 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66084 Tested-by:
-
Oliver Bartsch authored
With the bootstrap update in #93126 the data attribute name to set the modal content changed from `data-content` to `data-bs-content`. This patch now adjust all remaining places to display the action specific content, instead of the default "Are you sure?", again. Resolves: #94199 Releases: master Change-Id: I0ca3967dcd831ad31050e170b4d91ef93932cd27 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69267 Tested-by:
-
Benni Mack authored
The additional argument "relativeToCurrentScript" through out the File Abstraction Layer is a faulty conceptual implementation from back in the days. FAL can only build "relativeToCurrentScript" links for local drivers (and only in some cases). In addition, we've successfully migrated all logic in Frontend (Site Handling) and Backend (URL Routing since TYPO3 v11) to be able to handle absolute links, so this option should be marked as deprecated and never be used again, as it does not properly work if we want a true Abstraction Layer logic. Resolves: #94193 Releases: master Change-Id: Ib9ba752399bdc5b385804d580157d918fe90327c Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69173 Tested-by:
-
Oliver Bartsch authored
Since #94186, extbase controller actions are required to return a PSR-7 response interface. To ease the use for extension authors, the helper method `htmlResponse()` was added to the ActionController. If no data is provided, $this->view->render() is automatically used as response body. This is more or less the usual behaviour of most extbase actions and therefore also described in the corresponding RST. Since core code is often used as example for custom implementations, those places should follow the best practices, described in the RST. Therefore, this patch adjust all places in core, which call htmlResponse() and unnecessarily pass $this->view->render() as data. Resolves: #94186 Releases: master Change-Id: Id6ac4f92cc9b6fdb70150a2de4ea5a6877a9a55f Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69229 Tested-by:
Benjamin Franzke <bfr@qbus.de> Reviewed-by:
-
Richard Haeser authored
With the introduction of the new backend module web component router, the title of the backend windows will be set to the title of the main iframe. Most of the modules didn't provide a proper name though. For most modules we have a proper name now which will show up in the title of the backend window, if no title is propagated by the module, the backend router will fallback to the default backend title. As the format of the title is quite "personal". If you are used to have opened more TYPO3 backend windows, you would like to see which installation you have open. If you only work in one backend, you might want to see on which module you are currently working. It is possible to set the order of the title of the backend within your user settings now. By default it will be title - siteName [version] Resolves: #94182 Releases: master Change-Id: I02602650370140217aa252bbd8e29ea4e05d994a Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69172 Tested-by:
-
Jochen Roth authored
Remove groupData filemounts property because it causes GeneralUtility::intExplode to crash when $this->groupData['filemounts'] is defined as a empty array. Resolves: #93935 Releases: master Change-Id: Ia3879898c74bd94122bae08d21eabd396ce2a46a Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/68795 Tested-by:
-
Oliver Hader authored
Several JavaScript code smells are cleaned up and duplicate/superfluous parts removed. Resolves: #94164 Releases: master, 10.4 Change-Id: I4518a40d64005dad53c91dd1df8951255452abfc Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69187 Tested-by:
-
- May 25, 2021
-
-
Helmut Hummel authored
This change removes and modifies a few places within PackageManager code which was built before composer files contained the extension-key information, and before Composer Mode installations used the subtree split packages for core (TYPO3 v8). The change does the following: * Removes a fallback for the "cms" package requirement * Prefers extra.typo3/cms.extension-key of composer.json over the folder name for extension key * Removes lowercasing Composer names, since Composer enforces this now * Gracefully allow packages without ext_emconf.php to exist (will become relevant with following changes) * Ignore composer.json requires and suggests, when ext_emconf.php exists Releases: master Resolves: #94170 Change-Id: I92c3244245f8680947a8e109b489af848a04b800 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69183 Tested-by:
-
Larry Garfield authored
Resolves: #94189 Releases: master, 10.4 Change-Id: Idd70dda6b26c4e6462b351d61ac03e76b7fd9533 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69256 Tested-by:
-
Benni Mack authored
The database table sys_language has become obsolete with the introduction of site handling and site languages. Since language configuration is not content, it does not have to be included system-wide in the database. Therefore the table is now marked as deprecated and not referenced in the Core anymore. This means, that this patch removes any direct usages of sys_language in the core, except the site configuration module, as this requires an overall rework of how site languages can be created and pre-filled in the GUI and is therefore handled in a separate patch. This also enables us to possibly use locales (and unify the typo3 languages to locales) for content in the future. Resolves: #94165 Releases: master Change-Id: I8612c9f8df1b90201fc4315307a405f963325d82 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/68468 Tested-by:
-
