Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

New media uploads are offloaded while Image Storage rollback is active

Abierto
  • ¿Algo no está bien?
#1,159 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
56/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
php, wordpress
Área
backend, cloud

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug-report bug-report-triage customer report regression

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)

Lenguaje dominante
PHP
Estrellas
73
Forks
14
Merge medio
2 d 13 h
PR fusionados (30 d)
16

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Codeinwp/optimole-wp

Todos los issues de Codeinwp/optimole-wp

Issues similares

Más issues de PHP

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.