New media uploads are offloaded while Image Storage rollback is active

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.

Status (2026-10-11)

Fixed in PR #1174 (bugfix/1159 → development, approved by pirate-bot at aed92868).

• Fix: while an Image Storage rollback runs, new uploads stay in the media library. The hook that offloads a new upload, and the filename deduplication that goes with it, are now registered only while Image Storage is on. Offloaded images keep being served from Optimole during the rollback, as before.
• Tests: with a rollback in progress, neither hook is registered and a new upload keeps a local file. The test fails on development.
• To know: an upload made during a rollback keeps its local file; a not-yet-restored image with the same name in the same month folder is then restored with a -1 suffix.
• Not proven: on a live connected site (the local test site is not connected to Optimole).

---

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:

1. Enable Optimole Image Storage offloading and offload at least one image.
2. Start Rollback so rollback_status becomes enabled and offload_media becomes disabled.
3. While rollback remains active, upload a new image to the WordPress Media Library.
4. 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 sets rollback_status to enabled and offload_media to disabled before 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 registers generate_image_meta() on wp_generate_attachment_metadata whenever is_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 723d891d57cf66713ad73cca58ca1e61725743e0 changed rollback to satisfy is_offload_enabled() and first appears in tag v3.11.1; tag containment confirms the behavior remains through v4.2.14. The preceding implementation only registered these hooks when offload_media itself 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.14 by 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.0 and v3.11.1 to 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)