Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
#222 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
38/100
issue の種類
バグ
明瞭さ
説明が足りない
活発さ
静か
技術スタック
azure, php, wordpress
領域
api, backend, cloud

調査の方向性

まず、同じ画像で 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

  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?

主要言語
HCL
スター
139
フォーク
84
PR マージ指標
30日以内にマージされた PR はありません

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

Azure/wordpress-linux-appservice のほかの issue

Azure/wordpress-linux-appservice の issue をすべて見る

似ている issue

Backend & API Design の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。