_wp_attachment_metadata.sizes is empty for REST API uploads, but populated correctly when uploading via wp-admin
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 38/100
调研方向
首先，使用同一张图片重现 POST /wp/v2/media，并将其附件元数据与 wp-admin 上传路径进行比较。跟踪 REST 上传在生成变体后将 _wp_attachment_metadata 持久化到何处，并以本地文件和 Azure Blob 文件作为证据。对于 REST 上传，当 media_details 包含生成的尺寸、width 和 height 时，即表示完成。
由索引模型根据 Issue 内容生成。
描述
Environment
WordPress: 7.0.2
PHP: 8.3.29 (fpm-fcgi)
Server: Linux 6.6.139.1-1.azl3 x86_64
Web Server: nginx 1.28.0
Hosting: Azure App Service
Upload method under investigation: POST /wp/v2/media
Description
When uploading images through the REST API (POST /wp/v2/media), the image variants (thumbnail, medium, large, etc.) are successfully generated and written to both the local wp-content/uploads directory and Azure Blob Storage.
However, the attachment metadata returned by the REST API contains an empty sizes array:
"media_details": {
"sizes": {}
}
The key point is that uploading the exact same image through the standard wp-admin Media Library uploader works as expected:
Image variants are generated.
_wp_attachment_metadata['sizes'] is correctly populated.
The REST API subsequently returns the expected media_details.sizes.
This suggests the issue is specific to the REST API upload path rather than image generation itself, as the same server, PHP configuration, image editor, and storage backend all work correctly through the admin uploader.
Steps to Reproduce
- Upload an image using POST /wp/v2/media.
- Inspect the response.
- Observe that media_details.sizes is an empty object ({}).
- Verify that the variant image files exist in both:
- wp-content/uploads
- Azure Blob Storage
- Upload the same image through the wp-admin Media Library.
- Observe that media_details.sizes is correctly populated.
Expected Behaviour
media_details.sizes should contain the generated image variants regardless of whether the image was uploaded through the REST API or via wp-admin.
Actual Behaviour
When uploaded via the REST API:
✅ Image variants are physically generated.
✅ Variant files exist locally and in Azure Blob Storage.
❌ _wp_attachment_metadata['sizes'] is empty.
❌ media_details.sizes in the REST response is {}.
When uploaded through wp-admin:
✅ Image variants are generated.
✅ _wp_attachment_metadata['sizes'] is populated correctly.
✅ media_details.sizes is returned as expected.
Question
Does anyone have any ideas what could be causing this behaviour?
When uploading via the REST API (POST /wp/v2/media), the image variants are physically generated and stored correctly, but _wp_attachment_metadata['sizes'] is empty. As a result, the REST response also returns an empty media_details.sizes, and even the top-level width and height values in media_details are empty.
Uploading the exact same image via wp-admin correctly populates all of this metadata.
Is there a known reason why the metadata would not be populated when uploading through the REST API, even though the variant images are successfully generated?
- 主要语言
- HCL
- 星标
- 139
- 派生
- 84
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
Azure/wordpress-linux-appservice 的其他 Issue
-
难度 1/5 1-3 小时 新手友好度 68/100
Azure/wordpress-linux-appservice#220 · 1 条评论 · 1 个 reaction ·
-
难度 2/5 1-3 小时 新手友好度 72/100
-
难度 3/5 1-2 天 新手友好度 48/100
Azure/wordpress-linux-appservice#223 · 3 条评论 ·
-
难度 3/5 1-2 天 新手友好度 48/100
-
难度 5/5 一周以上 新手友好度 25/100
查看 Azure/wordpress-linux-appservice 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 68/100
run-llama/llama_index#23278 ·
维护者通常 2 天内回复
-
from-review-extraction priority: low python severity:nit
难度 2/5 1-3 小时 新手友好度 90/100
LearningCircuit/local-deep-research#6944 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
iMicknl/python-overkiz-api#2263 ·
维护者通常 7 天内回复
-
难度 2/5 1-3 小时 新手友好度 88/100
meshery/meshery#22119 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
sgl-project/sglang#41482 ·
维护者通常 1 天内回复