Skip to content

Media: Demonstrate multisite rejecting sideloaded sub-sizes by file type - #15859

Draft
desrosj wants to merge 1 commit into
WordPress:trunkfrom
desrosj:test/csm-multisite-sideload-file-types
Draft

desrosj wants to merge 1 commit into
WordPress:trunkfrom
desrosj:test/csm-multisite-sideload-file-types

Conversation

@desrosj

@desrosj desrosj commented Nov 10, 2026

Copy link
Copy Markdown
Member

Adds two multisite tests showing that client-side media processing rejects sub-sizes the server would have generated itself, when they are in an output format the network does not allow for upload.

  • test_server_sub_sizes_in_output_format_not_allowed_by_network() (passes): with upload_filetypes set to jpg jpeg png gif and an image_editor_output_format filter mapping JPEG to WebP, the image editor writes a WebP thumbnail. Sub-sizes go straight to disk, so the network's file types never apply.
  • test_sideload_sub_size_in_output_format_not_allowed_by_network() (fails): the same WebP thumbnail, sideloaded as the browser would after transcoding it to image_output_format, is checked against the allowed types and rejected:
{"code":"rest_upload_sideload_error","message":"Sorry, you are not allowed to upload this file type.","data":{"status":500}}

Networks created before WordPress 5.8 have no webp in upload_filetypes (and none before 6.5 have avif), and upgrades never add them. On those networks, every sub-size of a JPEG upload fails with a WebP or AVIF output plugin active, so the whole upload fails.

The tests are tagged ms-required. To run them: npm run test:php -- -c tests/phpunit/multisite.xml --filter not_allowed_by_network

Tests only, no fix yet. One option is to allow the attachment's own image_output_format during a sideload.

Trac ticket: TBD

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 5.5
Used for: Investigating the issue while reviewing #15512, and drafting the tests and this description. To be reviewed by me.

🤖 Generated with Claude Code


This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

…ype.

On the classic path, the image editor writes sub-sizes to disk directly, so a network that does not allow WebP uploads still gets WebP sub-sizes when `image_editor_output_format` asks for them. With client-side media processing, the browser transcodes each sub-size to that format and sideloads it, and the sideload is checked against the network's allowed upload file types, so it is rejected with "Sorry, you are not allowed to upload this file type."

Networks created before WordPress 5.8 have no `webp` in `upload_filetypes`, and upgrades never add it.

The first test is the classic baseline and passes. The second fails until the sideload endpoint allows the attachment's own output format.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant