Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

_wp_attachment_metadata.sizes is empty for REST API uploads, but populated correctly when uploading via wp-admin

Đang mở
  • Có gì không ổn?
#222 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
38/100
Loại issue
Lỗi
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Ít trao đổi
Công nghệ
azure, php, wordpress
Lĩnh vực
api, backend, cloud

Hướng nghiên cứu

Bắt đầu bằng cách tái hiện POST /wp/v2/media với cùng một hình ảnh và so sánh metadata của tệp đính kèm với đường dẫn tải lên của wp-admin. Theo dõi nơi REST upload lưu _wp_attachment_metadata sau khi các biến thể được tạo, sử dụng các tệp cục bộ và Azure Blob làm bằng chứng. Được xem là hoàn tất khi media_details bao gồm các kích thước đã tạo, width và height đối với REST upload.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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

  1. Upload an image using POST /wp/v2/media.
  2. Inspect the response.
  3. Observe that media_details.sizes is an empty object ({}).
  4. Verify that the variant image files exist in both:
  • wp-content/uploads
  • Azure Blob Storage
  1. Upload the same image through the wp-admin Media Library.
  2. 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?

Ngôn ngữ chính
HCL
Star
139
Fork
84
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của Azure/wordpress-linux-appservice

Tất cả issue của Azure/wordpress-linux-appservice

Issue tương tự

Thêm issue về Backend & API Design

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.