1. 13 Jan, 2022 2 commits
  2. 12 Jan, 2022 4 commits
  3. 11 Jan, 2022 3 commits
  4. 10 Jan, 2022 2 commits
    • Benjamin Franzke's avatar
      [TASK] Separate JavaScriptHandler concerns · a669f117
      Benjamin Franzke authored
      This change is preparatory refactoring in order to support
      native JavaScript modules (ESM) where a module can't be used both
      as classic script-src and as ES6 module providing exports at the same
      time (this was/is possible for AMD as implemented in #95953):
      `export` is an invalid keyword in non-module scripts and cannot be
      specified conditionally, that is very different to AMD modules where
      `define()` can be called conditionally.
      
      JavaScriptHandler currently has three execution modes:
      
       * If used as script-scr: Call processItems from text content for:
         * RequireJS configuration
         * Generic JavaScriptItems processing
       * If used as AMD module:
         * Generic JavaScriptItems processing
      
      JavaScriptHandler is now separated into the following three concerns:
      
      JavaScriptItemProcessor
      -----------------------
      The previous processor "mode" is now available as
      streamlined JavaScriptItemProcessor module, in order
      to drop type invariance (it requires parsed objects
      instead of allowing raw json data or objects)
      
      JavaScriptItemHandler
      ---------------------
      The previous JavaScriptHandler module that processes
      text content and calls arbitrary hooks has been
      simplified to the one usecase that was actually being used:
      Handling JavaScriptItems by parsing the text content.
      The extracted JavaScriptItemProcessor is used as backend
      for the actual work.
      
      RequireJSConfigHandler
      ----------------------
      The RequireJS configurator is now available as
      separate module, as this logic is only needed once and not by
      other modules. There is no need to keep that functionality in
      JavaScriptItemProcessor, especially as it has been hidden from
      AMD modules, which complicated the JavaScriptHandler.
      This extraction also actually allows to make use of modules
      in JavaScriptHandler and therefore enables the possibility to
      share code using JavaScriptItemProcessor.
      
      Also the code has been migrated to TypeScript.
      JavaScriptItemHandler and RequireJSConfigHandler do not export
      or import code, therefore they are usable as plain targets
      for script-tags.
      
      In addition the JavaScriptItemHandler is now executed
      asynchronously, which allows the browser to parse DOM
      in parallel. (synchronous mode is required for RequireJS
      config, but not for loading of requirejs-modules/instructions,
      they are asynchronous anyway).
      
      FileClipboardCest is adapted to wait more than 1 second, since the
      rerendering of the clipboard (a new iframe request is made) takes
      longer than 1 second in some test runs (not locally, but on CI)
      (note: the default 1 second wait timeout is configured in
      typo3/sysext/core/Tests/Acceptance/Application.suite.yml, but that's
      too less in this case).
      
      Releases: main
      Resolves: #96476
      Related: #95953
      Related: #96323
      Change-Id: I48a5751cea03537344e925beba365841e0855dde
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/72892
      
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Oliver Hader's avatarOliver Hader <oliver.hader@typo3.org>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
      Reviewed-by: Oliver Hader's avatarOliver Hader <oliver.hader@typo3.org>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
      a669f117
    • Oliver Bartsch's avatar
      [BUGFIX] Fix rootlevel check in ListModule fieldControl · cee749cc
      Oliver Bartsch authored
      Resolves: #96481
      Releases: main, 11.5
      Change-Id: I41eeb4ecf0b90e998875701131b2c8a35bfa3225
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/72906
      
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Stefan Bürk's avatarStefan Bürk <stefan@buerk.tech>
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Stefan Bürk's avatarStefan Bürk <stefan@buerk.tech>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      cee749cc
  5. 08 Jan, 2022 1 commit
  6. 07 Jan, 2022 2 commits
  7. 05 Jan, 2022 1 commit
  8. 04 Jan, 2022 1 commit
  9. 03 Jan, 2022 3 commits
  10. 30 Dec, 2021 2 commits
  11. 29 Dec, 2021 2 commits
  12. 23 Dec, 2021 2 commits
  13. 21 Dec, 2021 4 commits
  14. 20 Dec, 2021 6 commits
  15. 17 Dec, 2021 1 commit
  16. 16 Dec, 2021 2 commits
  17. 15 Dec, 2021 2 commits