Skip to content
Snippets Groups Projects
  1. Dec 12, 2023
    • Benni Mack's avatar
      [RELEASE] Release of TYPO3 12.4.9 · 09d18800
      Benni Mack authored
      Change-Id: I4d979c9bdd1305a8bca8a2c36f70bc054d3d6ce3
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/82176
      
      
      Reviewed-by: default avatarBenni Mack <benni@typo3.org>
      Tested-by: default avatarBenni Mack <benni@typo3.org>
      v12.4.9
      09d18800
    • Oliver Hader's avatar
      [BUGFIX] Ignore l10n_state when detaching localization parent · 07c49ed7
      Oliver Hader authored
      When an exisiting localization (sys_language_uid>0 and l10n_parent>0)
      shall be detached (l10n_parent=0), the processing the l10n_state value
      was skipped - basically since the processor assumes no adjustments
      would be required.
      
      The state is provided by FormEngine and is expected to be serialized
      to JSON again in DataMapProcessor - in this case, the modifications
      are just skipped as well.
      
      Resolves: #102623
      Releases: main, 12.4
      Change-Id: Ifb400924fbdd8dcc20b8ff15d3b870507141b612
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/82170
      
      
      Tested-by: default avatarcore-ci <typo3@b13.com>
      Tested-by: default avatarOliver Hader <oliver.hader@typo3.org>
      Reviewed-by: default avatarOliver Hader <oliver.hader@typo3.org>
      07c49ed7
    • Benjamin Franzke's avatar
      [BUGFIX] Avoid <o:p> tags pasted from MS Word into CKEditor5 · 91caafd6
      Benjamin Franzke authored
      With #99738 the option to allow all classes has been reenabled,
      which implicitly caused all custom html elements to be allowed:
      
      ```
          htmlSupport:
            allow:
              - { classes: true, attributes: { pattern: 'data-.+' } }
      ```
      
      The rule matched to any HTML element available in the CKEditor5 General
      HTML Support (GHS) schema definition, including the pseudo element
      `'$customElement'` that acts as placeholder for custom elements,
      because the omitted `name` matcher implicitly acted like a match-all
      (`.*`) pattern.
      
      This became an issue, since `@ckeditor/ckeditor5-paste-from-office`
      relies on the fact, that the pasted HTML is sanitized by GHS.
      Namespaced tags like `<o:p>` (which the desktop version of microsoft
      office likes to include when using copy&paste) where now allowed.
      
      To account for this behavior we change two things:
      
      1) We drop the default allow-list configuration that was added in
         v12.4.7, since the negative side effects outweighed the benefits:
         * All HTML Tags where implicitly allowed, which allowed any tags,
           even custom elements to be inserted via copy&paste or via source
           editor
         * All classes were enabled, thus custom Microsoft office classes
           started to pollute the HTML sources.
         * The configuration could not be removed/changed by an integrator
           since htmlSuppot.allow is an array and was therefore only appended,
           but never overwritten by custom RTE configurations
      
        We considered to switch to a name pattern like `[a-z]+` in our default
        configuration but decided against that because that'd still allow all
        other official HTML elements which is not good default, given that it
        can't be changed as described above.
      
      2) We now restrict migrated CKEditor v4 (extra)allowedContent
         (e.g. `extraAllowedContent: *[*](*){*}`) match-all-elements
         directives (first asterisk in the example) to plain selectors in
         order to exclude custom or namespaced elements like `<o:p>`.
         We therefore migrate to a matcher pattern `[a-z]+` in order for the
         virtual custom-element entry `'$customElement'` to become a no-match.
      
      Integrators are actually expected to define the set of allowed classes
      with the CKEditor5 `style.definitions[]` configuration array.
      
      Releases: main, 12.4
      Resolves: #102507
      Resolves: #102522
      Related: #99738
      Change-Id: I904f906b7cbbdf5d5f1b3ff23d2b1c62abbcf174
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/81995
      
      
      Tested-by: default avatarBenjamin Franzke <ben@bnf.dev>
      Tested-by: default avatarcore-ci <typo3@b13.com>
      Reviewed-by: default avatarBenjamin Franzke <ben@bnf.dev>
      91caafd6
    • Andreas Kienast's avatar
      [TASK] Update ckeditor5 to v40.2 · 14f16d9b
      Andreas Kienast authored
      This commit updates ckeditor5 to v40. See changelog at
      https://github.com/ckeditor/ckeditor5/releases/tag/v40.2.0.
      
      Executed commands:
      
          npm i --save \
              @ckeditor/ckeditor5-alignment@^40.2.0 \
              @ckeditor/ckeditor5-autoformat@^40.2.0 \
              @ckeditor/ckeditor5-basic-styles@^40.2.0 \
              @ckeditor/ckeditor5-block-quote@^40.2.0 \
              @ckeditor/ckeditor5-clipboard@^40.2.0 \
              @ckeditor/ckeditor5-code-block@^40.2.0 \
              @ckeditor/ckeditor5-core@^40.2.0 \
              @ckeditor/ckeditor5-editor-classic@^40.2.0 \
              @ckeditor/ckeditor5-engine@^40.2.0 \
              @ckeditor/ckeditor5-essentials@^40.2.0 \
              @ckeditor/ckeditor5-find-and-replace@^40.2.0 \
              @ckeditor/ckeditor5-heading@^40.2.0 \
              @ckeditor/ckeditor5-horizontal-line@^40.2.0 \
              @ckeditor/ckeditor5-html-support@^40.2.0 \
              @ckeditor/ckeditor5-indent@^40.2.0 \
              @ckeditor/ckeditor5-link@^40.2.0 \
              @ckeditor/ckeditor5-list@^40.2.0 \
              @c...
      14f16d9b
  2. Dec 11, 2023
    • Daniel Siepmann's avatar
      [BUGFIX] Use proper editor.css path within TYPO3 · d3b26dc0
      Daniel Siepmann authored
      GeneralUtility::createVersionNumberedFilename() will process the
      provided path. It will execute a file_exists check. The file therefore
      needs to be resolvable. Applying getPublicResourceWebPath() beforehand
      will result in a web url, which can not be resolved on file system
      level.
      We therefore remove the unnecessary getPublicResourceWebPath() call.
      createVersionNumberedFilename() will resolve EXT: paths anyway.
      
      That way TYPO3 can properly handle the file and add the corresponding
      version number if configured.
      Furthermore this resolves open_basedir restriction issues on configured
      systems.
      
      Resolves: #102619
      Releases: main, 12.4
      Change-Id: I22dbd2187ee302e9cc1194c0522421fafab3938a
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/82120
      
      
      Tested-by: default avatarcore-ci <typo3@b13.com>
      Tested-by: default avatarBenjamin Franzke <ben@bnf.dev>
      Reviewed-by: default avatarBenjamin Franzke <ben@bnf.dev>
      d3b26dc0
    • Benjamin Franzke's avatar
      [BUGFIX] Fix link-element initialization race condition · 1f5e344b
      Benjamin Franzke authored
      Children of custom elements are not guaranteed to be available by the
      time the element is added to the DOM — i.e. when the connectedCallback()
      is triggered by the browser. That means we can not assume that all
      child elements will already be available. See #102550 for details.
      
      To circumvent this race we make use of HTML event bubbling. That means
      we register our event handlers on the wrapper element and will
      receive events that are triggered on one of the children elements.
      To circumvent the initialization race conditions in connectedCallback()
      we shift the stateful initialization to the server-side rendering.
      
      Note that we either need to render html components server or client-side
      in order to avoid such race conditions or nasty workarounds (like adding
      mutation observs and keeping track whether all elements have already
      been added or not). Ideally the link-element component would be rendered
      fully client-side at some point, but that's out of scope for now.
      
      Resolves: #102603
      Related: #102550
      Releases: main, 12.4
      Change-Id: I54715fd671f717e4253ee41e8ac33a1ca5960eae
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/82169
      
      
      Reviewed-by: default avatarBenjamin Franzke <ben@bnf.dev>
      Tested-by: default avatarcore-ci <typo3@b13.com>
      Tested-by: default avatarBenjamin Franzke <ben@bnf.dev>
      1f5e344b
  3. Dec 09, 2023
  4. Dec 08, 2023
  5. Dec 07, 2023
  6. Dec 06, 2023
  7. Dec 05, 2023
    • Stefan Froemken's avatar
      [BUGFIX] Set HTTP timeout to 20 seconds · 0df3196a
      Stefan Froemken authored
      To prevent infinite outgoing requests
      while using RequestFactory which will exceed
      max_execution_time limitation we reduce
      timeout to 20 seconds.
      
      Resolves: #102606
      Releases: main, 12.4
      Change-Id: I6ba432a63b6e093566f407663db13f5b4141146d
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/82025
      
      
      Reviewed-by: default avatarGeorg Ringer <georg.ringer@gmail.com>
      Tested-by: default avatarGeorg Ringer <georg.ringer@gmail.com>
      Tested-by: default avatarcore-ci <typo3@b13.com>
      0df3196a
    • Benni Mack's avatar
      [BUGFIX] Include records in Extbase without a l10n parent · 9ab43f07
      Benni Mack authored
      Within TYPO3's LanguageAspect there are four options for doing
      overlays:
      OVERLAYS_OFF -> fetch records in a specific language directly
      OVERLAYS_MIXED -> fetch default records + do overlays if available
      OVERLAYS_ON -> fetch default records + do overlays - discard if no overlay is available
      OVERLAYS_ON_WITH_FLOATING -> same as OVERLAYS_ON PLUS the records that have no l10n_parent.
      
      This change enables Extbase records to also be
      fetched when using LanguageAspect::OVERLAYS_ON_WIITH_FLOATING
      as floating records are the ones that do not have
      a l10n_parent set ("copy mode").
      
      Resolves: #87160
      Releases: main, 12.4
      Change-Id: I021efe3761efa63860eac5522af82fc20f0fe53f
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/82024
      
      
      Tested-by: default avatarcore-ci <typo3@b13.com>
      Tested-by: default avatarBenni Mack <benni@typo3.org>
      Reviewed-by: default avatarBenni Mack <benni@typo3.org>
      9ab43f07
    • Christian Kuhn's avatar
      [BUGFIX] Allow access to TypoScript overrides for labels in _LOCAL_LANG · 490f1269
      Christian Kuhn authored
      This bugfix enables the possibility to access _LOCAL_LANG
      values from TypoScript properly again via Extbase's
      LocalizationUtility, and thus for <f:translate> ViewHelpers
      as well again.
      
      This is what has changed under-the-hood:
      
      The TranslateViewHelper is now only a thin layer
      to Extbase's LocalizationUtility (as before), and only
      checks if a current request or Locale/languageKey is
      given, if a locale can be resolved. Everything else
      is then dispatched to the LocalizationUtility.
      
      <f:translate> is very clean now and has almost no further
      responsibility than to call LocalizationUtility::translate
      
      Instead of adding further LocalizationUtility magic,
      overriding of TypoScript is now enabled for any kind
      of plugin which hands in $extensionName. This is achieved
      by building proper Locale objects from the request which
      are then used to build the respective LanguageService.
      
      As it turned out after the 12.4.0 release, the "Locales"
      class is indeed the factory for creating a Locale, which
      is decoupled from the actual LanguageService (= label magic),
      the Locales factory receives a few create methods to make
      life easier for usage, which both f:translate AND
      LocalizationUtility receive, making their parts much smaller.
      
      Further work will dissolve the usage of the Configuration
      Manager of Extbase, but this won't happen in v12 anymore.
      
      Resolves: #100759
      Releases: main, 12.4
      Change-Id: Ifcad2ec590746e96066a96f314500bd50e9b4695
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/82023
      
      
      Tested-by: default avatarcore-ci <typo3@b13.com>
      Reviewed-by: default avatarBenni Mack <benni@typo3.org>
      Tested-by: default avatarBenni Mack <benni@typo3.org>
      490f1269
    • Oliver Hader's avatar
      [BUGFIX] Convert line break element in table element wizard · 7224dc1e
      Oliver Hader authored
      The table element wizard (TCA `renderType=textTable`) stores
      serialized table representation in a text field. Previously,
      the removed (see #95036) `TableController` substituted those
      newline characters by `<br>` tags.
      
      Since there is in general no handling of TCA render types,
      this conversion now happens in the corresponding LitElement.
      
      Resolves: #102572
      Releases: main, 12.4
      Change-Id: I12537b0d649ae28b945a2dc79baeb09a4a6135b1
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/82022
      
      
      Tested-by: default avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: default avatarOliver Bartsch <bo@cedev.de>
      Tested-by: default avatarcore-ci <typo3@b13.com>
      7224dc1e
  8. Dec 04, 2023
  9. Dec 02, 2023
  10. Dec 01, 2023
  11. Nov 30, 2023
  12. Nov 29, 2023