New media uploads are offloaded while Image Storage rollback is active
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 56/100
Direzione di ricerca
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.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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)
- Lingua principale
- PHP
- Stelle
- 73
- Fork
- 14
- Merge medio
- 2g 13h
- PR unite (30g)
- 16
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di Codeinwp/optimole-wp
-
bug-report bug-report-triage crash-report
Difficoltà 4/5 3-5 giorni Idoneità per principianti 65/100
Codeinwp/optimole-wp#1162 ·
I maintainer di solito rispondono entro 1 giorno
-
customer report feature-request-triage
Difficoltà 3/5 1-2 giorni Idoneità per principianti 65/100
Codeinwp/optimole-wp#1161 ·
I maintainer di solito rispondono entro 1 giorno
-
customer report feature-request-triage
Difficoltà 3/5 1-2 giorni Idoneità per principianti 55/100
Codeinwp/optimole-wp#1151 ·
I maintainer di solito rispondono entro 1 giorno
-
bug-report bug-report-triage crash-report
Difficoltà 4/5 3-5 giorni Idoneità per principianti 55/100
Codeinwp/optimole-wp#1139 ·
I maintainer di solito rispondono entro 1 giorno
-
bug-report bug-report-triage customer report
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
Codeinwp/optimole-wp#1136 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di Codeinwp/optimole-wp
Issue simili
-
Update the one-click "GTM4WP" Delay JS exclusion so that it also works with a custom data layer nameAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
I maintainer di solito rispondono entro 1 giorno
-
[Feature]: Remove Kanboard Discourse forum link from README.md and CONTRIBUTING.md, or moderate itAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
-
bug Localization
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
solana-foundation/pay-kit#341 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
cline/cline#14560 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno