Skip to content
Snippets Groups Projects
  1. Dec 22, 2023
  2. Dec 21, 2023
  3. Dec 20, 2023
  4. Dec 19, 2023
    • Stefan Bürk's avatar
      [TASK] Ensure removing dangling images works with podman · 9fa175c0
      Stefan Bürk authored
      The TYPO3 core `runTests.sh` contains the `-u` option to
      update the images and remove dangling images. Providing
      an image name and a `--filter` option is not supported
      by podman:
       > Error: cannot specify an image and a filter(s)
       and has not been discovered yet in the TYPO3
      core implementation yet.
      
      Both container runtimes `docker` and `podman` support filtering images
      using the `reference` filter option. Therefore, this change modifies
      the dangling image removal to use multiple filters
      
      To verify that filtering with two `--filter` options can be used with
      podman and docker, the following commands can be executed to list the
      set of local non-dangling images.
      
      Note: This example uses `dangling=false` instead of
      	  `dangling=true` (as in `runTests.sh`), since we expect
            most developers don't have dangling images yet.
      
      > podman images \
          --filter "reference=ghcr.io/typo3/core-testing-*" \
          --filter "dangling=false" --format "{{.ID}}"
      
      > docker images \
          --filter "reference=ghcr.io/typo3/core-testing-*" \
          --filter "dangling=false" --format "{{.ID}}"
      
      Resolves: #102697
      Releases: main, 12.4, 11.5
      Change-Id: I717d1aa229bdfb73c63aa5b2d46e1aff665544cb
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/82235
      
      
      Tested-by: default avatarcore-ci <typo3@b13.com>
      Tested-by: default avatarStefan Bürk <stefan@buerk.tech>
      Reviewed-by: default avatarStefan Bürk <stefan@buerk.tech>
      9fa175c0
    • Garvin Hicking's avatar
      [BUGFIX] No "update storage index" FAL task fail with too many records · 390092d8
      Garvin Hicking authored
      The Indexer builds a large array of all actual files on a storage
      (identifiedFileUids). If many files exists, this array can get
      very large.
      
      This array was then passed to a QueryBuilder to fetch all
      records NOT IN that array. Since a NOT IN query is passed as a
      string to the database, it can exceed the string size allowed
      in a query, making the whole task fail.
      
      Since a NOT IN query cannot be chunked easily, the whole
      logic has been adapted in a different way.
      
      Instead of fetching a restricted list of database records,
      all records are fetched and iterated. Even with a million
      of sys_file_records of a single (!) storage this will
      perform alright, and be within practical usage scenarios.
      
      Each database record is then checked for a match in the
      large array of known records, and then execute the
      same logic as before.
      
      To benchmark the implications, the following test was run:
      
      Baseline:
      
      * sys_file with 50.736 entries
        * 16.912 marked as missing
        * 33.824 marked as existing
      * Filesystem with 8.771 actual files
      
      Tested setup via a script which:
      
      * Resets to baseline sys_file storage
      * Executes scheduler task "File Abstraction Layer: Update storage index
        (scheduler)"
      * Flags 41.965 files as missing, 8.771 as found.
      
      Script execution was performed 50 times, and a mean avery was calculated,
      once once with the patch in place, once without.
      
      Old variant (using NOT IN query): 11.787 seconds
      New variant (fetching all records): 12.0544 seconds
      
      On top of being within the same performance level, using the new method,
      no database exception will be provoked (see ticket).
      
      Resolves: #102295
      Releases: main, 12.4
      Change-Id: Id998d7cd062fe75aac738b896bfb307b51f5cef8
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/82237
      
      
      Tested-by: default avatarStefan Bürk <stefan@buerk.tech>
      Reviewed-by: default avatarStefan Bürk <stefan@buerk.tech>
      Tested-by: default avatarcore-ci <typo3@b13.com>
      390092d8
    • Benjamin Franzke's avatar
      [TASK] Sanitize embedded HTML in Installation-Wide Configuration GUI · 5e2a9d4e
      Benjamin Franzke authored
      Input data is statically provided by EXT:core only, so there is no
      security issue known right now. This change is a preparation to avoid
      possible future security issues.
      
      Resolves: #102676
      Releases: main, 12.4, 11.5
      Change-Id: I49a7fdd250e8ce74fdde07ad305cbae7e4af8ec3
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/82234
      
      
      Tested-by: default avatarOliver Bartsch <bo@cedev.de>
      Tested-by: default avatarcore-ci <typo3@b13.com>
      Reviewed-by: default avatarOliver Bartsch <bo@cedev.de>
      5e2a9d4e
    • Stefan Bürk's avatar
      [BUGFIX] Avoid type errors in `ResourceFactory` methods · 48d746eb
      Stefan Bürk authored
      With #92289 logic has been decoupled from `ResourceFactory`
      into the `StorageRepository`. As a side change, native php
      types have been added to a couple of methods.
      
      `StorageRepository->findByUid()` parameter type has been set
      to integer, which breaks the `null` fallback and retrieving
      the default storage `uid: 0` in `ResourceFactory` method
      `getStorageObjectFromCombinedIdentifier()`. Even worse is
      the fact that `getObjectFromCombinedIdentifier()` does not
      even try to cope with a invalid identifier provided.
      
      This change modifies `getObjectFromCombinedIdentifier()` and
      `getStorageObjectFromCombinedIdentifier` of `ResourceFactory`
      to cope with missing storage identifier by falling back to
      the default storage (`0`) with a shuffle of the exploded values.
      
      As a side-effect two PHPStan ignore patterns can be removed
      from the PHPStan baseline file.
      
      Used command(s):
      
        Build/Scripts/runTests.sh -s phpstanGenerateBaseline
      
      Resolves: #102692
      Related: #92289
      Releases: main, 12.4, 11.5
      Change-Id: I8ee9736839f59db7917cb49dd0d62af17ee28cda
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/82232
      
      
      Tested-by: default avatarcore-ci <typo3@b13.com>
      Tested-by: default avatarStefan Bürk <stefan@buerk.tech>
      Reviewed-by: default avatarStefan Bürk <stefan@buerk.tech>
      48d746eb
  5. Dec 18, 2023
  6. Dec 17, 2023
  7. Dec 16, 2023
  8. Dec 15, 2023
    • Oliver Bartsch's avatar
      [BUGFIX] Properly handle module access for workspaces · 3f25e7ff
      Oliver Bartsch authored
      This fixes a couple of workspace related issues
      in the module access evaluation.
      
      Basically, it's now ensured that the user will
      never be confronted with an exception for cases
      where he is in a module, which is not allowed in
      a workspace and then switches the workspace.
      
      This also applies for deep links. Therefore, the
      the start module evaluation, taking the redirect
      into account, is now respecting the fact that the
      given module might be temporarily not accessible.
      
      Finally the inheritance of the workspace access
      restriction is restored by changing the default
      value in the BaseModule and respecting the parent
      module's configuration for sub modules in the
      access check. Previously it was possible to
      access such sub modules, e.g. the site configuration
      module in a workspace by using a deep link.
      
      Resolves: #102665
      Releases: main, 12.4
      Change-Id: I1daabcd9d6b1cb9782a96c7c02ae0bf285369ede
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/82124
      
      
      Tested-by: default avatarcore-ci <typo3@b13.com>
      Tested-by: default avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: default avatarOliver Bartsch <bo@cedev.de>
      3f25e7ff
  9. Dec 14, 2023
  10. Dec 13, 2023
    • Nikita Hovratov's avatar
      [TASK] Extract registration of controller actions into separate method · e4105ace
      Nikita Hovratov authored
      EU::configurePlugin tightly couples registration of controller actions
      and TypoScript generation for a frontend rendering definition.
      Furthermore, lib.contentElement is only defined in fluid_styled_content,
      which makes it an indirect requirement.
      
      This patch extracts the part for the controller action registration, so
      it can be used independently of fluid_styled_content. In addition, this
      new method expects the controller actions to have an array shape
      already. A converter method ensures compatibility for both string and
      array syntax.
      
      A concrete use-case for internal usage would be Content Blocks, as it
      would be possible to separately define a Content Block of type "Plugin"
      and in addition register controller actions for it.
      
      Resolves: #102643
      Releases: main, 12.4
      Change-Id: I74d84f54bdd399934b57b3e49e2209f62b5fda68
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/82181
      
      
      Reviewed-by: default avatarOliver Bartsch <bo@cedev.de>
      Tested-by: default avatarOliver Bartsch <bo@cedev.de>
      Tested-by: default avatarcore-ci <typo3@b13.com>
      e4105ace
  11. Dec 12, 2023
    • Oliver Bartsch's avatar
      [BUGFIX] Expose import file in BeforeImportEvent · 12f67268
      Oliver Bartsch authored
      The file being about to be imported is
      now exposed in the BeforeImportEvent.
      
      This information might be quite relevant for
      event listeners to decide about modifications
      to the `Import` instance.
      
      Resolves: #102657
      Releases: main, 12.4
      Change-Id: I03c2493b7beda4d07e17d1112117d090f0fae545
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/82122
      
      
      Reviewed-by: default avatarOliver Bartsch <bo@cedev.de>
      Tested-by: default avatarOliver Bartsch <bo@cedev.de>
      Tested-by: default avatarcore-ci <typo3@b13.com>
      12f67268
    • Thomas Hohn's avatar
      [BUGFIX] Avoid exception on trailing comma in include_static_file.txt · a26f2dbe
      Thomas Hohn authored
      If an entry in the include_static_file.txt file contains a trailing
      comma, a RuntimeException (1651137904) is thrown. The problem is a
      check whether the path contains 'EXT:', in this case the second path
      is an empty string and hence the exception is thrown.
      
      The change removes empty strings when splitting the entries in the
      file by comma.
      
      Resolves: #102659
      Releases: main, 12.4
      Change-Id: Ic2290b0b153487c7e982b4bca6b220a6bb9abf55
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/82121
      
      
      Tested-by: default avatarBenni Mack <benni@typo3.org>
      Tested-by: default avatarcore-ci <typo3@b13.com>
      Reviewed-by: default avatarBenni Mack <benni@typo3.org>
      a26f2dbe
    • Benni Mack's avatar
      [TASK] Set TYPO3 version to 12.4.10-dev · 731e9acb
      Benni Mack authored
      Change-Id: I05fb7181a26e6bc6cae3696fc037491e49f0892e
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/82177
      
      
      Tested-by: default avatarBenni Mack <benni@typo3.org>
      Tested-by: default avatarcore-ci <typo3@b13.com>
      Reviewed-by: default avatarBenni Mack <benni@typo3.org>
      731e9acb
    • 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 \
              @ckeditor/ckeditor5-paragraph@^40.2.0 \
              @ckeditor/ckeditor5-paste-from-office@^40.2.0 \
              @ckeditor/ckeditor5-remove-format@^40.2.0 \
              @ckeditor/ckeditor5-show-blocks@^40.2.0 \
              @ckeditor/ckeditor5-source-editing@^40.2.0 \
              @ckeditor/ckeditor5-special-characters@^40.2.0 \
              @ckeditor/ckeditor5-style@^40.2.0 \
              @ckeditor/ckeditor5-table@^40.2.0 \
              @ckeditor/ckeditor5-theme-lark@^40.2.0 \
              @ckeditor/ckeditor5-ui@^40.2.0 \
              @ckeditor/ckeditor5-undo@^40.2.0 \
              @ckeditor/ckeditor5-utils@^40.2.0 \
              @ckeditor/ckeditor5-word-count@^40.2.0
          npm run build
      
      Resolves: #102654
      Releases: main, 12.4
      Change-Id: I4a7a7596897cd346583bcca5d64824a437d8a710
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/82173
      
      
      Tested-by: default avatarBenjamin Franzke <ben@bnf.dev>
      Reviewed-by: default avatarBenjamin Franzke <ben@bnf.dev>
      Tested-by: default avatarcore-ci <typo3@b13.com>
      14f16d9b
  12. 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
  13. Dec 09, 2023
  14. Dec 08, 2023
  15. Dec 07, 2023