Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Offload-limit warning remains after account usage drops

Đang mở
  • Có gì không ổn?
#1,118 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

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
55/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
javascript, php, wordpress
Lĩnh vực
backend, frontend

Hướng nghiên cứu

Bắt đầu với Optml_Admin::daily_sync() trong inc/admin.php, sau đó lần theo các cài đặt đã được lưu trong inc/settings.php và phần hiển thị cảnh báo trong assets/src/dashboard/parts/connected/settings/OffloadMedia.js cùng assets/src/dashboard/utils/api.js. Xem xét tests/test-media.php và các đường dẫn quota-state trong inc/media_offload.php; hoàn tất khi mức sử dụng được cập nhật đồng bộ với cảnh báo đã lưu, để thông báo giới hạn không còn hiệu lực không xuất hiện nữa.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

bug-report bug-report-triage customer report

Summary

The WordPress Optimole settings can continue showing the offload-limit warning after account usage has fallen below the plan limit. Expected behavior is for refreshed account usage to clear an obsolete warning. Actual behavior is a persisted warning that displays the stored 50,000-image limit despite substantially lower dashboard usage, which can incorrectly indicate that further offloading is unavailable.

Customer context

Product / area: Optimole WordPress plugin, Image Storage offloading status
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 account service and dashboard
Reported error / symptom: Plugin shows a 50,000-images-offloaded warning while the account dashboard shows 1,181 assets
Impact: Administrators receive an inaccurate quota warning after deleting environments

Reproduction notes

Reported reproduction:

  1. Delete duplicate Optimole environments so account usage drops.
  2. Confirm the Optimole dashboard shows 1,181 assets.
  3. Open the Optimole WordPress plugin settings.
  4. Observe the 50,000-images-offloaded limit warning.

The customer report was not reproduced in a local runtime, but the stale-state path is directly present in the inspected source.

Diagnosis

Conclusion

The warning state is persisted independently from refreshed account usage. Optml_Admin::daily_sync() refreshes service_data but does not reconcile offload_limit_reached, while the settings UI renders the warning solely from that persisted flag and a locally stored limit. A previous support investigation also classified false offload-limit warnings as a UI notification defect. No matching GitHub issue was found.

Where this likely occurs
  • inc/admin.php — Optml_Admin::daily_sync() lines 1130–1158 refreshes account service data without updating the persisted offload-limit warning state.
  • inc/admin.php — Optml_Admin::localize_dashboard_app() lines 1409–1477 passes account data and the local offload_limit to the dashboard as separate values.
  • inc/settings.php — Optml_Settings::$defaults lines 102–103 defines the persisted warning flag and the 50,000 fallback limit.
  • assets/src/dashboard/parts/connected/settings/OffloadMedia.js — OffloadMedia lines 438–440 renders the warning whenever offloadLimitReached is true, without comparing refreshed usage.
  • assets/src/dashboard/utils/api.js — callSync() lines 525–546 updates the warning state only in a terminal transfer-response branch.
  • inc/media_offload.php — Optml_Media_Offload::generate_image_meta() lines 1384–1400 persists the reached state during the proactive quota check; lines 1446–1457 persists it after an upload-limit exception.
  • Commit 7b8a68f8 introduced offloading-limit notifications. Available history does not establish an earlier working release followed by a regression.
Engineering notes

The displayed 50,000 value can come from the plugin's local default or a previously stored service limit; it is not the current asset count. The dashboard's 1,181 assets and the SDK's offload-usage value may represent different service fields, so the account-specific discrepancy remains dependent on service data. The confirmed defect is the lack of reconciliation for an already persisted warning when account information refreshes.

Test coverage status

No relevant coverage was found during inspection for stale offload_limit_reached state, daily-sync reconciliation, or warning rendering. tests/test-media.php exercises offload processing and mocked account details but does not assert warning state transitions.

What to verify or explore next
  • May be worth reproducing after reducing usage below the limit, running the account refresh, and reopening Optimole settings.
  • May be worth capturing the SDK getUsage() current and limit values alongside refreshed service_data in a controlled test account.
  • If reproducible, checking both a completed bulk transfer and a newly uploaded attachment would clarify which warning-state path persists.
Unknowns / follow-up
  • The customer's plugin version and locally persisted Optimole settings are unavailable.
  • The service-side usage payload and whether environment deletion immediately changes SDK offload usage are unavailable.

Confidence

Confidence: 92/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

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của Codeinwp/optimole-wp

Tất cả issue của Codeinwp/optimole-wp

Issue tương tự

Thêm issue về PHP

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.