1. 13 May, 2022 1 commit
  2. 10 May, 2022 1 commit
  3. 05 May, 2022 2 commits
  4. 04 May, 2022 1 commit
  5. 03 May, 2022 1 commit
  6. 29 Apr, 2022 2 commits
  7. 25 Apr, 2022 1 commit
  8. 22 Apr, 2022 1 commit
  9. 17 Apr, 2022 1 commit
  10. 14 Apr, 2022 2 commits
  11. 21 Mar, 2022 1 commit
  12. 14 Mar, 2022 2 commits
  13. 09 Mar, 2022 2 commits
  14. 05 Mar, 2022 1 commit
  15. 04 Mar, 2022 2 commits
  16. 24 Feb, 2022 1 commit
  17. 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>
  18. 20 Feb, 2022 1 commit
  19. 18 Feb, 2022 1 commit
  20. 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 scheme:
      Manual modifications in:
      All other changes have been automated with:
      find Build/Sources/TypeScript/ -type f | \
          grep -v index.d.ts | \
          sed \
              -e 's:Build/Sources/TypeScript/:typo3/sysext/:' \
              -e 's:/Tests/:/Tests/JavaScript/:' \
              -e 's:/TypeScript/:/JavaScript/:' \
              -e 's:\.ts$:.js:' | \
          xargs git rm
      find Build/Sources/TypeScript/ -type f | while read file
          newFilename=$(echo $file | sed \
              -e :loop1 -e 's:\(/Public/TypeScript\|/Tests\)\([0-9a-zA-Z/.]*\)/\([A-Z][A-Z]*\)\([0-9a-zA-Z/-]*\)\.ts:\1\2/\L\3\E\4.ts:' -e 't loop1' \
              -e :loop2 -e 's:\(/Public/TypeScript\|/Tests\)\([0-9a-zA-Z/.]*[a-z]\)\([A-Z][A-Z]*\)\([0-9a-zA-Z/-]*\)\.ts:\1\2-\L\3\E\4.ts:' -e 't loop2' \
              -e s:/Resources/Public/TypeScript/:/: \
              -e s:/Tests/:/tests/:
          mkdir -p $(dirname "${newFilename}")
          [[ "$file" != "$newFilename" ]] && git mv "${file}" "${newFilename}"
      cat << EOF > convert_uppercase_to_lowercase.sed
      t loop1
      t loop2
      s:\(^import \|^import .* from \|import(\|declare module \)'\([0-9a-zA-Z/.]*\)/\([A-Z][A-Z]*\)\([0-9a-zA-Z/.-]*\)':\1'\2/\L\3\E\4':
      t loop3
      s:\(^import \|^import .* from \|import(\|declare module \)'\([0-9a-zA-Z/.]*[a-z]\)\([A-Z][A-Z]*\)\([0-9a-z/.-]*\)':\1'\2-\L\3\E\4':
      t loop4
      s:\(\* Module\:\{0,1\} \|\* @exports \|\* @module \)\([0-9a-zA-Z/.]*\)/\([A-Z][A-Z]*\)\([0-9a-zA-Z/.-]*\)$:\1\2/\L\3\E\4:
      t loop5
      s:\(\* Module\:\{0,1\} \|\* @exports \|\* @module \)\([0-9a-zA-Z/.]*[a-z]\)\([A-Z][A-Z]*\)\([0-9a-z/.-]*\)$:\1\2-\L\3\E\4:
      t loop6
      s:\(^import '\|^import .* from '\|import('\|declare module '\|\* Module\:\{0,1\} \|\* @exports \|\* @module \)TYPO3/cms/\([0-9a-z/.-]*\):\1@typo3/\2:g
      git ls-tree --name-only -r HEAD | \
          grep -v dashboard/Documentation/ | \
          grep -v Documentation/Changelog/ | \
          grep -v Build/JSUnit/ | \
          xargs sed -i -f convert_uppercase_to_lowercase.sed
      rm convert_uppercase_to_lowercase.sed
      sed -i \
          -e 's:TYPO3/CMS/\([A-Z]\):@typo3/\l\1:' \
          -e 's:@typo3/rteCkeditor:@typo3/rte-ckeditor:' \
          typo3/sysext/*/Configuration/JavaScriptModules.php \
      sed -i \
          -e "s/: \\(@typo3\\/.*\\)/: '\1\'/" \
      (cd Build; grunt build)
      git add typo3/sysext/
      Resolves: #96906
      Related: #96323
      Releases: main
      Change-Id: Ifed6ac373aa2bc0c36fe157fb3e9c220f520a9c4
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73522
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
  21. 15 Feb, 2022 1 commit
    • Benjamin Franzke's avatar
      [TASK] Convert all static RequireJS calls to native ES6 modules · 1ea56b32
      Benjamin Franzke authored and Georg Ringer's avatar Georg Ringer committed
      All static RequireJS calls (static string argument) are migrated to
      native ES6 modules.
      Excluded is CodeMirrorElement which still needs RequireJS to be
      available for loading CodeMirror and it's modules. CodeMirror
      migration to ES6 will be a separate step by upgrading from v5 to v6.
      Manual modifications in Form/Element/AbstractFormElement.php to keep
      JavaScriptModule flags for registerCustomEvaluation call-conversions.
      Also JavaScriptRenderer.php to is patched always include
      the EXT:core importmap whenever the JavaScriptItemHandler is used
      (required for the dependency to "JavaScriptItemProcessor.js").
      All other changes have been performed with the following commands:
        git grep -l "loadRequireJsModule('TYPO3/CMS" | \
          grep -v /Documentation/Changelog | \
          grep -v ActionMenuViewHelper.php | \
          xargs sed -i '/CodeMirrorElement/!'"s/->loadRequireJsModule('\\(TYPO3\/CMS\/[^']*\\)')/->loadJavaScriptModule('\\1.js')/g"
        git grep -l "JavaScriptModuleInstruction::forRequireJS('TYPO3/CMS" | \
          grep -v /Documentation/Changelog | \
          grep -v JavaScriptRendererTest.php | \
          xargs sed -i '/CodeMirrorElement/!'"s/JavaScriptModuleInstruction::forRequireJS('\\(TYPO3\/CMS\/[^']*\\)'/JavaScriptModuleInstruction::create('\\1.js'/g"
        git grep -l "JavaScriptModuleInstruction::forRequireJS($" | \
          grep -v /Documentation/Changelog | \
          grep -v Form/Element/AbstractFormElement.php | \
          xargs sed -i -e '/CodeMirrorElement/!s/::forRequireJS/::create/' -e "s/^\([ ]*\)'\\(TYPO3\/CMS\/[^']*\\)'/\\1'\\2.js'/g"
        sed -i "s/'\\(TYPO3\/CMS\/[^']*\\)'/'\\1.js'/g" typo3/sysext/backend/Tests/Functional/Form/MfaInfoElementTest.php
        # Same migration as already started in #96607
        git grep -l includeRequireJsModules= | \
          grep -v /Documentation/Changelog/ | \
          grep -v PageRendererViewHelper.php | \
          xargs sed -i \
            -e 's/includeRequireJsModules=/includeJavaScriptModules=/' \
            -e "s/\\([0-9]: *'TYPO3\\/CMS\\/.*\\)'/\\1.js'/g"
      Resolves: #96570
      Related: #96323
      Related: #96607
      Releases: main
      Change-Id: Idc81d6b4d58168f0bfafc3e9e4ad46fa1e5f27e7
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73027
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
  22. 14 Feb, 2022 1 commit
  23. 12 Feb, 2022 1 commit
  24. 11 Feb, 2022 1 commit
  25. 08 Feb, 2022 1 commit
  26. 07 Feb, 2022 1 commit
    • Oliver Bartsch's avatar
      [!!!][FEATURE] New Module Registration API · 29db88c3
      Oliver Bartsch authored and Benni Mack's avatar Benni Mack committed
      This change introduces a new way to register
      TYPO3 Backend Modules.
      Each module is now registered during build-time
      in a dedicated registry. Therefore, The registration
      is moved from ext_tables.php to the
      Configuration/Backend/Modules.php file.
      Accessing the registered modules can be done via
      a central API, the ModuleProvider class. This class
      takes care of access permissions and further
      processing (e.g. module menu generation).
      $GLOBALS[TBE_MODULES] is fully removed as no sane
      backwards-compatibility (for a use-case) is available.
      A new PSR-14 event BeforeModuleCreationEvent is added,
      which allows to manipulate a module configuration, before
      it is used to create and register the module.
      Existing registrations do no longer work. However, to support
      extenion authors in maintaining multiple versions, the previously
      used API methods (e.g. `addModule` and `registerModule`) will
      stay until TYPO3 v13.0. No trigger_error() is used, so extension
      authors use the Extension Scanner to detect usages.
      Executed commands:
         composer u typo3/cms-styleguide
      Resolves: #96733
      Releases: main
      Change-Id: I07f4bc417e6effb1215cf0e373cc60f2b13ba8ad
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73058
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      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>
  27. 05 Feb, 2022 1 commit
  28. 04 Feb, 2022 2 commits
  29. 02 Feb, 2022 1 commit
  30. 21 Jan, 2022 1 commit
  31. 19 Jan, 2022 2 commits