1. 03 Jun, 2022 1 commit
  2. 31 May, 2022 1 commit
  3. 28 May, 2022 1 commit
  4. 20 May, 2022 1 commit
  5. 09 May, 2022 1 commit
  6. 05 May, 2022 1 commit
  7. 29 Apr, 2022 1 commit
  8. 22 Apr, 2022 1 commit
  9. 18 Apr, 2022 1 commit
  10. 17 Apr, 2022 1 commit
  11. 14 Apr, 2022 1 commit
  12. 12 Apr, 2022 1 commit
  13. 05 Apr, 2022 1 commit
    • Nikita Hovratov's avatar
      [FEATURE] Introduce TCA type "number" · fb7c7814
      Nikita Hovratov authored and Andreas Fernandez's avatar Andreas Fernandez committed
      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: Nikita Hovratov's avatarNikita Hovratov <nikita.h@live.de>
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Reviewed-by: Nikita Hovratov's avatarNikita Hovratov <nikita.h@live.de>
      Reviewed-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
  14. 01 Apr, 2022 3 commits
  15. 30 Mar, 2022 1 commit
  16. 26 Mar, 2022 1 commit
  17. 22 Mar, 2022 1 commit
  18. 21 Mar, 2022 1 commit
  19. 15 Mar, 2022 1 commit
  20. 14 Mar, 2022 1 commit
    • Oliver Bartsch's avatar
      [FEATURE] Introduce TCA type "link" · 40d4f901
      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
      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's avatarcore-ci <typo3@b13.com>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Susanne Moog's avatarSusanne Moog <look@susi.dev>
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Susanne Moog's avatarSusanne Moog <look@susi.dev>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
  21. 11 Mar, 2022 1 commit
  22. 09 Mar, 2022 2 commits
  23. 07 Mar, 2022 1 commit
  24. 05 Mar, 2022 1 commit
  25. 04 Mar, 2022 2 commits
  26. 28 Feb, 2022 1 commit
  27. 25 Feb, 2022 1 commit
  28. 24 Feb, 2022 1 commit
  29. 22 Feb, 2022 1 commit
    • Stefan Bürk's avatar
      [BUGFIX] Use proper Postgres types on inserting / updating rows · 46fbd888
      Stefan Bürk authored and Oliver Bartsch's avatar Oliver Bartsch committed
      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's avatarcore-ci <typo3@b13.com>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
  30. 02 Feb, 2022 1 commit
  31. 18 Jan, 2022 1 commit
    • Stefan Bürk's avatar
      [TASK] Use proper QueryBuilder execute() replacement methods · 597a92fd
      Stefan Bürk authored and Benni Mack's avatar Benni Mack committed
      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: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
  32. 14 Jan, 2022 1 commit
  33. 08 Jan, 2022 1 commit
  34. 03 Jan, 2022 1 commit
  35. 20 Dec, 2021 1 commit
  36. 16 Dec, 2021 1 commit