WP-Optimize coordinates three pipelines under a single admin screen. The page cache writes static files under wp-content/cache/wpo-cache/ with a preload schedule held in wp_options under the wpo_cache_preload key. Image compression queues jobs to the reSmush.it or Local Server backend and tracks each image in the wp_options row wpo_image_compression_meta with a status column flowing through queued, processing, compressed, and failed. The database optimization log writes per-table cleanup records to wp_optimize_optimizations on each run. The default Optimize screen surfaces a Run Optimization button and a savings counter, which works for everyday use and hides every interesting detail when one image fails.

SleekView Kanban reads the same WP-Optimize tables and option rows the Optimize screen aggregates. Pick the image compression status field as the grouping and every image becomes a card grouped under Queued, Compressing, Compressed, or Failed. Card fronts can show the image path, the original size, the compressed size, the savings percentage, the backend used, and the last update timestamp so a developer can spot bottlenecks across the compression queue without leaving the board.

Dragging a card between columns calls the WP-Optimize helper API. A move from Failed back to Queued resets the image row and re-submits to the configured backend on the next cron tick. A move from Compressing back to Queued cancels the in-flight job. WP-Optimize's automatic cache purge on post save keeps running, so a manual board action never collides with the plugin's normal invalidation flow.

WP-Optimize bundles three things every WordPress site eventually needs. A page cache writes static HTML for anonymous visitors. An image compression pipeline submits uploads to reSmush.it or a local server backend and stores the compressed result.

A database cleanup script trims expired transients, autodrafts, and revisions on a schedule. Every one of those pipelines has a status that flows from queued to processing to compressed, with a failed branch for transient upstream errors. The Optimize screen reduces all of that to a single Run Optimization button and a savings counter, which works for everyday use and hides every interesting detail the moment one image fails or one backend times out.

A kanban board flips that around. Every image is a card. Every status value is a column.

A glance at the board tells the team how many images are queued, how many are stuck in the backend, how many succeeded, and how many failed with a reason worth investigating. Dragging a card writes the change back through the same helpers the cron tasks call internally. The Optimize screen still exists, and still gives a one-button bulk run.

The board exists for the rest of the time, when the team needs to see the compression queue the way the queue already sees itself.