Where an update goes after you click: the queue, the task list and the log

Some things in WP Safer happen while you watch, and some are handed to a queue. Knowing which is which saves a lot of clicking twice.

Straight away, or queued

• Runs immediately: the Update to … button on a single plugin or theme row, and activate, deactivate, lock and delete. The panel sends the command, waits for the site, and tells you what happened.
• Goes into the queue: Update all on the Plugins or Themes tab, Update core, plugin and theme installs, backups, and everything automatic updates decide to do. The answer you get is Added queue successfully, or a count such as "4 plugin(s) have been added to the queue for update".

Queued work is deliberate. A site with eleven outdated plugins is eleven separate installs; doing them one at a time, in the background, means a slow host cannot leave your browser hanging, and a plugin that misbehaves does not take the other ten down with it.

Follow the queue

Open Tasks in the left menu. General tasks lists everything waiting or running that is not a backup or a restore — those have their own tabs.

• Action is the job in plain words: Plugin Update, Theme Update, WordPress Core Update, Plugin Installation.
• Status is Waiting until a WP Safer job picks it up, then In progress.
• Queued is when it was added, and the site name links to the site.
• A job that is still Waiting can be removed with the bin icon (Delete task). A job already In progress cannot — its button is disabled.

The screen refreshes itself: roughly every seven seconds while something is waiting or running, every thirty when the queue is empty. Finished jobs disappear from this screen — they are in the log.

WP Safer works through the queue in batches, so a long list does not all move at once. "It's already in queue. Please wait until finished" means exactly that: the same job for the same target is already there, and clicking again would not make it sooner.

What was done, and did it work

Logs → Activity is the record of every command WP Safer ran on your sites: when, which site, which action, which target, and Success or Failed. Both kinds of update end up here — the immediate one and the queued one.

You can narrow it by Action (each action shows its own count) and by Period, from Today to Last year or a Custom range. The page number lives in the address, so a log page you send to someone opens on the same page.

For a single site, the same list is on the site's own Logs tab, without the site column. It is the same table and the same rows, filtered to that one site.

A failed row is not always a broken site

The Result column reports what the site answered. Common reasons for Failed:

• The site could not be reached — it was down, slow, or behind something that blocked the request while the job ran. The update was probably not installed; check the version on the Plugins tab.
• rate-limited — the connector plugin accepts a limited number of requests per minute from one address, and a very large batch can touch that ceiling. It clears by itself.
• The filesystem is not writable or file modification is disabled — see Updating plugins, themes and WordPress.

After every queued update WP Safer reads the site again and refreshes its plugin, theme and WordPress versions, so the tabs show what is actually installed rather than what we asked for. If an update went in but the site broke afterwards, that is a different signal, and it is handled by the check that runs a few minutes later: When an update breaks a site.