Core Updates

You can get to this page by clicking Overview, Core Updates in the main menu.

This page allows you to see all core Joomla! and WordPress updates available across all of your sites.

You can select the checkboxes next to one or more sites and click on Update Selected to schedule the Joomla! or WordPress core update. Likewise, selecting the checkboxes next to one or more sites and clicking on Cancel Selected will remove the updates of these sites from the queue as long as they have not already started in the meantime.

Why does this feature exist?

While Joomla! and WordPress try to make their updates as smooth as possible, there are some cases where updates may cause problems. When you manage hundreds of sites you might want to delay updates until you are sure there are no show-stopper issues in a new release. Moreover, you may want to wait until a specific day where traffic is historically lower to apply the updates (something you cannot automatically schedule in Panopticon).

If you have dozens or hundreds of sites it does not make sense spending days clicking on individual sites' update buttons, reloading the page, rinse and repeat until you have enqueued all the sites you wanted for an update. It makes more sense to just do it in large batches, which is what this page does.

Moreover, it may make sense for you to know just how many sites have pending updates, especially if there are sites which need manual intervention before you can update them. Being able to see all pending updates will help you schedule your work.

Obviously, if you are auto-updating all sites, or simply don't have all that many sites, this feature may not be of any use to you. That's okay. You can just not use this feature. Remember, Akeeba Panopticon is mass-distributed software; it's meant to cater for a multitude of use cases, not just a specific user's use case.

Invalid Login updating Joomla

Sometimes Panopticon emails you to say that updating a Joomla site failed with the error message:

Extraction of the update failed; the site may be broken. Returned error message: “Invalid login”

…even though, when you check the site, the Joomla version has actually been updated. This section explains what is going on and how to fix it.

Where the “Invalid login” message comes from

The message is not produced by Panopticon. It is produced by Joomla's own update extraction script, administrator/components/com_joomlaupdate/extract.php. It is the catch-all error returned whenever that script cannot validate the request.

In a normal Panopticon-driven core update the sequence is:

1. Panopticon asks the connector on your site to “activate” the extraction.
2. The connector generates a fresh random 32-character password, writes it into a one-time file (administrator/components/com_joomlaupdate/update.php), and returns the password to Panopticon.
3. Panopticon POSTs the password to extract.php, which reads it back from update.php, compares the two, and proceeds with the extraction.

extract.php returns Invalid login whenever any of the following is true at step 3:

• The update.php file does not exist on the site (it has been deleted by something else).
• The update.php file is older than 90 minutes (Joomla considers it stale and refuses to use it).
• The password in update.php does not match the password Panopticon sent.

The root cause: two update methods running at the same time

Panopticon is not the only thing that can install a Joomla core update. Other update methods include:

• Joomla Automated Updates. Later versions of Joomla 5 and all versions of Joomla 6 ship with the (optional) Automated Updates feature. You can see this under System, Update, Joomla, Options, Automated Updates in your site's administrator.
• Host-controlled updates. Some hosts offer their own tooling to manage Joomla core updates, for example Softaculous.
• Other monitoring / management services. Panopticon is not the only product in this space. YourSites, Watchful, mySites and similar services can also drive Joomla updates.
• CRON jobs and CLI updates. Joomla can be updated from the command line, including from a CRON job.
• The Joomla backend Joomla Update interface. A human clicking the Update button in the Joomla administrator.

All of these methods, including Panopticon, end up using the same com_joomlaupdate code path on your site. They all generate their own one-time password, write their own update.php, run extract.php with that password, and clean up after themselves. None of them coordinate with each other.

If two of them run at the same time you get a race condition. For example:

1. Panopticon's connector writes update.php with password A and returns A to Panopticon.
2. Another update method fires shortly after, but before Panopticon finishes unpacking the update. It overwrites update.php with its own password B (or, if it finishes first, deletes the file).
3. Panopticon POSTs password A to extract.php. The file is now either gone or contains password B, so extract.php rejects the request with Invalid login.

The end result is exactly what you observe: the site is updated (by the other update method), but Panopticon sends an error email because its own extraction attempt was rejected. The same race explains why the error appears irregularly, and only on some sites — it only triggers when the two schedules happen to overlap.

What to do about it

Pick one method to update each site. Never two.

If you are using Panopticon to manage your sites, you must disable every other automated update method on those sites. This is not a Panopticon-specific recommendation: running two automated updaters against the same site is asking for trouble regardless of which tools they are. They will eventually collide.

In practice this means, on each site that Panopticon manages:

• Turn off Joomla's Automated Updates feature (System, Update, Joomla, Options, Automated Updates in the Joomla administrator). If you do not need the “Joomla! Update” scheduled task at all, you can disable or delete it from System, Manage, Scheduled Tasks.
• Disable any host-provided automatic Joomla update (e.g. Softaculous auto-upgrade).
• Stop any other monitoring / management service from auto-updating Joomla on that site.
• Remove any CRON job or CLI script that triggers Joomla core updates on that site.
• Avoid clicking the Update button in the Joomla administrator while a Panopticon-scheduled update is in progress.

Once Panopticon is the only thing driving core updates on a site, the Invalid login emails will stop.

A note on multiple Panopticon installations

The same reasoning applies to Panopticon itself. Do not point two separate Panopticon installations at the same site. Each installation has its own database, its own scheduler and its own queue of tasks. Neither one has any way of knowing what the other is doing on a given site. As far as the site is concerned, two Panopticon installations driving updates against it are indistinguishable from Panopticon plus Joomla's Automated Updates — the same race condition, the same Invalid login emails, and potentially worse problems with backups, scans and configuration changes overwriting each other.

This typically happens by accident: a staging Panopticon left running after a production one was set up, a migration where the old installation was never decommissioned, or someone running a personal Panopticon alongside an agency one. If you find yourself in this situation, decide which Panopticon installation is authoritative for each site and remove that site from the other one.

For the same reason, do not add the same site twice to a single Panopticon installation. Panopticon does not deduplicate sites by URL — if you add the same site under two different entries (for example with and without www, or with the URL spelled slightly differently), each entry will independently run its own update, backup, scan and configuration tasks against the same physical site. You will get exactly the same race conditions as if you had two Panopticon installations, plus a smaller but real chance of two backup or scan tasks tripping over each other. Each site should appear exactly once in each Panopticon installation that manages it.