New media uploads are offloaded while Image Storage rollback is active
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
- 56/100
Hướng nghiên cứu
Start with inc/settings.php and inc/media_offload.php, especially is_offload_enabled(), instance(), and generate_image_meta(). Review tests/test-media.php and its rollback coverage, then add coverage for a new attachment while rollback_status is enabled and offload_media is disabled. Done means new uploads no longer enter the offload path during rollback while existing rollback behavior remains covered.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Summary
Images added to the WordPress Media Library while an Image Storage rollback is active can still be transferred to Optimole Cloud. Starting rollback is expected to stop cloud offloading for new uploads while existing cloud images are restored locally. Instead, newly added media can continue entering the offload workflow, preventing users from reliably stopping additional cloud transfers during recovery.
Customer context
- Product / area: Optimole Pro, Image Storage rollback and media uploads
- Version: Unknown from the ticket; defect is present in inspected tag
v4.2.14 - Environment: WordPress; other environment details not provided
- Integration / third party: WordPress attachment metadata generation
- Reported error / symptom: Newly added images continue going to Optimole servers while rollback is in progress
- Impact: Additional media can be cloud-offloaded while the user is attempting to stop offloading and restore local files
Reproduction notes
Code-backed reproduction:
- Enable Optimole Image Storage offloading and offload at least one image.
- Start
Rollbacksorollback_statusbecomesenabledandoffload_mediabecomesdisabled. - While rollback remains active, upload a new image to the WordPress Media Library.
- Observe that the new attachment still enters Optimole’s metadata-generation/offload callback and can be transferred to cloud storage.
The source path is confirmed in v4.2.14; a controlled WordPress runtime reproduction was not performed.
Diagnosis
Conclusion
The plugin disables the offload_media setting when rollback starts, but treats any active rollback as equivalent to enabled offloading during bootstrap. This registers the attachment-metadata callback that uploads newly generated media to Optimole Cloud. The callback has no rollback-state guard, so a new image uploaded during rollback can follow the normal offload path. This directly matches the reported continued cloud uploads.
Where this likely occurs
assets/src/dashboard/parts/connected/settings/OffloadMedia.js—onRollbackdMedia()lines 138–160 setsrollback_statustoenabledandoffload_mediatodisabledbefore starting rollback.inc/settings.php—Optml_Settings::is_offload_enabled()lines 875–882 returns true when either offloading is enabled or rollback is active.inc/media_offload.php—Optml_Media_Offload::instance()lines 154–185 registersgenerate_image_meta()onwp_generate_attachment_metadatawheneveris_offload_enabled()is true.inc/media_offload.php—Optml_Media_Offload::generate_image_meta()lines 1289–1379 validates and prepares a newly generated attachment for cloud upload without distinguishing rollback from normal offload mode.- Git history: commit
723d891d57cf66713ad73cca58ca1e61725743e0changed rollback to satisfyis_offload_enabled()and first appears in tagv3.11.1; tag containment confirms the behavior remains throughv4.2.14. The preceding implementation only registered these hooks whenoffload_mediaitself was enabled.
Engineering notes
Rollback requires portions of the media-offload subsystem to remain available for restoring and rendering existing offloaded attachments. The inspected bootstrap gate groups URL handling, attachment rendering, post filtering, and new-upload processing under the same state check. The confirmed scope is new WordPress image attachments created while bulk rollback status is active; other upload mechanisms were not tested.
Test coverage status
tests/test-media.php includes successful rollback coverage in test_image_rollback() lines 348–358 and rollback scheduling/locking coverage at lines 643–741. No relevant coverage was found during inspection for creating a new attachment while rollback_status is enabled and offload_media is disabled.
What to verify or explore next
- May be worth reproducing on
v4.2.14by starting rollback, uploading one image through the Media Library, and checking its local file, attachment metadata, offload flags, and cloud record. - May be worth comparing the same workflow on
v3.11.0andv3.11.1to verify the identified release boundary at runtime. - If reproducible, checking uploads through the block editor, WooCommerce product media, and REST media endpoint could establish whether they share the attachment-metadata path.
Unknowns / follow-up
The customer’s installed plugin version and the exact upload interface are unknown. No runtime logs were provided, and WordPress core source was not inspected in this plugin-only workspace.
Confidence
Confidence: 96/100
Repository inspection confirms that new attachments can enter the cloud-offload path while rollback is active. The separate stalled-restoration report matches open issue #1108, which was read and already contains evidence from the linked parent HelpScout conversation.
Source: HelpScout #3458633804
Generated by bug-report-triage (ID: bug-report-triage_6ab26de1374543.30050428)
- 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
-
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
-
bug-report bug-report-triage customer report
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
Codeinwp/optimole-wp#1136 · 2 bình luận ·
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 68/100
Automattic/static-site-importer#1879 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/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 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
521xueweihan/HelloGitHub#3790 ·
-
[Bug] Feed date, title and author too long to fit inside article box on smaller screens, mobileĐang mởBug (unconfirmed) Good first issue 1️⃣ help wanted UI :art:
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
FreshRSS/FreshRSS#9360 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày