Offloaded attachment download resolves to a missing local file
Maintainer thường phản hồi trong vòng 1 ngày
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
- 52/100
Hướng nghiên cứu
Bắt đầu với Optml_Media_Offload::generate_image_meta(), add_new_actions() và alter_attached_file_response() trong inc/media_offload.php. Chạy composer phpunit -- tests/test-media.php, sau đó tái hiện tác vụ tải xuống của WordPress hoặc extension bằng một tệp đính kèm vừa được offload. Hoàn tất khi workflow tải xuống đã được bao phủ và không còn báo thiếu tệp cục bộ, trong khi các kiểm thử offload và rollback hiện có vẫn hợp lệ.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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:
- Keep Optimole active with Image Storage/offloading in use.
- Upload an image through WordPress.
- Attempt to download the uploaded attachment.
- 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 remoteid:path in attachment metadata.inc/media_offload.php—Optml_Media_Offload::add_new_actions()lines 2654–2701 registersalter_attached_file_response()globally onget_attached_filefor 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 thatget_attached_file()resolves to a path that does not exist after processing.- Commit
31022521introducedalter_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.phpwith 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)
- Ngôn ngữ chính
- PHP
- Star
- 73
- Fork
- 14
- Merge trung bình
- 2 ngày 13 giờ
- Pull request đã merge (30 ngày)
- 16
Chuẩn bị môi trường
- Có Dockerfile hoặc tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- 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.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của Codeinwp/optimole-wp
-
bug-report bug-report-triage crash-report
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 65/100
Codeinwp/optimole-wp#1162 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
customer report feature-request-triage
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 65/100
Codeinwp/optimole-wp#1161 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug-report bug-report-triage customer report regression
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 56/100
Codeinwp/optimole-wp#1159 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
customer report feature-request-triage
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 55/100
Codeinwp/optimole-wp#1151 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug-report bug-report-triage crash-report
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 55/100
Codeinwp/optimole-wp#1139 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của Codeinwp/optimole-wp
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
-
domain/crm-after-sales Platform(Default) priority/high
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
kind/bug status/to verify
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
PHP-CS-Fixer/PHP-CS-Fixer#9867 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
sync-en
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 86/100
Maintainer thường phản hồi trong vòng 2 ngày
-
sync-en
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 88/100
Maintainer thường phản hồi trong vòng 2 ngày