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

Offloaded attachment download resolves to a missing local file

オープン
  • 何か問題がありますか？
#1,119 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

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

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
52/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
php, wordpress
領域
backend

調査の方向性

inc/media_offload.php の Optml_Media_Offload::generate_image_meta()、add_new_actions()、alter_attached_file_response() から始めます。composer phpunit -- tests/test-media.php を実行し、その後、新たにオフロードした添付ファイルを使って WordPress または拡張機能のダウンロードアクションを再現します。ダウンロードワークフローがカバーされ、ローカルファイルが見つからないと報告されなくなり、既存のオフロードおよびロールバックのテストが引き続き有効であれば完了です。

索引モデルが issue の本文から書いたものです。

説明

bug-report bug-report-triage customer report

Summary

Downloading a newly offloaded WordPress attachment can return a file-not-found error. Expected behavior is for an offloaded attachment to remain downloadable. Actual behavior is that the attachment's local source has been removed while the download-facing file lookup resolves to a nonexistent local path, preventing administrators from retrieving the media.

Customer context

Product / area: Optimole WordPress plugin, Image Storage attachment downloads
Version: Customer version not provided; inspected source is 4.2.11
Environment: WordPress admin; browser and WordPress/PHP versions not provided
Integration / third party: Optimole cloud storage
Reported error / symptom: Downloading the newly uploaded attachment returns “file not found” while Optimole is active
Impact: Administrators cannot download affected offloaded attachments through workflows that consume the WordPress attached-file path

Reproduction notes

Reported reproduction:

  1. Keep Optimole active with Image Storage/offloading in use.
  2. Upload an image through WordPress.
  3. Attempt to download the uploaded attachment.
  4. Observe a “file not found” error.

Runtime reproduction was not performed, but the existing unit test and inspected source confirm that the filtered attached-file path does not exist after offload.

Diagnosis

Conclusion

The offload path removes the local source and rewrites attachment metadata to a remote marker. The globally registered get_attached_file filter then combines that remote metadata with the local uploads directory, producing a path for which the source confirms no local file exists. This directly matches the reported file-not-found download behavior. No matching GitHub issue was found.

Where this likely occurs
  • inc/media_offload.php — Optml_Media_Offload::generate_image_meta() lines 1478–1521 validates an Optimole URL, deletes the local source, and stores a remote id: path in attachment metadata.
  • inc/media_offload.php — Optml_Media_Offload::add_new_actions() lines 2654–2701 registers alter_attached_file_response() globally on get_attached_file for the new-offload path.
  • inc/media_offload.php — Optml_Media_Offload::alter_attached_file_response() lines 2715–2728 prefixes the local uploads directory to the remote metadata value.
  • tests/test-media.php — Test_Media::test_image_processed() lines 297–316 explicitly confirms that get_attached_file() resolves to a path that does not exist after processing.
  • Commit 31022521 introduced alter_attached_file_response() in the offloading-without-database-replacement work. Available history does not identify a release where this download path worked before breaking.
Engineering notes

The local deletion is intentional for Image Storage, but get_attached_file is a filesystem-path contract used by WordPress and extensions for attachment operations. The inspected filter is global despite its nearby comment discussing an Elementor file-existence check. The exact download controller used on the customer site is unknown, but any inspected workflow relying on this filtered local path encounters the absent file represented in the existing test.

Test coverage status

tests/test-media.php — Test_Media::test_image_processed() lines 297–316 and Test_Media::test_image_sync() lines 326–346 cover remote URL generation and explicitly assert local-file absence. Test_Media::test_image_rollback() lines 348–358 covers restoration. No relevant coverage was found during inspection for downloading an offloaded attachment or for a consumer requiring a readable result from get_attached_file().

What to verify or explore next
  • May be worth reproducing through the exact WordPress or extension download action that reports “file not found.”
  • May be worth running composer phpunit -- tests/test-media.php with a focused download consumer around a newly offloaded attachment.
  • Compatibility checks may be useful for core media actions and common attachment-download integrations that consume get_attached_file.
Unknowns / follow-up
  • The exact download UI or extension invoking the file lookup is not provided.
  • The customer's plugin version and attachment metadata are unavailable.

Confidence

Confidence: 95/100

Repository inspection independently confirms a stale offload-limit warning path and a missing local download target after offload. The blank-rendering symptom is credible but remains unconfirmed without the affected remote response or offloading logs.

Source: HelpScout #3431088020
Generated by bug-report-triage (ID: bug-report-triage_6a8f62001e0958.60696283)

主要言語
PHP
スター
73
フォーク
14
平均マージ
2日 13時間
マージ済み PR（30日）
16

環境構築

はじめの一歩

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

Codeinwp/optimole-wp のほかの issue

Codeinwp/optimole-wp の issue をすべて見る

似ている issue

PHP の issue をもっと見る

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

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