- Aug 30, 2023
-
-
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 <a.fernandez@scripting-base.de> Tested-by:
core-ci <typo3@b13.com> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Stefan B�rk <stefan@buerk.tech> 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 Klee <typo3-coding@oliverklee.de> Tested-by:
Garvin Hicking <gh@faktor-e.de>
-
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 <ben@bnf.dev> 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:
Nikita Hovratov <nikita.h@live.de> Tested-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 "cache layer" won't make things more expensive in practice, which allows us to remove this static state without further fallback. In main, this needs a TF update: > composer u typo3/testing-framework In 12.4, this need a TF raise: > composer req --dev typo3/testing-framework:^8.0.3 Resolves: #101779 Releases: main, 12.4 Change-Id: Ie5db07b0475f612a996d369ab3417672b33fbb2d Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80735 Reviewed-by:
Thomas Hohn <tho@gyldendal.dk> Reviewed-by:
-
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:
-
Benjamin Franzke authored
Resolves: #101717 Related: #82577 Releases: main, 12.4 Change-Id: I9e0a42954b387d34ded5ebd1bde533b9feb4e70e Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80602 Tested-by:
-
Benjamin Franzke authored
Resolves: #101713 Related: #82577 Releases: main, 12.4 Change-Id: Ic7b41b79552a4c14d7395609e0ac3dda9c47b20f Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80567 Tested-by:
-
Benjamin Franzke authored
Resolves: #101712 Related: #82577 Releases: main, 12.4 Change-Id: Id77b6cd93cff41c26220ca0b10b948813c1242be Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80598 Tested-by:
-
Benjamin Franzke authored
Resolves: #101702 Related: #82577 Releases: main, 12.4 Change-Id: I4ec165e645ee367d71404338e83ba6f40cb28494 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80505 Tested-by:
-
Benjamin Franzke authored
Resolves: #101634 Related: #82577 Releases: main, 12.4 Change-Id: Ia9ad4d39e925f671707ec62cd989bfca6dbf32ab Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80467 Tested-by:
Benni Mack <benni@typo3.org> Tested-by:
Andreas Nedbal <andy@pixelde.su> Reviewed-by:
Oliver Hader <oliver.hader@typo3.org> Reviewed-by:
-
Christian Kuhn authored
Use the new v12 EXTBASEPLUGIN in TS setup to streamline frontend functional tests a bit. Resolves: #101773 Related: #100293 Releases: main, 12.4 Change-Id: I84e3cc93f617e3d8feeb76e6acf2c02bc4070a6d Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80716 Tested-by:
Markus Klein <markus.klein@typo3.org> Tested-by:
-
Andreas Fernandez authored
When resetting the tag filter in "View Upgrade Documentation", the `hidden` class now gets removed, making previously filtered upgrade docs visible again. Resolves: #101771 Releases: main, 12.4 Change-Id: Ie8bc14cc20fed803ae9644308eeb7cf2daa15a09 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80713 Tested-by:
-
Achim Fritz authored
Resolves: #101754 Related: #100307 Releases: main, 12.4 Change-Id: I43c43f1635fd789e3f035e9840d37fb70528cb66 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80694 Reviewed-by:
Guido Schmechel <guido.schmechel@brandung.de> Reviewed-by:
-
Benjamin Kott authored
The `script` tag is defined to hold executable code or data and not template html markup. We are switching this to the `template` tag that is indended for this usecase. Resolves: #101769 Releases: main, 12.4 Change-Id: I0657e5cbce7e13770ce88918cb9e4137bf017590 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80711 Tested-by:
-
Benjamin Franzke authored
The ajax Icon API is currently not available during first install, therefore neither getIcon nor the icon web component may be used to render an icon. The icon markup is therefore now pre-rendered via fluid for both states and toggled via CSS. Resolves: #101765 Related: #98089 Releases: main, 12.4 Change-Id: Ib72c06e41f083e4dc7392845058fc86aae95af9c Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80705 Reviewed-by:
-
Benjamin Kott authored
The `retrieveYamlFilesFromExtensionFolders` function returned the full path to the form configuration as key and the filename as value. The filename used to `loadMetaData` that resulted in that the file could not be found because it expects to get the full path here. We are adapting retrieveYamlFilesFromExtensionFolders so we only work on the values returned from that array to avoid confusions or misshaps like this in the future. Resolves: #101767 Releases: main Change-Id: If1b58eae8da7fd5ac913a6a89cfd0aa889a200ef Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80709 Tested-by:
-
Oliver Klee authored
This fixes an issue in the acceptance tests where `null` is passed to `GeneralUtility::xml2array()` (which expects a `string`). Having an early check for an empty string also avoids pointless XML parsing (which should help performance a bit). Resolves: #101757 Releases: main, 12.4, 11.5 Change-Id: Ifc4406536c273baca9acdda7a0af7a91594f57bf Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80698 Reviewed-by:
-
Mathias Bolt Lesniak authored
The constructor of `\TYPO3\CMS\Core\Http\Request` now correctly accepts resources of the type "stream" as $body argument. Resolves: #101764 Related: #97620 Releases: main, 12.4 Change-Id: I2e7000c11ef4a16334f3305142ef8fb7fe6c639f Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80704 Tested-by:
-
