Skip to main content

Automation: scheduled scans and 404 monitoring

Two parts run in the background. For both of them the same rule applies as for everything else:

They find and report. They do not move and do not delete. There is no automatic cleanup in Media Organizer — not even behind an option. That option deliberately does not exist.

Scheduled scans

A scan can run regularly through the Joomla task scheduler. The task plugin is enabled automatically during the installation.

Setting it up

  1. Open System → Scheduled Tasks.
  2. New task → task type Media Organizer.
  3. Choose the interval — weekly or daily is enough for most websites.
  4. Optionally set up the email notification.

From the dashboard, Adjust task takes you straight into the settings. The dashboard also shows when the last scheduled run was, whether it succeeded and when the next one is due.

The task scheduler needs a trigger. If it runs on page views ("lazy scheduler"), it starts only when somebody visits the site. For reliable timing, set up a real cron job — that is Joomla standard and described in its documentation.

What the scheduled scan gives you

One thing above all: continuity. The deletion gate requires that a file was a candidate in several consecutive scans (default: 2) and that the scan is not too old (default: at most 7 days). A regular scan satisfies both by itself — you do not have to remember to scan manually just before cleaning up.

As a side effect the figures show you how your media library develops.

The 404 monitoring

The system plugin logs accesses to files that sit in quarantine. It is disabled after the installation — switch it on under System → Plugins.

Why this is so useful

Media Organizer can only find what is inside your Joomla installation. An image linked in a newsletter, embedded in a PDF or included from another website is invisible to any scan in the world.

The 404 monitoring closes exactly that gap — but only once the file is in quarantine: if somebody then requests the file, a 404 arises and the plugin records it.

A 404 hit on a file in quarantine is the strongest indication there is not to delete it: somebody actually requested it. You see the count on every tile in the quarantine view.

The deletion gate checks these counters too: if there were hits, deleting for good is blocked.

Is this a performance problem?

The plugin runs along with page views but keeps itself tight: it is only interested in 404s on paths it knows to be in quarantine. If you still do not want it running permanently, a good compromise is: switch it on while a batch sits in quarantine — and off again afterwards.

  1. Enable the 404 monitoring.
  2. Move a manageable batch to quarantine.
  3. Wait out the retention period and keep running the website normally.
  4. Before deleting for good, check the 404 counters. Any hits? Restore and look for the reference.
  5. All stayed quiet: delete. Next batch.

Where to go from here

Applies to version 1.1.2.0.

Deutsche Fassung

Back to top