1. 11 May, 2022 1 commit
  2. 21 Apr, 2022 1 commit
  3. 18 Apr, 2022 1 commit
  4. 22 Mar, 2022 1 commit
  5. 15 Mar, 2022 1 commit
  6. 16 Feb, 2022 1 commit
    • 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
  7. 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
  8. 05 Feb, 2022 1 commit
  9. 02 Feb, 2022 1 commit
  10. 10 Nov, 2021 2 commits
  11. 04 Nov, 2021 1 commit
  12. 01 Oct, 2021 1 commit
  13. 24 Sep, 2021 2 commits
  14. 14 May, 2021 1 commit
  15. 13 May, 2021 1 commit
  16. 29 Mar, 2021 1 commit
  17. 19 Jan, 2021 1 commit
  18. 04 Jan, 2021 1 commit
  19. 19 Oct, 2020 1 commit
  20. 15 Apr, 2020 1 commit
  21. 14 Apr, 2020 1 commit
  22. 07 Oct, 2019 1 commit
  23. 14 Mar, 2019 1 commit
  24. 11 Aug, 2018 1 commit
  25. 18 Jul, 2018 1 commit
    • Christian Kuhn's avatar
      [FEATURE] Allow TCA description property · d421f7dc
      Christian Kuhn authored and Andreas Wolf's avatar Andreas Wolf committed
      When the site configuration module has been introduced, it came
      with a custom functionality to show an additional help text
      when editing site records between the field label and the field input.
      
      This useful feature is now changed into a general TCA feature
      available everywhere: A new field information node expansion / "wizard"
      is added to all form elements, the inline and flex containers: If
      the property "description" is set for a TCA column type (same array
      level as "label", it will show the value as localized string between
      the field label and the input section.
      
      There are three available render types for "wizard a-like" output:
      * Field information - text between label+field
      * Field control - buttons next to input sections like the link popup button
      * Field wizards - clickable stuff below the input section, for example
        the localization state selector
      If a field has been set to readOnly=true in TCA, field control and field
      wizards do not make sense to render since they are meant to act with the
      field value.
      The field information node however has only informational character
      which is useful for readOnly fields, too. Thus, this node expansion
      type is now the only one that is always rendered, even if a field has
      been set to readOnly.
      
      Note this patch is fully covered by ext:styleguide (master) to have
      examples for all changed elements now using the description property.
      
      Resolves: #85410
      Releases: master
      Change-Id: Idcfacafa19b8208614b653b8fac22ce47bca3b8f
      Reviewed-on: https://review.typo3.org/57397
      
      Tested-by: default avatarTYPO3com <no-reply@typo3.com>
      Reviewed-by: default avatarJörg Bösche <typo3@joergboesche.de>
      Tested-by: default avatarJörg Bösche <typo3@joergboesche.de>
      Reviewed-by: Andreas Wolf's avatarAndreas Wolf <andreas.wolf@typo3.org>
      Tested-by: Andreas Wolf's avatarAndreas Wolf <andreas.wolf@typo3.org>
      d421f7dc
  26. 17 May, 2018 1 commit
  27. 25 Apr, 2018 1 commit
  28. 01 Apr, 2018 1 commit
  29. 22 Nov, 2017 1 commit
  30. 12 May, 2017 1 commit
  31. 20 Apr, 2017 1 commit
  32. 11 Feb, 2017 1 commit
  33. 07 Feb, 2017 1 commit
    • Oliver Hader's avatar
      [FEATURE] Introduce allowLanguageSynchronization · 2fd70c83
      Oliver Hader authored and Christian Kuhn's avatar Christian Kuhn committed
      This feature introduces a new functionality called
      "allowLanguageSynchronization" which can be set on a field
      configuration of a TCA column. This is the successor of
      "l10n_mode=mergeIfNotBlank" as the old option had several
      conceptual downsides:
      
      1) "mergeIfNotBlank" took the value of the default record
         during runtime, but only if the translation field was empty.
         This means it was not possible to see what the record
         actually contained without having all fields of the parent
         at hand.
      
      2) It was not possible to have a value "santa" in the original
         record but remove the option in a translation (because an
         empty string "" implicitly triggered the runtime call in the
         frontend)
      
      3) "mergeIfNotBlank" did not work on relations except for files
         fetched via the FileRepository API calls, but for no other
         inline elements.
      
      4) "mergeIfNotBlank" did the overlay functionality in the frontend,
         but only FormEngine and DataHandler took care of the option.
         Custom backend modules had to implement the same functionality.
      
      5) In FormEngine, there was an icon in the translation record that
         if the record kept empty the value of the original language was
         taken, but this is not optimal in terms of usability.
      
      6) "mergeIfNotBlank" did not take the new l10n_source option into
         account, where localizations could be made from other records
         than the default language "0".
      
      The new feature can be set on any TCA column setting:
      
      $GLOBALS['TCA'][<table-name>]['columns']
      	[<field-name>]['config']['behaviour']
      		['allowLanguageSynchronization'] = true;
      
      This brings an option to records with translations (both from
      l10n_parent and l10n_source) to have the value for all translations
      synchronized or explictly have a checkbox to use a custom value.
      
      The information whether a field is custom filled, or kept in sync
      from l10n_parent/l10n_source is stored in a separate field called
      "l10n_state" inside the database.
      
      The introduced upgrade wizard and TCA migration to remove
      "l10n_mode=mergeIfNotBlank" has been modified to migrate to this
      option and add a l10n_state database field if a TCA table used
      "mergeIfNotBlank" but did not add the l10n_state field manually
      via ext_tables.sql yet.
      
      New extensions can easily use the new option right away,
      extensions that need to stay compatible with v7 and v8 can add
      both options right away to have the same output.
      
      The main goals to achieve with this change is now:
      
      * Have consistent database values for all records regardless
        of l10n_mode=mergeIfNotBlank paving the way to fetch translated
        records without having to overlay (once l10n_mode=exclude is
        also copying values and relations)
      * Be more explicit for editors about records that have a different
        or the same state as their l10n_parent/l10n_source as a benefit
        for bigger instances with a lot of languages
      * Avoid hidden magic when retrieving localized records in the
        TYPO3 Frontend.
      
      Resolves: #79658
      Related: #79243
      Releases: master
      Change-Id: I6c2dbfeb09b47f958a536c9ab050c24ba4bbcbbd
      Reviewed-on: https://review.typo3.org/51291
      
      Tested-by: default avatarTYPO3com <no-reply@typo3.com>
      Reviewed-by: Frans Saris's avatarFrans Saris <franssaris@gmail.com>
      Tested-by: Frans Saris's avatarFrans Saris <franssaris@gmail.com>
      Reviewed-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      Tested-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      2fd70c83
  34. 31 Jan, 2017 1 commit
  35. 26 Jan, 2017 1 commit
    • Christian Kuhn's avatar
      [!!!][FEATURE] FormEngine element level refactoring · 84be5e61
      Christian Kuhn authored
      The patch introduces a new API on FormEngine element level
      that substitutes the old "wizards" / renderWizard() API
      with a more powerful system.
      
      Single wizards are now split into one of three categories:
      * An informational wizard
      * A control button / icon
      * A true wizard with additonal functionality
      
      Method renderWizards() is still called in elements for compatibility
      reasons if people added own scrip/popup/userFunc wizards, but all
      core wizards are migrated.
      
      The patch significantly cleans the HTML of single elements, especially
      HTML stuff that was added by the SingleFieldContainer is now put down
      to single elements, while main HTML wraps formerly done by renderWizards()
      is fetched "up" to single elements. This gives single elements full
      control about the main HTML it is producing, which is a must have
      preparation in order to further advance in this area and to switch
      single elements to fluid rendering in one of the next steps.
      
      The patch brings a pretty huge list of TCA changes and
      simplifications, all TCA changes are supported by TCA migration,
      so existing extensions should benefit out of the box and just
      get deprecations logged.
      
      Change-Id: I45083e14e45bbf40c06267b51c9d0b7c15e2f7ab
      Resolves: #79440
      Resolves: #70032
      Releases: master
      Reviewed-on: https://review.typo3.org/51151
      
      Tested-by: default avatarTYPO3com <no-reply@typo3.com>
      Reviewed-by: Wouter Wolters's avatarWouter Wolters <typo3@wouterwolters.nl>
      Tested-by: Mona Muzaffar's avatarMona Muzaffar <mona.muzaffar@gmx.de>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      84be5e61
  36. 01 Dec, 2016 1 commit
  37. 09 Oct, 2016 1 commit
  38. 30 Aug, 2016 1 commit