1. 13 May, 2022 1 commit
  2. 10 May, 2022 1 commit
  3. 25 Apr, 2022 1 commit
  4. 17 Apr, 2022 1 commit
  5. 14 Apr, 2022 1 commit
  6. 14 Mar, 2022 1 commit
  7. 09 Mar, 2022 1 commit
  8. 20 Feb, 2022 1 commit
  9. 18 Feb, 2022 1 commit
  10. 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
      anymore.
      
      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>
      25773e86
    • 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
        TYPO3/CMS/T3editor/Element/CodeMirrorElement
      will transparently be transformed to the new sc...
      7a41f905
  11. 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>
      1ea56b32
  12. 12 Feb, 2022 1 commit
  13. 11 Feb, 2022 1 commit
  14. 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>
      29db88c3
  15. 05 Feb, 2022 1 commit
  16. 04 Feb, 2022 1 commit
  17. 02 Feb, 2022 1 commit
  18. 19 Jan, 2022 1 commit
  19. 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>
      597a92fd
  20. 16 Jan, 2022 2 commits
  21. 23 Dec, 2021 1 commit
  22. 03 Nov, 2021 1 commit
  23. 24 Oct, 2021 1 commit
  24. 19 Oct, 2021 1 commit
  25. 12 Oct, 2021 1 commit
  26. 07 Oct, 2021 1 commit
  27. 24 Sep, 2021 1 commit
  28. 30 Aug, 2021 1 commit
  29. 25 Aug, 2021 1 commit
  30. 24 Aug, 2021 1 commit
  31. 20 Aug, 2021 1 commit
  32. 12 Aug, 2021 1 commit
    • Benni Mack's avatar
      [FEATURE] Improve Usability in Workspaces module · cc0c62e8
      Benni Mack authored and Christian Kuhn's avatar Christian Kuhn committed
      The workspaces module has a better style and some
      improvements for editors and administrators:
      
      * Editors now get feedback if an AJAX call shows no results
      * Editors + Administrators now switch workspace via a selector,
        very helpful when having more than a couple of workspaces
      * Administrators can now edit a workspace record
        directly from the module
      
      The change cleans up a lot of unused code in the main workspaces
      module and brings a few UX improvements within the module.
      
      * Dropdowns instead of tabs (good when having a lot of workspaces)
      * Language + Depth + Action selection is now rendered via
        Controller+Action instead of waiting for a first AJAX round trip
      * Properly using "moduleData" from "uc" to store information
      * Solved issues related to language icon rendering
      * Removed unused inline settings
      * Consistent usage of Persistent JS module accessing BE_Users' UC
      * nProgress for showing progress of loading AJAX requests
      
      Next steps in this area:
      * Hand in the first payload as JSON to avoid AJAX call on
        initial page load
      * Remove leftover inline JavaScript
      
      Resolves: #94819
      Releases: master
      Change-Id: Ie533656a14af56dad4a4039fcbc9b08bde693500
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70452
      
      
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Wouter Wolters's avatarWouter Wolters <typo3@wouterwolters.nl>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Wouter Wolters's avatarWouter Wolters <typo3@wouterwolters.nl>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      cc0c62e8
  33. 29 Jul, 2021 1 commit
  34. 21 Jun, 2021 1 commit
  35. 26 May, 2021 1 commit
    • Richard Haeser's avatar
      [TASK] Set proper title of window in backend · 2cba0bac
      Richard Haeser authored and Benjamin Franzke's avatar Benjamin Franzke committed
      With the introduction of the new backend module web component router,
      the title of the backend windows will be set to the title of the
      main iframe. Most of the modules didn't provide a proper name though.
      
      For most modules we have a proper name now which will show up in the
      title of the backend window, if no title is propagated by the module,
      the backend router will fallback to the default backend title.
      
      As the format of the title is quite "personal". If you are used to have
      opened more TYPO3 backend windows, you would like to see which
      installation you have open. If you only work in one backend, you
      might want to see on which module you are currently working. It is
      possible to set the order of the title of the backend within your
      user settings now. By default it will be title - siteName [version]
      
      Resolves: #94182
      Releases: master
      Change-Id: I02602650370140217aa252bbd8e29ea4e05d994a
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69172
      
      
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Jochen's avatarJochen <rothjochen@gmail.com>
      Tested-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
      Reviewed-by: Jochen's avatarJochen <rothjochen@gmail.com>
      Reviewed-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
      2cba0bac
  36. 20 May, 2021 1 commit
  37. 27 Apr, 2021 1 commit
  38. 12 Apr, 2021 1 commit