- Aug 06, 2021
-
-
Christian Kuhn authored
typo3/testing-framework ships default .xml and bootstrap files for phpunit unit and functional tests. They are however quite hard to maintain since the testing-framework supports multiple core versions at once, but core occassionally needs version specific settings. The patch copies the files from the testing-framework to Build/phpunit and adapts core usages. The files within testing-framework will be kept, but will receive an additional "these are boilerplates, consider copying them to your extension" hint for extension developers. The local .xml files are now: * Compatible with phpunit 9 * Let tests fail if phpunit marks a test with warning. With this enabled, we would have seen the issues fixed with #94724 and #94723 with initial #94706 already. Good to do that now. Resolves: #94725 Related: #94706 Related: #94723 Related: #94724 Releases: master Change-Id: I9fef75a972759d26d4e0e3286142cacf181c33d2 Reviewed-on: https://review.typo3.org/c/Pack...
-
Christian Kuhn authored
The consuming test case has been dropped a while ago, fixture removal has been forgotten. Resolves: #94727 Releases: master Change-Id: I3ec574a3efd200c2572a5596ae6e97a03a5a0d49 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70242 Tested-by:
core-ci <typo3@b13.com> Tested-by:
Wouter Wolters <typo3@wouterwolters.nl> Tested-by:
Oliver Bartsch <bo@cedev.de> Reviewed-by:
-
Oliver Bartsch authored
BackendUtility::getRecordTitle() should return a string (as the return type annotation suggest). Especially because the return value is usually directly passed to htmlspecialchars(), which again requires a string to be given. Since BackendUtility::getRecordTitle() was missing some typecasts, it was possible that e.g. an integer was returned. This then failed in classes, defining strict mode. An example for such scenario: Having a table, which defines the `uid` as `label` field. getRecordTitle is using getProcessedValue(), which has a guard clause to directly return the input value, in case the label field is `uid`. This would then usually (depending on DBMS) return an integer. This is now fixed by applying type casts to the relevant places. Resolves: #94726 Releases: master Change-Id: Ie02837ff5e55f369ff8ddf1f3e5098e636f475bb Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70243 Tested-by:
Benni Mack <benni@typo3.org> Tested-by:
Jochen <rothjochen@gmail.com> Tested-by:
Jörg Bösche <typo3@joergboesche.de> Reviewed-by:
-
- Aug 05, 2021
-
-
Wouter Wolters authored
Rector is used to migrate functional tests to PHPunit v9. Resolves: #94724 Related: #94706 Releases: master Change-Id: I378acd4145aacb5448d461eec48c3a1695876d61 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70238 Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
-
Wouter Wolters authored
composer req --dev codeception/codeception:^4.1.21 composer req --dev codeception/module-webdriver:^1.2.1 composer req --dev php-webdriver/webdriver:^1.11.1 composer req --dev composer/package-versions-deprecated:^1.11.99.2 composer req --dev codeception/codeception:^4.1.21 -d typo3/sysext/core --no-update composer req --dev codeception/module-webdriver:^1.2.1 -d typo3/sysext/core --no-update composer req --dev php-webdriver/webdriver:^1.11.1 -d typo3/sysext/core --no-update composer req --dev composer/package-versions-deprecated:^1.11.99.2 -d typo3/sysext/core --no-update composer u mikey179/vfsstream behat/gherkin composer/semver codeception/stub Resolves: #94722 Releases: master Change-Id: I2ec0277374a2bf4e1501e79469826b7ea6360557 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70234 Tested-by:
-
Christian Kuhn authored
LocalConfiguration BE/explicitADmode controls wether field permissions for backend user groups are additive (explicitAllow) or subtractive (explicitDeny). By means of best practice in the IT world, user permissions should always be configured additive - which is called the "Principle of Least Privilege" (see https://en.wikipedia.org/wiki/Principle_of_least_privilege). TYPO3's permission system already uses PoLP in all cases of backend groups except for the permission system of "Allowed Content Types" This is not only important from a security point of view in terms of permissions (for instance when an extension adds new CTypes), it's also possible to easily create a hard to understand mess in explicitDeny mode with nested groups. The default / fallback in DefaultConfiguration however has always been explicitDeny since "ever". New instances always got explicitAllow due to it being set in FactoryConfiguration - since TYPO3 v6.2. We can expect the vast majority of instances to run with explicitAllow already, either since the instance is younger than ~7 years, or because an admin already did set the default to explicitAllow for any instance that works with a non-trivial backend user group setup. This change turns the default in DefaultConfiguration around towards explicitAllow. A simple silent upgrade within install tool sets the value to explicitDeny in LocalConfiguration for instances that still use this, so this change is fully transparent and b/w compatible. Resolves: #94721 Releases: master Change-Id: Ifd219edce21a1c044541e6c8129134543e8d95ef Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70233 Tested-by:
-
Christian Kuhn authored
We missed this one with #94706, which leads to warnings from phpunit when executing unit test suite. Resolves: #94723 Related: #94706 Releases: master Change-Id: I73d72d0def421f097b313c86ea7cad206804c372 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70235 Tested-by:
-
Benni Mack authored
If you have inline JS (or inlineFooterJS) code the method "GeneralUtility::minifyJavaScript()" is called twice for the same code to actually minify the code, because PageRenderer takes care of minification, so FE process does not explicitly have to do that. This does no harm, only if there is a hook within minifyJavaScript(), the processing is triggered twice. This also only happens if config.compressJs = 1 is called. Resolves: #94716 Releases: master Change-Id: I77af009bf252b9f249794ed5b8db1dd0ae26b769 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70207 Tested-by:
-
Jochen Roth authored
EXT:styleguide is capable to create a frontend page with a single click. Therefor, acceptance tests have been created to test each content element for expected classes and text. Also PHP8 undefined array key warnings have been fixed to get tests working as expected. Resolves: #94649 Releases: master Change-Id: Ie7586bd01a2b0f02c75fb300cc346c9129c346a4 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70118 Tested-by:
-
Oliver Bartsch authored
The value of a TSconfig entry in the $TSdata array, forwarded to the ModifyLoadedPageTsConfigEvent, has to be a string. Therefore the fallback must be a string, too. Otherwise it would make it unnecessary hard for extension authors to extend the default TSconfig using the mentioned event as they have to check for the actual type first. Resolves: #94718 Releases: master, 10.4 Change-Id: I023a389e79c01bceb427431d15da16d0b2089b0f Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70209 Tested-by:
Achim Fritz <af@achimfritz.de> Reviewed-by:
-
Daniel Siepmann authored
Not casting will lead to type incompatibility when used with sqlite where doctrine does not convert types. Resolves: #94698 Releases: master Change-Id: I923df64ba6d55be3b4d8fa219049ca3b507d8f36 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70195 Tested-by:
Oliver Klee <typo3-coding@oliverklee.de> Reviewed-by:
-
Christian Kuhn authored
Acceptance test docker image selenium/standalone-chrome:3.141 is re-tagged upstream to latest releases. Latest release 3.141.59-20210729 tagged as 3.141 has issues as shown by styleguide recently. To not run into this within core tests, the patch pins previous version 3.141.59-20210713 for now. Resolves: #94712 Releases: master Change-Id: I90f7e548c9a1a38616452ae29e566a9ae33c9fc3 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70198 Tested-by:
-
Benni Mack authored
PHPunit v9 allows to use further improvements to our testing API, and also offers extended support until at least Feb 2022. PHPunit v9 requires PHP 7.3+ which isn't a problem for us per-se. In addition, composer does not complain about an abandoned package anymore if we upgrade to PHPunit 9. In order to achieve this, we need to explicitly require "codeception/phpunit-wrapper:^9.0" which we can then remove later-on again. Used composer commands: > composer req --dev "phpunit/phpunit:^9.5" "phpspec/prophecy-phpunit" "codeception/phpunit-wrapper:^9.0" -W > composer req --dev "phpunit/phpunit:^9.5" "phpspec/prophecy-phpunit" -d typo3/sysext/core --no-update > composer remove --dev codeception/phpunit-wrapper Used rector to migrate all Unit tests to prevent warnings.. Resolves: #94706 Releases: master Change-Id: I68d9df07421149f4ad40964afc512f0f995b295b Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69297 Tested-by:
Mathias Brodala <mbrodala@pagemachine.de> Tested-by:
-
Oliver Bartsch authored
This fixes an array to string conversion and an undefined array key warning in EXT:form FinisherOptionGenerator. Resolves: #94686 Releases: master Change-Id: Ic6265c36ac0f53d70d85baabf9d1881263027207 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70179 Tested-by:
-
Benni Mack authored
Referencing other records in workspaces usually works in a way that it is always pointing to the live pendant of a versioned record, never to the versioned record (t3ver_oid>0). However, for MM this is the exception - because MM does not have the workspace context. So when Extbase is resolving a separate query to resolve e.g. a category from a news record, the MM handling kicks in, but always showed the live version, because there was no chance to overlay. Extbase internally first fetches the aggregate root (e.g. news), then does the overlay and building of the object of the main object, and then fires another query to fetch e.g. all attached categories / relations. In case of MM relations for workspaces, they need to be using the versionedUid of the news record, and not the live version. However, since this also affects other relations (IRRE without MM, Select + Group), the RelationHandler is used for workspace'd relations, and adds one additional query to that. This change adapts the place where the query for the properties is built, and takes the UID of the versioned record to resolve the properties attached to it. Resolves: #88021 Resolves: #82750 Resolves: #82086 Resolves: #76993 Relates: #57169 Releases: master, 10.4 Change-Id: I57d34b46d17d504301f54071404d6169ec974676 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/68913 Tested-by:
Danilo Caccialanza <supercaccia@bluewin.ch> Tested-by:
Martin Tepper <martintepper@arcor.de> Tested-by:
cbugada <christian.bugada@ti.ch> Tested-by:
-
Benni Mack authored
When using Online Media (Youtube, Vimeo) with FAL and with composer-mode, the preview images are put under var/transient/ which isn't accessible to the outside. This change adapts the change to be put in typo3temp/assets/online_media/ to be always accessible. In the future, this API should be refactored to have preview images based on processed files instead. Resolves: #93860 Related: #84545 Releases: master, 10.4, 9.5 Change-Id: I086b962a0efad2bcc0c67679838d3d973812462d Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69472 Reviewed-by:
Jan Kornblum <jan.kornblum@gmx.de> Reviewed-by:
Guido Schmechel <guido.schmechel@brandung.de> Reviewed-by:
-
- Aug 04, 2021
-
-
Oliver Bartsch authored
In #94622 the TCA type `category` was introduced as replacement for the CategoryRegistry. Therefore, the CategoryRegistry as well as the API method ExtensionManagementUtility::makeCategorizable() are now deprecated. Resolves: #85613 Related: #94622 Releases: master Change-Id: Ie12a643b97e2149981aec3fb1599bf8c8b4a8d64 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70202 Tested-by:
-
Wouter Wolters authored
The labels are now Cut or Copy when the icon is shown is about releasing the content from the clipboard. Resolves: #94627 Releases: master Change-Id: If5f4784f117f02ae7808849aec540f8b322196ae Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70200 Tested-by:
-
Helmut Hummel authored
The implementation of the bugfix https://review.typo3.org/53360 was done by iterating over TCA during cache generation and correctly quoting SQL fragments that are provided, to after that store TCA in cache. This has disadvantages: 1. A DB connection is required to create TCA cache: This makes efforts for warming up caches upfront impossible, as cache warmup should be able to be performed on build systems without DB connection. 2. It separates code that executes a query from code that is preparing a query: Escaping arguments for a query in a different place than the actual query execution can be considered an anti pattern, because at other points it isn't clear in which context these values are used. Beside that, performing the actual query, undoing DB encoding and redoing a different encoding is impossible. Pre-processing / quoting identifiers upfront can be considered a similar anti pattern as well. Despite there are less use cases to perform operations on the original non quoted identifiers, post processing of such fields in an event is impossible with the current implementation. 3. The current implementation being buggy and the adoption in TYPO3 is sparse: While this could be tackled with according fixes, it shows that this feature, that has been implemented a couple of years ago and is a technical burden, is rarely used, and therefore the implementation can be simplified and cleaned up. The patch drops this TCA preparation and field name escaping is now done in places where the queries are actually built. Strictly seen this is a breaking change for implementers of the TCA post processing event or for custom code that directly uses TCA to perform query parts. It is unlikely though that such code exists in userland, nonetheless a feature flag "runtimeDbQuotingOfTcaConfiguration" is introduced to allow extensions to also use the feature flag and use the quoting on demand if not done before. For TYPO3 v12, this feature flag will be enabled at all times. Releases: master Resolves: #94697 Change-Id: Ie0e48054def29c6c1e2810c8d30528c719439d9f Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69507 Tested-by:
Helmut Hummel <typo3@helhum.io> Reviewed-by:
-
Benni Mack authored
Currently Extbase ships with a custom CacheService which contains all PageIDs where the cache should be cleared once the plugin has been finished processing. In order to reduce the amount of injections within Typo3DbBackend, and decoupled Typo3DbBackend from the actual implementation of how caches are flushed, the cache clearing for pages of specific records is now moved into CacheService directly. This way, a better separation of concerns happens and custom StorageBackends can be implemented without needing to worry about TYPO3's internal cache flushing strategy. On top, it will become simpler to remove the SingletonInterface of Typo3DbBackend, if desired, as it does not keep state of the plugin via ConfigurationManager. Additionally, if we ever want to create a generic Cache Clearing logic (decoupled from DataHandler), we could simply combine CacheService with the new API. Resolves: #94703 Releases: master Change-Id: Ia79c01c35e6440634d2018f890f661acabacd852 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70186 Tested-by:
-
Benni Mack authored
The "inSet" method is very useful for finding CSV values in fields, however there was never a "notInSet" method which is now available for TYPO3 Core. Resolves: #84115 Releases: master Change-Id: Ied84fa51cb37391c9b814a2cddd5dbeb212fdd44 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70152 Tested-by:
Georg Ringer <georg.ringer@gmail.com> Tested-by:
-
Benni Mack authored
PSR3 ships with a LogLevel class, whereas TYPO3 Core ships its own logging API which is based on a numeric log level syntax. This change reduces the amount of usages of numeric usages of error / message magic (such as TimeTracker), thus, slowly migrating towards PSR3-based LogLevels everywhere. Resolves: #94702 Releases: master Change-Id: I359c88ce50ab94ef1022be975c07f4a7e3c25d0d Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70168 Tested-by:
-
Georg Ringer authored
If the language mode is chosen in the page module and the default language is selected, only the elements of the default language must be chosen. Resolves: #92460 Releases: master Change-Id: Ieb472967e37d85095d0cdd7c1608c5f48adcfc49 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65970 Tested-by:
-
- Aug 03, 2021
-
-
Andreas Fernandez authored
To avoid issues with Flexform section identifiers having any reserved character in CSS context, e.g. a dot, the identifier is now hashed to be able to find the container via `querySelector()`. Resolves: #94541 Releases: master Change-Id: Id2a63ae679e024835284672b2121af9003e58f51 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69815 Tested-by:
Tymoteusz Motylewski <t.motylewski@gmail.com> Reviewed-by:
-
Andreas Fernandez authored
Scenario: * a site with another language being configured as "strict" * an Extbase plugin consuming a list of records identified by their respective uid * plugin and records are localized to the site's language Expectation: The plugin receives the UIDs of the original record UIDs having sys_language_uid = 0. The plugin uses a custom Extbase Repository and passes the UIDs as array to a ->in() clause: ``` $query = $this->createQuery(); $query->matching($query->in('uid', [1, 2, 3])); ``` According to the site configuration, Extbase should be able to find these records in the default language and either overlay if translated, or discard them if no translations are available. Actual result: Extbase is not able to find any record and thus returns an empty result set. The identified cause is that Extbase searches the database for the given record UIDs in conjunction with the current language id, returning an empty set by definition. To prove the wrong behavior, tests are added that show the broken behavior, the actual fix will come with another patch in #88137. Resolves: #94694 Related: #88137 Releases: master, 10.4 Change-Id: I9a7a6ec5d1b5cfb82e1fc05365fde6e45df12dfc Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70192 Tested-by:Anja Leichsenring <aleichsenring@ab-softlab.de> Tested-by:
-
Benni Mack authored
Custom icons from extensions can now be registered via EXT:my_extension/Configuration/Icons.php. These files are now loaded and parsed during build-time, and stored in the core cache. Resolves: #94692 Releases: master Change-Id: I9f919510b8913103288e56e824c8a0148e045ad6 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70178 Tested-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Reviewed-by:
-
Nikita Hovratov authored
The new property '_recursive' allows to define recursive properties of objects. These properties are transformed automatically, without the need to define every entry level manually. Objects can contain a list of the same type like themselves. Examples could be folders containing folders or comments having comments as replies. Resolves: #90347 Releases: master Change-Id: I29b34cf3666c5ad142e51371240501cb85941b5a Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/63181 Tested-by:
-
Oliver Bartsch authored
In #89700, the page information view in the info module was extended for a new type, which displays the layout related (backend_layout, ..) fields for the corresponding pages. Since there might be field values which are not longer valid, because the referenced backend layout does not longer exist, the new type does now highlight such values with the already known `INVALID VALUE ("<value>")` string. Resolves: #94674 Releases: master Change-Id: I342fff7b8d76694831fa839901250b7d5da7e973 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70194 Tested-by:Simon Gilli <typo3@gilbertsoft.org> Reviewed-by:
-
Benni Mack authored
This change removes the internal "newlog()" method from DataHandler. All occurrences are replaced by DataHandler->log() methods, which newlog() acted as a wrapper for it. The main downside of newlog() is that the connection to the actual record (when writing to sys_log) is lost, and no contextual information is kept. This change solves that problem by properly setting the table and record uid to the log method. The main usages for DataHandler->newlog() are put into localization and workspaces/versionable handling. where the "action" is currently set to SystemLogGenericAction::UNDEFINED, because there is no specific type for them. Specific action types have been added for localize, versionize and publishing. The next step in this line of patches are: * Clean up the labels by always using %s or {} for replacements. Resolves: #94685 Releases: master Change-Id: If943dbaba39e1a9c16028b8c64e18b4b42aba902 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70171 Tested-by: -
Benni Mack authored
This change registers FileController as backend controller in Services.yaml and allows to inject all needed dependency via constructor DI. Resolves: #94696 Releases: master Change-Id: Idc14d1ef86bcbd5c4da77f3101b5a97f2a6aa6c3 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70188 Tested-by:
-
Oliver Bartsch authored
This fixes a TypeError by using the correct import. Resolves: #94689 Releases: master Change-Id: Ic54a1b1be27ab3809cfcf38e8aa2096433a771bd Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70180 Tested-by:
-
Benni Mack authored
Resolves: #94690 Releases: master Change-Id: I341b73f0c8782c75ca3c4bcf5a7038e6a86fc5dd Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70127 Tested-by:
-
Benni Mack authored
This change replaces some of the linkThisScript calls to use the UriBuilder / Routing of TYPO3 Backend, and corrects existing UriBuilder calls. Resolves: #94663 Releases: master Change-Id: If2dcb7c4f57b7357087eb88b7383576f3aaede1b Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69916 Tested-by:
-
Benni Mack authored
When uploading an invalid file (or a folder), the message within the filelist now does not contain empty "()" (for the status text) anymore. Resolves: #94691 Releases: master Change-Id: I8fcf62c7bd8a7ef3413e44e787a56fb289e73b83 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70184 Tested-by:
Nikita Hovratov <nikita.h@live.de> Tested-by:
-
- Aug 02, 2021
-
-
Oliver Bartsch authored
To ease the use of the new columns selector, especially when dealing with tables, having a large number of columns (e.g. pages or tt_content), a filter is added to the columns selector action bar. The remaining actions, such as "check all" are then bound to the current filter result. This allows to quickly select a specific group of columns. Resolves: #94680 Releases: master Change-Id: I348fcb9b043a2dd5697248be7aebd322c25cdf3f Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70169 Tested-by:
-
Christian Kuhn authored
Extbase provides a couple of generic domain repositories and models, especially frontend / backend users and groups. Those are flawed by design: The main issue is that domain models have to be specific for the domain they are used in. By definition, a generic, opinionated model can't be "correct" since the domain it is used in, is unique: It might be that a backend user email has to be set and the domain does not model anything but email and firstname? Many usages don't need backend groups attached to a backend user model at all, or if they need them, then maybe in a recursive presentation, or a specific order or something similar. Having a default group resolution is thus at least misleading, if not wrong, and can be a performance issue on top. A generic model can never foresee its usages. The existing models thus try to 1:1 adapt the database fields, which is also misleading since a domain model is not and should not be a direct representation of a database table. It would only be by chance if the generic models fit a specific domain. Similar issues exist with the repositories: The CategoryRepository for instance assumes it is a good idea to set respectStoragePid(false), which is most likely not the right thing for an extension use. In the end, whatever extbase delivers here, is most likely wrong and does not fit the problem domain. The patch keeps the 'experimental' FAL related models since those can be actually useful for extensions and their final fate has not been decided, yet. The other generic models, especially those with lots of properties are marked as deprecated with the patch. Change-Id: I06629fddd0258c517f3fa8bdf2e9c4b342be9678 Resolves: #94654 Related: #83296 Releases: master Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70061 Tested-by:
-
Oliver Bartsch authored
A new TCA type "category" is introduced, which allows to simplify the configuration of category TCA columns. Besides the benefit for integrators, this allows to deprecate the CategoryRegistry in the next step. The new type can also be used for other use cases. Therefore, the TCA option "relationship" is available for this TCA type. Besides "manyToMany" (default), this can also be set to "oneToOne" or "oneToMany". Using the new type, FormEngine will always render a category tree. This means, no additional `renderType` is defined. In such case, TCA type "select" can still be used as before, without any limitation. However, all relevant places in core are adjusted in this patch. The category element is rendered through a custom element (web component), reducing inline javascript. Resolves: #94622 Releases: master Change-Id: I1b95c42288b070fa6bac114266f5ad246a045b21 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69899 Tested-by:
core-ci <typo3@b13.com>...>
-
Nikita Hovratov authored
This fixes wrong input configuration, wrong method calls and adds some missing test cases. - The first parameter of assertSame expects the expected value. All occurrences in DataHandlerTest, which had them mixed up, are corrected. - TCA configuration "type => input" corrected. - Missing test cases with empty string as input added. Resolves: #94682 Releases: master Change-Id: If31ad11bb1e958fd24b1cbdb7d525d056fe3111b Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70175 Tested-by:
-
- Jul 30, 2021
-
-
Georg Ringer authored
If the creation date of a system news is cleared by an editor, the rendered news must skip the date. Resolves: #94576 Releases: master, 10.4 Change-Id: I93958ba0e858960dba4b99c0123cedce7dba5539 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69908 Tested-by:
Torben Hansen <derhansen@gmail.com> Tested-by:
-
Oliver Bartsch authored
Resolves: #94678 Related: #92953 Releases: master Change-Id: I33073717590a8561c9c5cfe4a1d76bfc627ff949 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70164 Tested-by:
-
