- 03 Jun, 2022 1 commit
-
-
Instead of checking for the array key `enablecolumns` the check must be done on the field `disabled` itself. Resolves: #97728 Releases: main, 11.5 Change-Id: I411b37d4d63eb1ad52592cd887a95c2552ab7bfa Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/74810 Tested-by:
core-ci <typo3@b13.com>
Tested-by: Simon Schaufelberger <simonschaufi+typo3@gmail.com> Tested-by:
Oliver Bartsch <bo@cedev.de>
Tested-by: Stefan Bürk <stefan@buerk.tech> Reviewed-by:
Oliver Bartsch <bo@cedev.de>
Reviewed-by:
-
- 31 May, 2022 1 commit
-
-
Based on the code, these parameters are nullable. The doc comments should reflect that. Doing so eliminates several PHPStan warnings. Whether these parameters ought to be nullable is a question for another time. Resolves: #97648 Releases: main, 11.5 Change-Id: Id0cc51d159ebb0321e94f7fb77a5d560950cfb05 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/74676 Tested-by:
core-ci <typo3@b13.com>
Tested-by: Oliver Klee <typo3-coding@oliverklee.de> Tested-by:
Nikita Hovratov <nikita.h@live.de> Tested-by:
-
- 28 May, 2022 1 commit
-
-
Resolves: #97630 Releases: main, 11.5 Change-Id: Id31d1b28929eb85dd2adaa8a263e5d84a2a842b5 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/74644 Tested-by:
core-ci <typo3@b13.com>
Tested-by: crell <larry@garfieldtech.com> Reviewed-by:
-
- 20 May, 2022 1 commit
-
-
This change reduces specialities within DataHandler: * DataHandler->username is not used, and can be removed. * Initial check in workspaceCannotEditOfflineVersion() can be moved to the caller class, using more useful log entries. * recordInfo() now fetches the full record from the DB which could then be cached separately during runtime. * Some internal methods are marked as protected, as they are trivial to re-implement and currently only used by DataHandler anyways. Resolves: #97628 Releases: main Change-Id: Ia91066914fadd9f5648d0d60de4d8bbf3c9daf21 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/74519 Tested-by:
core-ci <typo3@b13.com>
Tested-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by: Oliver Bartsch <bo@cedev.de>
-
- 09 May, 2022 1 commit
-
-
Not all tables have tstamp defined in their ctrl section. Resolves: #97588 Releases: main, 11.5 Change-Id: Ibddaab2e313bc2511b1f9aa903ed312d3cf7f9bd Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/74577 Tested-by:
core-ci <typo3@b13.com>
Tested-by: Georg Ringer <georg.ringer@gmail.com> Tested-by:
Oliver Bartsch <bo@cedev.de>
Reviewed-by: Oliver Bartsch <bo@cedev.de>
-
- 05 May, 2022 1 commit
-
-
This change adapts DataHandler logs to use interpolation from PSR-3 instead of %s to identify variables in log_details properly later-on. This makes all log messages from DataHandler and Workspaces PSR-3 compliant. In addition, all messages do not contain a "!" at the end anymore, as there is no need to emphasize errors through the log message itself (that's why there is type "Error" for logging). Same goes for "." in order to be consistent. Resolves: #97556 Releases: main Change-Id: Ia509b6e121be64cf89d111bdc260332d343b164c Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/74526 Tested-by:
core-ci <typo3@b13.com>
Tested-by: 
Jochen <rothjochen@gmail.com>
Tested-by: Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
Jochen <rothjochen@gmail.com>
Reviewed-by:
-
- 29 Apr, 2022 1 commit
-
-
Core requirements have been changed and publicly announced with: https://typo3.org/article/new-system-requirements-for-upcoming-typo3-v12 This patch removes supportive code for MSSQL due dropped support for this dbmns. MSSQL specific report and status checks are removed with #97411. Resolves: #97462 Related: #96553 Related: #97411 Releases: main Change-Id: I131805157b7780a4de6d0f3ab8e9d0d6883b7872 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/74382 Tested-by:
core-ci <typo3@b13.com>
Tested-by: Benni Mack <benni@typo3.org> Tested-by:
Oliver Bartsch <bo@cedev.de>
Tested-by: Andreas Fernandez <a.fernandez@scripting-base.de> Reviewed-by:
Oliver Bartsch <bo@cedev.de>
Reviewed-by:
-
- 22 Apr, 2022 1 commit
-
-
Due to a former lack of missing proper functions to check for strings starting, ending or containing sub-strings, workarounds with strpos() constructs have been used in TYPO3 as well as in just about every PHP application. PHP finally implemented proper native functions for these kind of tasks, which make code more readable and avoid to easily oversee bugs. Additionally, php-cs-fixer provides a rule-set to replace most of these changes, see: https://cs.symfony.com/doc/ruleSets/PHP80MigrationRisky.html This rule is now enabled and used to ensure cleaner code in the future. The rule is applied to ensure green cgl checks. Replacements covered by php-cs-fixer rule: * replace `strpos($haystack, $needle) === 0` with `str_starts_with($haystack, $needle)` * replace `strpos($haystack, $needle) !== 0` with `!str_starts_with($haystack, $needle)` * replace `strpos($haystack, $needle) !== false` with `str_contains($haystack, $needle)` * replace `strpos($haystack, $needle) === false` with `!str_contains($haystack, $needle)` Some additional (manual) replacements on nearby places to changed code places: * replace `substr($haystack, strlen($needle) * -1) === $needle` with `str_ends_with($expression, ']')` * replace `substr($haystack, strlen($needle) * -1) !== $needle` with `!str_ends_with($expression, ']')` Used commands: > Build/Scripts/runTests.sh -s cgl Resolves: #97438 Releases: main Change-Id: Ia1206d4dd08b43597bfe794389f6db8bdeb3de0f Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/74365 Tested-by:
core-ci <typo3@b13.com>
Tested-by:
-
- 18 Apr, 2022 1 commit
-
-
This patch replaces the "eval=null" option with the direct option "nullable". The goal is to further thin out "eval" and even remove it from some types completely. The TCA types password, datetime, link, number and color now don't have the TCA option "eval" anymore. A lot of code can now be simplified due to the removed lookup into the eval list. Resolves: #97384 Releases: main Change-Id: I48c98a3aa18c69fe9b6ae0501ce40f3571cfd216 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/74319 Tested-by:
core-ci <typo3@b13.com>
Tested-by: Susanne Moog <look@susi.dev> Reviewed-by:
-
- 17 Apr, 2022 1 commit
-
-
The corresponding parameter is used like an int, and only ints are passed. So it needs to be an int instead of a string. This change is non-breaking and hence backportable. Resolves: #97407 Releases: main, 11.5 Change-Id: I4f88ba99666176ca8074f6f50c97ddd7f98c4090 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/74336 Tested-by:
core-ci <typo3@b13.com>
Tested-by:
-
- 14 Apr, 2022 1 commit
-
-
It can be very hard to debug, which field in particular has failed, when the DataHandler only mentions the invalid value without any context. Therefore, the field name and the table name are now always added to the log message. This has been done for the type "link" and type "email" field. Note: For FlexForm fields the name of the table column is logged, as it is not feasible to account for the full path, especially in sections. Resolves: #97351 Releases: main Change-Id: I9172e40a2af7947fd858fc8a9f2a6dc842205aa6 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/74263 Tested-by:
core-ci <typo3@b13.com>
Tested-by: Jörg Bösche <typo3@joergboesche.de> Reviewed-by:
-
- 12 Apr, 2022 1 commit
-
-
Oliver Bartsch authoredTCA type "datetime" allowed the value to be a native type (with `dbType`), a int with `eval=int` or a simple string. Since the value is always a timestamp - in case no native type is used - the `eval=int` option is removed and the value is always handled as integer. Note: Due to various problems with migration of existing fields, this patch does not yet enforce the database field to be of type "integer". This will be done step by step in further patches, e.g. https://review.typo3.org/c/Packages/TYPO3.CMS/+/74281 Resolves: #97358 Releases: main Change-Id: Ia8297854fb75241660ffa2a9df850b22dd7a0b84 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/74205 Tested-by:
core-ci <typo3@b13.com>
Tested-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by: Oliver Bartsch <bo@cedev.de>
-
- 05 Apr, 2022 1 commit
-
-
The new type "number" is a replacement for type "input" with "eval=int" or "eval=double2" set. With this, the type "input" field is now always a html "text" field and type "number" is always a html "number" field. With the new TCA option "format", a number type can be defined. Values can be either "integer" (default) or "decimal". The decimal format replaces the former "double2" eval value. In the future, a new option for precision might be added, in order to dynamically define how many decimal places should be possible. The valueSlider has been moved from InputTextElement to NumberElement, as it makes only sense with a type number field. Additionally, the JS module is migrated to a custom element. Note: There is still the eval="num" option for type "input" fields. This is solely for the purpose to ensure only numeric characters are used. Therefore, this option does not qualify anymore for the "range" option. The "range" option is now removed altogether for simple type "input" fields, as it now purely handles text values. Resolves: #97193 Releases: main Change-Id: Ia0888699f2c518917412e700e2681d9fea727340 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/74067 Tested-by:
core-ci <typo3@b13.com>
Tested-by:
-
- 01 Apr, 2022 3 commits
-
-
Oliver Bartsch authored
In the process of using dedicated TCA types, the new TCA type "color" is introduced and replaces "renderType=colorpicker" of TCA type "input". Notable changes to the previous behaviour: - The maxlength is set to 7, since this is the maximum length for the hex color (#XXXXX | /#[0-9a-fA-F]{3,6}/) - The only allowed eval is "null" - "trim" is always done in DataHandler and FormEngine Note: The maxlength might change again as soon as we switch to another color picker which supports e.g. opacity specification. The TCA type is now wrapped into a custom element. Also does it now use the general ValuePicker JS module, instead of duplicating this functionality in the ColorPicker JS module. The ColorPicker JS module is furthermore refactored. Global initialization of the color pickers is deprecated. To initialize the ColorPicker for an element, it has to be provided as first argument in the initialize() method. used command: > composer u typo3/cms-styleguide Resolves: #97271 Releases: main Change-Id: I1418b100ae214499be7b01f6c94539a6cb6baa3b Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/74121 Tested-by:core-ci <typo3@b13.com>
Tested-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by: Oliver Bartsch <bo@cedev.de> -
Oliver Bartsch authored
Resolves: #97280 Releases: main, 11.5 Change-Id: Id6b2b5bf9a200d7c0ccc6c23273bb5086d6ee50a Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/74154 Tested-by:
core-ci <typo3@b13.com>
Tested-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by: Oliver Bartsch <bo@cedev.de> -
To prepare towards a deployable backend group access rights system, some of the more obscure options are removed to reduce overall complexity. * TYPO3_CONF_VARS['BE']['explicitADmode'] is finally gone: Following a deny list approach is a flawed security system. TYPO3's default setting (explicitADmode=allow) follows the very common "Least Privileged" principle, so editors need to be explicitly given access to a CType, as is done with all other permissions. * The only valid value for TCA config option "authMode" on type="select" fields is now "explicitAllow". The previous "explicitDeny" value is abandoned following the reasoning above. The value "individual" is abandoned since it is a very rarely used setting (not a single match in TER). * With authMode="individual" being gone, the select item array keys on position six that could be set to "EXPL_DENY" and "EXPL_ALLOW" are obsolete. * Field "explicit_allowdeny" in table be_groups is simplified. This was a comma separated list of colon separated: "table:field:value:ALLOW/DENY". The last "ALLOW" or "DENY" is now obsolete. The patch removes the above handling from the core. A TCA migration scans TCA for invalid options and adapts them. An upgrade wizard is in place to clean up the be_groups explicit_allowdeny field of existing rows. Resolves: #97265 Releases: main Change-Id: I545b08fc694e9081ad79e69e7f55f684316e7b0f Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/74126 Tested-by:
core-ci <typo3@b13.com>
Tested-by: Oliver Bartsch <bo@cedev.de>
Tested-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by:
-
- 30 Mar, 2022 1 commit
-
-
In our process of using dedicated TCA types, the new TCA type "date" is introduced and replaces "renderType=inputDateTime" of TCA type "input". Notable changes to the previous behaviour: - the "format" option, which was already documented but never used in FormEngine, is now mandatory - TCA option "max" is no longer evaluated - The only allowed eval's are "null" and "int" The corresponding FormEngine element class is renamed from InputDateTimeElement to DatetimeElement. This is covered in the ClassAliasMap. Note: The "eval=int" seems to be superfluous since the field value should always be stored as int in case no native type ("dbType") is used. However, this would be breaking and is therefore done in a separate followup patch. This has already been kickstarted in https://review.typo3.org/c/Packages/TYPO3.CMS/+/74027/12. Resolves: #97232 Releases: main Change-Id: I94c6d12759cd7787e6185ab36d2fcd60f5dc15df Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/74027 Tested-by:core-ci <typo3@b13.com>
Tested-by:
-
- 26 Mar, 2022 1 commit
-
-
In the process of using dedicated TCA types, the new TCA type "password" is introduced and replaces "eval=password" and "eval=saltedpassword" of TCA type "input". Notable changes to the previous behaviour: - "trim" is always done in DataHandler and FormEngine - Password field is rendered as input type=password - The input field has by default "autocomplete=off" The TCA type "password" introduces the new configuration "hashed", which can be set to "false", if the field value should be saved as plaintext to the database. This configuration has no effect for the tables "fe_users" and "be_users". Resolves: #97104 Releases: main Change-Id: Ia48296291a61df6802ef21105b38b4f508b7a11c Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73832 Tested-by:
core-ci <typo3@b13.com>
Tested-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by: Oliver Bartsch <bo@cedev.de>
-
- 22 Mar, 2022 1 commit
-
-
EXT:core unfortunately has a couple of dependencies to EXT:frontend. One of them are TypoLinkCodecService. Since this service does not have any context, only related to EXT:frontend, it is now moved to EXT:core, resolving this cross dependency. This also allows to use the service in the DataHandler instead of duplicating parts of the code, which was previously done to prevent any EXT:frontend dependency in the DataHandler. Resolves: #97217 Releases: main Change-Id: Ib24bfb530fd0ac486ac30b09f43717c95c98c292 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73993 Tested-by:
core-ci <typo3@b13.com>
Tested-by:
-
- 21 Mar, 2022 1 commit
-
-
Annotations are not needed since .phpstorm.meta.php takes care of it. Resolves: #97213 Releases: main, 11.5 Change-Id: I00687c4ea2c938e5b531016faf80f2a84ea1cdd9 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73996 Tested-by:
core-ci <typo3@b13.com>
Tested-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by: Oliver Bartsch <bo@cedev.de>
-
- 15 Mar, 2022 1 commit
-
-
When logging, the "DELETE" action is used when trying to read a record which should be copied. This change uses the INSERT action, so the log is proper. Resolves: #97182 Releases: main, 11.5 Change-Id: I294ee08e24327e67b6de2812163a00e6ca35f043 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73911 Tested-by:
core-ci <typo3@b13.com>
Tested-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by: Oliver Bartsch <bo@cedev.de>
-
- 14 Mar, 2022 1 commit
-
-
Oliver Bartsch authored
In our process of using dedicated TCA types, the new TCA type "link" is introduced and replaces "renderType=link" of TCA type "input". Notable changes to the previous "inputLink" behaviour: - "linkPopup" fieldControl is now always used by the FormEngine element - Corresponding fieldControl options are migrated to columns config - The type now makes use of include lists instead of exclude lists - The allowed link types are now evaluated in DataHandler - "trim" is always done in DataHandler and FormEngine - "max" is no longer evaluated - "softref=typolink" is automatically set As mentioned, the TCA type "link" uses include lists. This also required to adjust the LinkPopup fieldControl, as well as the Link Browser classes. The previously used "blinkLink[Fields|Options]" options are still supported in case the "LinkPopup" fieldControl is used for another TCA type. However, they might be deprecated soon. Finally, the TSconfig key for the MailLinkHandler is renamed from "mail" to "email", to unify the naming in the codebase. Resolves: #97159 Releases: main Change-Id: Ied9e957b973ed8904736e5d4353a989ea76065d8 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73866 Tested-by:
core-ci <typo3@b13.com>
Tested-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by: Oliver Bartsch <bo@cedev.de>
-
- 11 Mar, 2022 1 commit
-
-
t3ver_oid might be missing if the table is not workspace enabled. Resolves: #97168 Releases: main, 11.5 Change-Id: I378ec155922f26d6ed536eda9131c612bb0e20a7 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73898 Tested-by:
Oliver Bartsch <bo@cedev.de>
Tested-by: core-ci <typo3@b13.com>
Tested-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by:
-
- 09 Mar, 2022 2 commits
-
-
DataHandler and a few other places still used hard-coded values in the details field of sys_log, which is why certain logs could not be cleaned up due to different messages. This change removes all direct left-over places where variables are written directly as message (a few special cases will be handled separately). Resolves: #97155 Releases: main, 11.5 Change-Id: Idcf0e29ae41c6c1cf108b9c00c07fb180e16223b Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73863 Tested-by:
Oliver Bartsch <bo@cedev.de>
Tested-by: core-ci <typo3@b13.com>
Reviewed-by: Oliver Bartsch <bo@cedev.de> -
Benni Mack authored
This change allows using PSR-3 provided placeholders such as "{myVariable}" in various places related to logging rendering, and fixes places in DataHandler where placeholders weren't used in the past and hard-coded strings were used instead of labels. Various logging calls to sys_log can now be read in a unified way, as the Logging API already used the placeholders in some places. Resolves: #97148 Releases: main, 11.5 Change-Id: Idd248fe6b5edf4dbc0476a602ba3dbb1d165b588 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73859 Tested-by:core-ci <typo3@b13.com>
Tested-by: Jochen <rothjochen@gmail.com>
Tested-by: Oliver Bartsch <bo@cedev.de>
Tested-by: Jochen <rothjochen@gmail.com>
Reviewed-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by:
-
- 07 Mar, 2022 1 commit
-
-
Resolves: #97132 Releases: main Change-Id: I8c052bba413c174f752dcb2d8558b7fbc95115df Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73839 Tested-by:
core-ci <typo3@b13.com>
Tested-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by: Oliver Bartsch <bo@cedev.de>
-
- 05 Mar, 2022 1 commit
-
-
doctrine/dbal moves their classes forward and deprecated some stuff while providing replacement for it. This has been early adopted for the core facade classes with #97081 in a forward-compatible way. Before deprecating the old methods core usage have to be replaced. Following ExpressionBuilder methods are replaced: * 'andX()' with 'and()' * 'orX()' with 'or()' 'and()' and 'or()' are made strict along the way. This is a preparation to deprecate 'andX()' and 'orX()' to align with ongoing deprecation and replacement of doctrine/dbal changes. Resolves: #97110 Related: #97081 Releases: main Change-Id: Ia931266c6edc3abea38122242d7eab1092ae7d49 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73817 Tested-by:
core-ci <typo3@b13.com>
Tested-by:
-
- 04 Mar, 2022 2 commits
-
-
This improves the DataHandler::checkValue_SW method by using "match" instead of "switch". Resolves: #97099 Releases: main Change-Id: I9c19f06693c69b099f6e5c06a36c44325b1e3329 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73804 Tested-by:
core-ci <typo3@b13.com>
Tested-by: -
Andreas Fernandez authored
In our process of using dedicated TCA types, the new TCA type "email" is introduced and replaces "eval=email" of TCA type "input". Notable changes to the previous "email" behaviour: - "trim" is always be done in DataHandler and FormEngine - The maxlength is set to 255, since this is the maximum length of an email address Resolves: #97013 Releases: main Change-Id: I9730becafd21d4efa6f43a1d6a265df29d2943f3 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73687 Tested-by:
core-ci <typo3@b13.com>
Tested-by:
-
- 28 Feb, 2022 1 commit
-
-
Andreas Fernandez authored
In order to make TCA slimmer and more understandable, the `required` configuration is now used in favor of `eval`, which is also enforced by an automatic TCA migration. At least since #67354 TYPO3 is able to use an explicit `required` configuration: 'column' => [ 'label' => 'foo', 'config' => [ 'type' => 'input', 'required' => true, ], ] Resolves: #97035 Releases: main Change-Id: Ifa4b361e7e4a664596697d4351d6d4b933946d54 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73709 Tested-by:core-ci <typo3@b13.com>
Tested-by: Oliver Bartsch <bo@cedev.de>
Tested-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by:
-
- 25 Feb, 2022 1 commit
-
-
The TCA type group became more and more a pure database relation type throughout the years. The only annoyance that was still there is internal_type with "folder" set. Although they are very similar in the user interface, internally they are handled completely separate. They share only a fraction of common TCA properties, too. This leads to checks for internal_type !== 'folder' everywhere across the codebase. To avoid this, folder must become an own type. With folder as an own type, the code becomes much more readable and there is a lot less if-branching. Resolves: #96983 Releases: main Change-Id: Ifb746be9a5fc978a9a47af4c9e65bfc5498abf51 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73622 Tested-by:
core-ci <typo3@b13.com>
Tested-by: Oliver Bartsch <bo@cedev.de>
Tested-by: Benjamin Franzke <bfr@qbus.de> Reviewed-by:
Oliver Bartsch <bo@cedev.de>
Reviewed-by:
-
- 24 Feb, 2022 1 commit
-
-
Christian Kuhn authored
Scenario: * Create a page in live * Create a default language content element in live * Localize live page * Select a workspace * Localize the content element in workspaces, translate mode * Select live workspace * Delete default content element in live When deleting the default language content element in live, usually all translated content elements are deleted, too. This does not work for content element translations that have been created in workspaces (t3ver_state=1). Those elements *should* be discarded, but are not. The patch adds a method to DataHandler to take care of discarding t3ver_state=1 translations in workspaces when a live record is set to deleted, and adds two functional tests to verify behavior. Resolves: #97018 Releases: main, 11.5 Change-Id: I1bba5de52447cdfb9e80feca27aebf9855dccd28 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73690 Tested-by:
core-ci <typo3@b13.com>
Tested-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by:
-
- 22 Feb, 2022 1 commit
-
-
In early stage of TYPO3v11 the storage format for data in the TCA ctrl transOrigDiffSourceField database field, often called l18n_diffsource changed from PHP serialized data to JSON encoded storage format with #91906, mainly to mitigate general security risks. doctrine/dbal enquotes json data provided as string with backslashes if not the correct field type is provided, which emits a postgres sql error exception when inserting or updating these fields, which are of type 'bytea' when dbms Postgres is used. Various parts of the core deal with arbitrary tables and don't know if a column is int, text or lob, or whatever. Those are blindly updated/inserted, resulting in Postgres saying "no". MSSQL has been named pickier than postgres in the past on that for similar issues with these fields. To solve this for MSSQL a expensive workaround on several places through the core with #81498 to get a working state and leaving it open to find a better way with a eventual cache-layer for these database field schema informations, thus unsolved yet. As core suffers now from the same issue for Postgres since the changed storage format, this patch adopts the choosen MSSQL solution for Postgres. This is a first bugfix solution with the tradeoff to be more expensive but working. Additionally one test case is added to cover this issue basicly but should be extended and further tightend in a dedicated patch. Improving the schema handling should be picked up and proper engineered in a another dedicated patch. Resolves: #96940 Related: #91906 Related: #81498 Releases: main, 11.5 Change-Id: I250fa10c9c7e06ddd330f7ab64f7680f21f3b4cd Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73636 Tested-by:
core-ci <typo3@b13.com>
Tested-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by: Oliver Bartsch <bo@cedev.de>
-
- 02 Feb, 2022 1 commit
-
-
Many classes in TYPO3 have a function called getLanguageService(). The function definition is not always equal and some functions have a return type or doc comment and others do not. This patch streamlines the function as following: * It must always use a return type declaration * It must not contain a doc comment header Also, the superfluous override of getLanguageService() in some subclasses extending AbstractFormElement has been removed. Resolves: #96732 Releases: main Change-Id: Ie4e7fc19b2e84dee78496b4eec674a215a81c00c Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73261 Tested-by:
core-ci <typo3@b13.com>
Tested-by:
-
- 18 Jan, 2022 1 commit
-
-
doctrine/dbal implemented single purpose method to replace the compound 'execute()' in QueryBuilder to avoid the incompatible return typehint tuple of 'Doctrine\DBAL\Result|int' in favour of 'executeQuery()' and 'executeStatement()' which was added forward-compatible with #96247 marking the old one internal but not deprecated for now to keep a eventually longer grace period to mitigate for extensions developers. This patch however goes through the core and replace these methods to be clean as possible and is a first preparation to remove the 'checkThisOnly' option from phpstan which are swallowed by this option. * replace 'execute' with 'executeQuery()' for select and count queries generating results ('Doctrine\DBAL\Result'). * use 'executeStatement()' for insert, update and delete queries return affected rows as return value (int) * adjust return typehints to match the single return type signature on really minor places to match the return type of the wrapped replaced execute method. * replace one really old 'exec()' from connection with corresponding replacement method along the way. * add several todos on two places which are weird and do not make any sense for further investigation and fixing, as declared as out-of-the-scope for this wide-area patch. Resolves: #96551 Related: #96247 Related: #96521 Releases: main, 11.5 Change-Id: Ie8d40f3882f1694ab7f7e5053729fa1c798a9c5f Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73032 Tested-by:core-ci <typo3@b13.com>
Tested-by:
-
- 14 Jan, 2022 1 commit
-
-
This happens when "transOrigPointerField" is not defined in TCA configuration. Additionally, a PHP 8.1 deprecation is fixed when passing a null to trim(). Resolves: #96514 Releases: main, 11.5 Change-Id: Ic99bd0b0c166397bda23d2e45ca2d4cb766000be Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/72970 Tested-by:
core-ci <typo3@b13.com>
Tested-by:
-
- 08 Jan, 2022 1 commit
-
-
The type can already be inferred from the source code. The cleanup was run automatically with a PHPStorm plugin. Resolves: #96482 Releases: main Change-Id: I669145adc66dc898f3016de1958cf0105c988243 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/72907 Tested-by:
core-ci <typo3@b13.com>
Tested-by:
-
- 03 Jan, 2022 1 commit
-
-
Resolves: #96415 Releases: main, 11.5 Change-Id: I4f96cd250b1f1ef27c7232b8fff3214cb555ab32 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/72827 Tested-by:
core-ci <typo3@b13.com>
Tested-by:
-
- 20 Dec, 2021 1 commit
-
-
doctrine/dbal:^3.2 changed return type of result for QueryBuilder execute methods, no longer have used prepared statement accessible for further query execution with other placeholder values. To raise doctrine/dbal:^3.2 two places have been changed to reuse the QueryBuilder instance itself instead of prepared statement with the corresponding patch #96287, thus given up the performance gain through reusable query execution plan in corresponding dbms systems. This patch adds support for prepared statements to TYPO3's QueryBuilder facade as this was not publicly available yet for TYPO3 users to be forward-compatible with Doctrine DBAL 3. Resolves: #96393 Related: #96287 Releases: main Change-Id: I814670ebf9920ed3162a31f98ad9efd4031f47c9 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/72610 Tested-by:
core-ci <typo3@b13.com>
Tested-by:
-
- 16 Dec, 2021 1 commit
-
-
The FinisherOptionGenerator of the form extension generates the data structure for the form setting overrides on the fly. By doing so, it didn't make a distinction between normal TCA fields and flexform specific sections/containers and added the wrapper "TCEforms" to sections as well, which broke the validation in DataHandler for the fields inside the container (E.g. the email field). The patch checks if section is set to "true" and adds the "TCEforms" key only for normal TCA field configurations. Unit tests have been added for the DataHandler checkValue_flex_procInData_travDS method, which show cases with and without the "TCEforms" key. Also, since this works now, a PHP 8 warning appeared. This is fixed now, too. Resolves: #95441 Releases: main, 11.5 Change-Id: Ib12a0484bcbdc827664181ca6af89edfadee13d8 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/71490 Tested-by:
core-ci <typo3@b13.com>
Tested-by:
-
