- Sep 01, 2023
-
-
Friedemann Altrock authored
Only add implicit default paths (Resources/Private/X) when they are not explicitly configured via TypoScript, as they may have been configured as an overwrite for another base path. Resolves: #81099 Releases: main, 12.4, 11.5 Change-Id: I0fe4cb690aa253d5d9941fcfbe0a9c9063298547 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80658 Reviewed-by:
Benjamin Franzke <ben@bnf.dev> Tested-by:
core-ci <typo3@b13.com> Tested-by:
Oliver Klee <typo3-coding@oliverklee.de> Reviewed-by:
Stefan Bürk <stefan@buerk.tech> Tested-by:
-
Christian Kuhn authored
We extracted all the single irre related test variants to dedicated fixture extensions in v12 already. The remaining usages of irre_tutorial just reset some TCA defaults. Those are now inlined to consuming tests, rendering this fixture extension obsolete. Resolves: #101825 Releases: main Change-Id: I8ce12525b203b0200d2c8f7884d0451261fd7973 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80820 Tested-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Reviewed-by:
-
Christian Kuhn authored
Avoiding this abstract streamlines various tests to do more things similar as other tests. This especially affects needed site setups, which is now done more often based on the SiteBasedTestTrait. There is also less class state in tests, making them more easy to understand and follow. Resolves: #101819 Releases: main Change-Id: I6ad889f14da9e1a4ffe80b447c821c348e6d4b90 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80815 Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
-
Christian Kuhn authored
We finally removed remaining usages with #101647 and can thus drop the info in about module. The domain is offline meanwhile, so we backport to v12 to avoid dead links in the backend. Resolves: #101823 Related: #101647 Releases: main, 12.4 Change-Id: Id925da8a2dc87ca840d65b750f5025ae00fee7f0 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80817 Tested-by:
-
Friedemann Altrock authored
Before this fix, only the first RTE processing configuration would be taken into account when deciding which tags to keep in an HTML snippet. RteHtmlParser is a DI service and as such is treated as a singleton. Using multiple RTE processing configurations with potentially different sets of allowed tags should work as expected. Resolves: #101190 Releases: main, 12.4, 11.5 Change-Id: Ib0227872b542f53b30a16494aa2f979b8f601e07 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80695 Reviewed-by:
-
- Aug 31, 2023
-
-
Christian Kuhn authored
Similar to `Configuration/page.tsconfig`, default User TSconfig is now loaded from extensions `Configuration/user.tsconfig` files. ExtensionManagementUtility::addUserTSConfig() is deprecated similar to the page TSconfig patch from #101799. Resolves: #101807 Related: #96614 Related: #101799 Releases: main Change-Id: I11cb1a05b8a582ca8f2937077fefa810e36b92d4 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80767 Reviewed-by:
Stephan Großberndt <stephan.grossberndt@typo3.org> Tested-by:
-
Stefan Bürk authored
FormEngine sends some information as payload with the suggest wizard ajax request to the `SuggestWizardController` as context. The controller loads the record based on the tableName and the uid to determine the recordType to read the correct TCA field configuration, respecting special overrides like `columnsOverrides`. If a new record is created, there is no record uid available and passed to the controller. Therefore, the recordType is not properly determined. That leads to wrong record suggestions, if for example the `allowed` record table is overriden for specific recordTypes. This change adds the recordTypeValue as additional html data attribute to the suggest search field, reads and sends it along with the context payload in the ajax request to the suggest wizard controller, which now uses the passed value while keeping the record retrievement as fallback for now. Suggest records are now directly searched correctly respecting the full TCA configuration for the type, even for new records. Additionally, uid is send as null instead of the string "NaN". Used command(s): > Build/Scripts/runTests.sh -s buildJavascript Resolves: #101796 Releases: main, 12.4, 11.5 Change-Id: I3b814d37b7d4d3e9674ad6f2af882520c4f91413 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80759 Reviewed-by:
Markus Hofmann <typo3@calien.de>
-
Christian Kuhn authored
To be an example of best practice, this patch changes all usages of "<INCLUDE_TYPOSCRIPT ..." to "@import". Tests are adapted as well, as long as they are not tailored to actually test INCLUDE_TYPOSCRIPT syntax. Resolves: #101813 Related: #97816 Releases: main, 12.4 Change-Id: I01c4eb19dfd0106c5577457cd0e1836865112d6a Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80794 Tested-by:
Oliver Hader <oliver.hader@typo3.org> Reviewed-by:
Thomas Hohn <tho@gyldendal.dk> Tested-by:
Garvin Hicking <gh@faktor-e.de>
-
Achim Fritz authored
BackendUtility has a couple of strtotime() calls that may end up as strtotime(null). This emits a PHP E_DEPRECATED error since PHP 8.1. Add a cast. Resolves: #101811 Resolves: #101805 Releases: main, 12.4, 11.5 Change-Id: I5cca1b2fd3bc0d6792f6d61a59bdbc5b4850d15d Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80793 Tested-by:
-
Oliver Hader authored
Resolves: #101808 Releases: main, 12.4 Change-Id: Iab938e0608a5547838d8b0cbc40c795e7653f929 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80770 Tested-by:
-
Andreas Fernandez authored
In its current implementation, the scheduler module renders all settings fields (aka "additional fields") at one and toggles their visibility depending of the selected scheduler task that is about to get created. When submitting the form, the field are now properly disabled to prevent their submission, instead of moving the fields out of the form in a `submit` event handler. Resolves: #101806 Releases: main Change-Id: I8428aa6d60b365348310d35de6303e4f9d4c77a0 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80769 Tested-by:
-
Andreas Fernandez authored
When TYPO3 is installed via CLI, the setup command now asks for the webserver being used to be able to copy necessary webserver files, e.g. `.htaccess` for Apache or `web.config` for IIS. Resolves: #100719 Releases: main, 12.4 Change-Id: Ibb97c4cf92b29ceeda85ae848ceeae16afb73359 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/78802 Reviewed-by:
Nikita Hovratov <nikita.h@live.de> Tested-by:
-
- Aug 30, 2023
-
-
Christian Kuhn authored
We can reduce class state by explicitely handing over runtime state to consuming methods in favor of parking them on $this. Resolves: #101804 Releases: main, 12.4 Change-Id: Ic33d619a189625fa9407a3ee36cddf76d0f14d32 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80763 Reviewed-by:
-
Benjamin Franzke authored
chosen-js is based on jQuery, while select-pure is based on lit and is therefore available as web components. This is a better fit for our current development model. Commands executed: npm remove chosen-js @types/chosen-js npm install --save select-pure grunt build Resolves: #101758 Releases: main Change-Id: I89c235f47f66fea43402c13bd5858c9a7f7b98e8 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80703 Tested-by:
-
Andreas Fernandez authored
FormEngine JavaScript now uses `requestSubmit()` to announce an actual data-changing submit action which allows binding to the `submit` event. Also, this allows some refactorings in the future. In the past, an artifical `dispatchSubmitEvent()` method was used to achieve the same, that is now removed. Resolves: #101794 Releases: main Change-Id: I60fcd19f946ff91da736ec2c74fdf41365429cee Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80754 Reviewed-by:
-
Christian Kuhn authored
Changing stages using the various buttons in workspace preview module fatals server side since the request is incomplete. This is mainly due to the weird ajax dispatching from class AjaxDispatcher to ActionHandler: This area needs a major overhaul. However, patch for issue #100577 already introduced a hack to hand the current request down. The patch re-uses this to fix the issue. Resolves: #101802 Related: #101781 Related: #96904 Related: #100577 Releases: main, 12.4 Change-Id: Ifacf653ed0409891469a168c7bc0c38eaacf183f Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80760 Tested-by:
-
Andreas Nedbal authored
Resolves: #101781 Releases: main Change-Id: I072c4ae70e08e5d0a6d94d5a3ea67a26394e88d4 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80738 Tested-by:
-
Christian Kuhn authored
ExtensionManagementUtility::addPageTSConfig() has been superseded in v12 with feature #96614 already, which allows autoloading Configuration/page.tsconfig files. To further reduce ExtensionManagementUtility, ext_localconf.php files and TYPO3_CONF_VARS, the old way is now marked as deprecated. The patch does that, documents the impact and refactors a couple of tests to deal with this as well. Resolves: #101799 Related: #96614 Releases: main Change-Id: I1e71ea2c9dbc2d305668036d92911a7704b29c4a Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80758 Reviewed-by:
-
Oliver Wand authored
Tables with TCA columns set to type="email" do not need an ext_tables.sql entry anymore. The core now creates this field automatically. This is one patch of more in this area: The v13 goal is to obsolete ext_tables.sql in most cases by creating default "business" fields of TCA tables automatically. The patch adds the main magic in class DefaultTcaSchema and removes own ext_tables.sql definitions having type=email. According tests sets are added and existing tests are hardened a bit towards more strict comparison. Resolves: #101654 Related: #101553 Releases: main Change-Id: I4060f7d8f3bab12f4272b5e9ebed9ac2d96b97a4 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80515 Reviewed-by:
Anja Leichsenring <aleichsenring@ab-softlab.de> Tested-by:
-
Benjamin Serfhos authored
See: https://github.com/ckeditor/ckeditor5/issues/14200#issuecomment-1625171318 This allows similar behaviour as CKEditor 4 with applying styles to block components as DocumentList is preferred over List. Resolves: #100348 Releases: main, 12.4 Change-Id: I155889e37ca1e63b27aed0d01dad2154da5bd37e Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/79701 Tested-by:
Riccardo De Contardi <erredeco@gmail.com> Reviewed-by:
Torben Hansen <derhansen@gmail.com> Reviewed-by:
Kub Zgi <jakzgi@wp.pl> Reviewed-by:
-
Oliver Hader authored
DataMapProcessor tries to access `$possibleChainedIds[0]` which might not be defined, since that array is the result of a previous `array_intersect` invokation, which keeps the array keys of the original input array. DataHandler tries to access `$this->copyMappingArray[$table][$uid]`, which might not be defined in case the previous copy command could not be executed (e.g. since the record was deleted already). Resolves: #101748 Releases: main, 12.4, 11.5 Change-Id: Ibcbc412c7df62ce17dfa2c0f6fc120ccebb953d8 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80666 Reviewed-by:
-
Christian Kuhn authored
Well, that functionality is hilarious: Sometimes, when the DataHandler updates or inserts database rows, it calls checkStoredRecord() which fetches the just written row to verify the row has actually been written correctly. * The implementation is inconsistent, DH does not do this for all update queries. * The default configuration is to fetch the row, but to *not* check the fields, rendering the entire thing useless, but still have the additional query. * *If* DH would actually find some collision, it will bury that information as entry in sys_log. * We fiddled with this in #79438 for v8 already to allow suppressing overhead via TYPO3_CONF_VARS. These toggles are widely unknown and most likely used very seldom. * Inserting invalid data a DB can not persist most likely raises doctrine exceptions, especially with many database instances being configured in "strict" mode nowadays. * With our current efforts to configure database columns automatically by auto-creating them from TCA, we further reduce the risk of columns not being configured correctly for given data. The patch: * Removes (@internal) DataHandler->checkStoredRecord() * Keeps two related DataHandler properties as b/w compat layer, but renders them unused. * Removes two related TYPO3_CONF_VARS. Resolves: #101793 Related: #79438 Related: #101553 Releases: main Change-Id: Ie93eddda48057b844067b654e327b8a371b197fc Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80752 Tested-by:
-
Robert Kärner authored
This patch fixes two issues when generating symlinks to the public extension resources (Public/Resources) into the _assets folder during Composer installation. First, directory symlinks can't be created the same way on Windows as on Unix platforms. The creation requires elevated rights, and the required command is named differently as well. Junctions should be used on Windows instead, because they do not need elevated privileges to be created. When installing a TYPO3 extension via Composer, its Resources/Public folder is getting symlinked to the publicly accessible _assets folder. Until now, this process only used the Unix specific functions provided by Composer. It did not create any symlinks on Windows based installations, without generating any error message. This patch adds the same checks and platform-specific functions used by Composer when symlinking packages from a local path repository. The second issue that has been addressed is the naming of the symlinks themselves. When a Resources/Public directory is symlinked into the _assets folder, the symlink will be named using an md5 hash based on parts of the extension's installation path on the filesystem. During Composer installation, this relative path is derived from the absolute path provided by Composer. As Windows uses a different default path separator (backslash) compared to Unix (forward slash), the relative path will be different between both platforms, resulting in a different md5 hash being generated. Absolute path on Unix: /path/to/typo3/vendor/mycompany/myext Absolute path on Windows: C:\path\to\typo3\vendor/mycompany/myext Relative path to be used for the hash on Unix: /vendor/mycompany/myext Relative path to be used for the hash on Windows: \vendor/mycompany/myext If an uri into the _assets folder is to be generated in either frontend or backend, the md5 hash will be always be generated by using forward slashes, resulting in incorrect links on Windows installations. This difference has been solved by replacing all backslashes in the absolute extension installation path into forward slashes on Windows installations, so the symlink will be named correctly from the beginning. Resolves: #98434 Resolves: #98447 Releases: main, 12.4, 11.5 Change-Id: I221eb538312302a7af4f7c3010c9982922f1c6ce Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75867 Reviewed-by:
Nicole Cordes <typo3@cordes.co> Tested-by:
-
- Aug 29, 2023
-
-
Christian Kuhn authored
ext:core TsConfigTreeBuilder contains default User TSconfig of the adminpanel extension. This does not belong there. The patch extracts this as "defaultUserTSconfig" to ext:adminpanel. Resolves: #101791 Releases: main Change-Id: Ifeac81e33f612976cb98b4b721d403ff72702100 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80750 Reviewed-by:
-
Benjamin Franzke authored
@lezer/common – in contrast to other @lezer modules, is placed in dist/index.js instead of dist/index.es.js. Therefore we add a distinct copy rule. The sortablejs npm package recently changed to provide both, a UMD bundle and a native ESM module. As we actually failed to update the UMD bundle (due to a rename of the build output filename in sortablejs), we switch to the new ESM variant right away. muuri failed to update because dashboardToEs6 was missing in the npmcopy concurrent target. Resolves: #101784 Resolves: #101785 Resolves: #101787 Related: #101783 Releases: main, 12.4 Change-Id: I2ccf69847876edb55f089a4a5142ac388699fb54 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80741 Tested-by:
-
Nikita Hovratov authored
A small step towards streamlining Core code to use the recently introduced SelectItem API. Resolves: #101745 Releases: main Change-Id: Ib54abeee5b09b517e84baf7c7cb115bdb9a87295 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80665 Reviewed-by:
Georg Ringer <georg.ringer@gmail.com> Reviewed-by:
-
Benjamin Franzke authored
IDEs like PhpSstorm complain about the same thing, so better we have that defined and checked via CI. Commands executed: node_modules/.bin/eslint --fix Sources/TypeScript/ Resolves: #101780 Releases: main, 12.4 Change-Id: I01e0289b671dfd4348319bca90dddaec085fbfe4 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80736 Tested-by:
-
Benjamin Franzke authored
This helps to prevent hard-to-discover build failures, that only happen on clean installs (e.g. CI). This is because TypeScript will by default scan the entire source dictionary (Build/ in our case) for possible includes. We previously excluded /Build/composer in #95046, but it is actually much better to explicitly include the actually used source paths to also exclude build output (Build/JavaScript/) from being reinterpreted by subsequential eslint or tsc compile runs. Note that we also refactor the types/ directory in order to be a folder that conforms to the @types/* packages conventions, by being actually usable in the compilerOptions.types property. Note that our custom global type definitions (types/) were previously implicitly loaded as globally available sourcepaths. With the new `include` option we could add them back, but then we wouldn't notice if we do not add proper index.d.ts files (like we did until now). Therefore index.d.ts files are added in here. Now, with TypeScript being "clean", we need a another small adjustment in order for eslint to still being able to lint our types/ folder. Therefore tsconfig.json is extended to include the types directory. See [1] for more information on why eslint needs that. [1] https://typescript-eslint.io/linting/troubleshooting/#i-get-errors-telling-me-eslint-was-configured-to-run--however-that-tsconfig-does-not--none-of-those-tsconfigs-include-this-file Resolves: #101782 Related: #95046 Releases: main, 12.4 Change-Id: I3ab8b874192d25470bbd5e71cc5d99e853259f89 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80739 Tested-by:
-
Benjamin Franzke authored
This allows to drop a npm patch that had been applied to the TypeScript @types/jquery before, in order to achieve the same effect. With eslint we can additionally provide a good hint for the developer, what to use instead. Commands executed: npm remove patch-package npm install Resolves: #101697 Releases: main, 12.4 Change-Id: I77e15a4b4c2a18f8b72ec2a5f41c7e54a7966c30 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80562 Tested-by:
-
Benjamin Franzke authored
Remove unused files that have been forgotten to be removed when there respective TypeScript source files where removed. Resolves: #101786 Related: #101783 Releases: main, 12.4 Change-Id: I75a74996e9dc1f9f30fd3b2f08914e25452df06f Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80740 Tested-by:
-
Andreas Fernandez authored
The Install Tool router attempts to build URLs manually by wild string replacements and manipulation, which is rather error-prone. This patch changes the approach to use the URL API instead. Resolves: #101789 Releases: main, 12.4 Change-Id: I07ee73764b4fc5167f732d67faf2843fef0db199 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80742 Reviewed-by:
-
Benjamin Franzke authored
…of a new form element, that has not yet been persisted. Tabbing through an elemenet is considered an "input" by the browser, which is why the "input" even is triggered. The result is an empty input element (as before), but an intent is made to delete the underlying property from the form element object model. When the object model is empty (remeber, it is a new element), and an input field refers to a nested property (e.g. properties.fluidAdditionalAttributes.placeholder) removing an element (e.g. 'placeholder') will fail when the parent has not yet been set (e.g. properties.fluidAdditionalAttributes) Resolves: #101750 Releases: main, 12.4, 11.5 Change-Id: I49a9ead343e671c3d0289bd6d969316b888d05eb Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80671 Tested-by:
Benjamin Kott <benjamin.kott@outlook.com> Reviewed-by:
-
- Aug 28, 2023
-
-
Christian Kuhn authored
The extbase ConfigurationManager is (unfortunately) a stateful singleton that we can not get rid of without a bigger rewrite. While stateful singletons are bad enough, the extbase LocalizationUtility makes this worse by parking an instance of ConfigurationManager in a static property, re-using it as a "cached" singleton. LocalizationUtility does this since it in itself is static, which makes this service just so convenient to use. When it comes to sub requests and similar, static state is doomed and we need to get rid of it, we've had a couple of patches in v12 dealing with similar things. Mid-term, extbase LocalizationUtility needs to vanish anyways, but in the meantime, we have to get rid of static state that kills sub request scope. The patch removes the static $configurationManager property and adapts functional tests that already showed the current solution was a hack. There are various upper and lower cache layers that ensure removing this "cach...
-
Torben Hansen authored
With #90002, all occurrences of the `list()` function have been migrated to the short list syntax. Our php-cs-fixer configuration does however not check the short list syntax usage, so we have one usage of `list()` in our codebase again. This change extends the php-cs-fixer configuration to ensure, that only the short list syntax is used. The new ruleset has been applied to the codebase and one usage of the `list()` function has been migrated. Resolves: #101777 Related: #90002 Releases: main, 12.4 Signed-off-by:
-
Benjamin Franzke authored
Resolves: #101738 Related: #82577 Releases: main, 12.4 Change-Id: Id857430ae81322cf9197ba6df422780695f59f50 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80630 Tested-by:
-
Benjamin Franzke authored
Resolves: #101737 Related: #82577 Releases: main, 12.4 Change-Id: Ibc8ed8be6a8defc7dba4910e3f1df937809600aa Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80629 Tested-by:
-
Benjamin Franzke authored
Resolves: #101736 Related: #82577 Releases: main, 12.4 Change-Id: If77dc697ac23b5f1fb3f36dd15fe36cfb369700d Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80628 Reviewed-by:
-
Benjamin Franzke authored
Resolves: #101735 Related: #82577 Releases: main, 12.4 Change-Id: I5584528f69fddba7a5f7f4b3592ca4bf9e83938c Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80627 Tested-by:
-
Benjamin Franzke authored
Resolves: #101734 Related: #82577 Releases: main, 12.4 Change-Id: I0619297a3fbf3e2fd18b1aef1a0c82794a5ca714 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80626 Tested-by:
-
Benjamin Franzke authored
Resolves: #101733 Related: #82577 Releases: main, 12.4 Change-Id: I4d9f92287d9a2b69fa4421de2377f7bf9806147c Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80624 Tested-by:
-
