1. 13 May, 2022 1 commit
  2. 10 May, 2022 1 commit
  3. 09 May, 2022 1 commit
  4. 05 May, 2022 2 commits
  5. 04 May, 2022 1 commit
  6. 03 May, 2022 1 commit
  7. 29 Apr, 2022 2 commits
  8. 25 Apr, 2022 1 commit
  9. 22 Apr, 2022 1 commit
  10. 19 Apr, 2022 1 commit
  11. 17 Apr, 2022 1 commit
  12. 14 Apr, 2022 2 commits
  13. 12 Apr, 2022 1 commit
  14. 07 Apr, 2022 2 commits
  15. 05 Apr, 2022 2 commits
    • 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>
    • Benjamin Kott's avatar
      [TASK] Use bootstrap badges instead of labels · 7398d122
      Benjamin Kott authored and Benni Mack's avatar Benni Mack committed
      The "label" class was removed in bootstrap 5 and replaced through
      "badge". The "label" class was kept in place for a while to keep
      the compatibility as high as possible, but it's time to move on.
      Since bootstrap 5 also dropped support for severities on certain
      components, we are adding them again for the badge to keep the
      convenience as high as possible and avoid promoting the "utility css"
      approach that was introduced with these decisions as we try to keep
      markup changes as low as possible.
      This patch also reverts the SCSS includes back to relative paths.
      While it is possible to define additional lookup paths for the parser,
      so you can have shorter includes - it comes at a cost. The included
      sources are opaque to the user and the IDE, this means there is
      no support for auto-completion, quick navigation through included files
      and can lead to unintended overrides by the user.
      Resolves: #97291
      Releases: main
      Change-Id: I9007af705a90db567353379146df1d76b2366a62
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/74163
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
      Reviewed-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
  16. 04 Apr, 2022 1 commit
  17. 30 Mar, 2022 1 commit
  18. 21 Mar, 2022 1 commit
  19. 14 Mar, 2022 2 commits
  20. 09 Mar, 2022 2 commits
  21. 05 Mar, 2022 2 commits
  22. 04 Mar, 2022 2 commits
  23. 01 Mar, 2022 1 commit
  24. 28 Feb, 2022 1 commit
  25. 24 Feb, 2022 2 commits
  26. 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>
  27. 20 Feb, 2022 1 commit
  28. 18 Feb, 2022 1 commit
  29. 16 Feb, 2022 2 commits
    • Christian Kuhn's avatar
      [!!!][FEATURE] Avoid BackendTemplateView · 25773e86
      Christian Kuhn authored
      Class BackendTemplateView has been a temporary solution
      to simplify the implementation of the "TsConfig template
      override" feature into smaller patches.
      With ModuleTemplate and general view works being mostly
      done in the backend, BackendTemplateView should be
      removed again.
      The patch removes all usages switching nearly all views
      to BackendViewFactory, which removes the explicit
      dependency to Typo3Fluid ViewInterface since the
      EXT:core ViewInterface is not directly bound to Fluid
      Using BackendViewFactory has the additional advantage
      that templates which don't use ModuleTemplate because
      they're hook usages or some other "sub-view", can now
      be overridden with TsConfig, too.
      Using BackendViewFactory also makes the dependency to
      ServerRequestInterface explicit. The patch thus hands
      $request around at some more places where $request was
      only an indirect dependency before.
      One special @todo area is FormEngine, which is unable
      to have dependency injection (for BackendViewFactory)
      due to its manual constructor arguments. The patch
      falls back to Typo3Fluid TemplateView in those cases.
      The FormEngine API should be adapted with another patch.
      Change-Id: Ie8959dada4dc6fd30e04d87fea6004e74cbe5990
      Resolves: #96904
      Related: #96730
      Related: #96513
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73518
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Stefan Bürk's avatarStefan Bürk <stefan@buerk.tech>
      Tested-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Stefan Bürk's avatarStefan Bürk <stefan@buerk.tech>
      Reviewed-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
    • Benjamin Franzke's avatar
      [TASK] Use @typo3/ as ES6 module namespace · 7a41f905
      Benjamin Franzke authored and Georg Ringer's avatar Georg Ringer committed
      Switch from TYPO3/CMS/ExtName/ to @typo3/ext-name/ module
      namespace in all TypoScript modules in order to
      use the common "scoped package" syntax as known from npmjs.
      This will allow TYPO3 TypeScript declarations to be
      published to @typo3/* packages on npmjs.com at some point,
      allowing extension authors to require these as npm/yarn
      dependencies to be able to use TypeScript type declarations
      when developing against the TYPO3 JavaScript API.
      While at it, the naming convention of JavaScript modules is
      also switched to use lowercase-dashed form. This is to adhere
      to the common used naming convention in the npm-world.
      Also @typo3/core/ajax/ajax-request.js simply looks better than
      a mixed form @typo3/core/Ajax/AjaxRequest.js would be.
      All existing RequireJS module identifiers are mapped
      to the new naming syntax in the requirejs-to-es6 bridge:
      For example a requirejs call to
      will transparently be transformed to the new sc...