Deleted (disabled) site keeps sending scheduled emails

[r3dvorak]

Hello,

I manage 100+ sites in the same Panopticon instance. Only one deleted site keeps sending a daily email at 00:00.
This is one of the oldest sites in this Panopticon instance, and the issue may be related to a legacy version or upgrade path.

What I did so far

• Verified latest versions of Panopticon and the connector
• Uninstalled the Panopticon connector plugin on the Joomla site
• Deleted the site in Panopticon
• Checked server cron jobs (none related)
• Checked Database:
  • A remaining disabled site record (enabled = 0) exists in the database.
  • This record still contains the email schedule (hour = 0, minute = 0).

Question

• Is it expected that a disabled or deleted site record can still trigger scheduled emails?
• Or should deleting a site fully remove or deactivate its scheduler entry?

Thanks for a quick clarification.

Best regards
Richard

[nikosdion]

A remaining disabled site record (enabled = 0) exists in the database.

Which database? Which table? What are the record's contents?

This record still contains the email schedule (hour = 0, minute = 0).

What email schedule? Which database table? What are the record's contents?

[r3dvorak]

Which database? Which table? What are the record's contents?

• Panopticon database (MariaDB)

• Table pXXX_sites

Record

• Single remaining record for the affected site no. 19
• enabled = 0
• The record still exists after deleting the site via the Panopticon UI

Record content

INSERT INTO `pXXX_sites` (`id`,`name`,`url`,`enabled`,`created_on`,`created_by`,`modified_on`,`modified_by`,`locked_on`,`locked_by`,`config`,`notes`) VALUES
(
  19,
  'example-site.tld',
  'https://www.example-site.tld/api',
  0,
  '2024-05-08 09:29:14',
  1,
  '2026-02-02 09:03:46',
  1,
  NULL,
  NULL,
  '{
    "config": {
      "core_update": {
        "install": "minor",
        "when": "immediately",
        "email_after": true,
        "email_error": true,
        "time": { "hour": 0, "minute": 0 },
        "backup_on_update": "1",
        "backup_profile": "1"
      }
    },
    "groups": ["1"]
  }',
  ''
);

This is what I referred to as the email schedule.

Content of the mail tells me that there is an extension update:

Hello,

---

Available Joomla!® and extension updates report for site #19
(example-site.tld)

---

Joomla!® core updates

There are no pending core updates to report.
You are using Joomla!® 5.4.2 which is the latest version.

Extension updates

There is one pending extension update.

• “Example Extension” – from 1.2.3 to 2.0.0

Have a great day!

---

This email was sent by the Panopticon installation.
This is an automated email. Please do not reply to it.`

[nikosdion]

When you delete a site it's deleted; gone. It doesn't simply get unpublished. Moreover, when you delete a site it does not matter if the site was published or not; it's gone.

When you delete a site, its tasks are deleted as well. The #__tasks table has a foreign key on site_id referencing #__sites(id) with ON DELETE CASCADE. When a site row is deleted, MySQL automatically deletes all tasks belonging to that site.

Unpublished sites will not have update checks run or emails sent (with caveats, as we will see below). There are two layers of protection:

1. Director tasks skip unpublished sites. The "director" tasks that discover what needs doing (RefreshSiteInfo, JoomlaUpdateDirector, ExtensionUpdatesDirector, etc.) all query #__sites with an explicit WHERE enabled = 1 filter. An unpublished site (enabled = 0) is never selected, so no new per-site update or scan tasks are ever created for it.
2. Per-site tasks (like UpdateSummaryEmail) have their own enabled flag in the #__tasks table. The task runner only picks up tasks where enabled = 1. However, unpublishing a site does not automatically disable its associated tasks — there's no onAfterUnpublish hook that cascades to the tasks table.

So the practical effect is:

• Update checks: Won't happen — the directors won't select the site.
• Scheduled update summary emails (UpdateSummaryEmail): These tasks remain enabled in the tasks table and will still execute on schedule. However, they only report on already-known update information stored in the site's config JSON — they read config.core.canUpgrade and config.extensions.list from the site record. Since no director is refreshing that data, the email will keep reporting the same stale information. The preventDuplicates mechanism (on by default) will suppress repeated identical emails after the first one, so in practice you'd get one email with the last-known state and then silence.

The preventDuplicates mechanism can be found in src/Task/UpdateSummaryEmail.php. Here's how it works:

1. Collect current state: The task reads the site's stored config JSON to gather core update info (config.core.canUpgrade, version numbers) and extension update info (config.extensions.list, filtered to extensions that actually have a newer version available).
2. Compute a fingerprint: getUpdatesIdentifier() (line 227) hashes the collected data: hash('sha1', json_encode($this->coreUpdate) . '::#::' . json_encode($this->extensionUpdates))
3. This produces a single SHA-1 representing the exact set of available updates.
4. Compare against the stored fingerprint: The previous fingerprint is persisted in the task's own params JSON under the key updates_identifier. If the current fingerprint matches the stored one, the email is skipped (lines 132–148).
5. Update the stored fingerprint: When the fingerprints differ (meaning the available updates changed), updateTaskWithIdentifier() (line 330) saves the new fingerprint back into the task's params before sending the email.

So the email fires again whenever the set of available updates changes — a new extension update appears, an update gets installed (removing it from the list), or a version number changes. It's not time-based; it's content-based deduplication.

One subtlety: preventDuplicates defaults to true but is configurable per-task via $params>get('prevent_duplicates', true) (line 181). A user could disable it to get an email every time the task runs regardless.

The prevent_duplicates comes from ViewTemplates/Updatesummarytasks/form.blade.php lines 95-106. In UI terms, when you edit an update summary email there's a "Prevent identical emails" option which sits in the form between the "Report extension updates" checkbox and the "Enabled" checkbox. It's part of the main task configuration, not hidden away in an advanced section.

TL;DR

Based on the information you provided, here's what happened.

You did not delete the site, you unpublished it. Or maybe you had two separate instances of the site and you deleted the published one, but forgot about the unpublished one.

Moreover, when you set up the update summary email you chose to disable the "Prevent identical emails" option which means that every day when this task runs you will indeed get emails about your (unpublished) site.

You just need to delete the (unpublished) site record.

[r3dvorak]

OK, thanks. That confirms the root cause is a classic PEBKAC situation ;).