Actionlogs in Joomla

Sooner or later, every website owner asks a question that starts with "who". Who unpublished the homepage last night? Who installed that extension nobody recognises? Did the new editor really delete twelve articles, or is the client mistaken?

Without a record, these questions have no answer, and you are left guessing.

Joomla answers them with a small but powerful core component called User Actions Log (com_actionlogs). It quietly records every important change on your site: saves, deletes, publishing, logins, installs, and configuration changes. Each record stores the user, the action, the time, and (optionally) the IP address. You do not need to install anything. It is already in your Joomla.

Who did what, when, and from where - recorded by Joomla without a single third-party extension.

This article explains how the Action Logs component works, what it records, how to read and filter the log, how notifications and CSV export work, and how to keep the log healthy on a busy site. The goal is to help website owners, administrators, and developers understand this quiet witness well enough to trust it the day they need it.

2. What Gets Logged

2.1 The Default Loggable Extensions

You decide which components are watched under Options → Logged Extensions. This is a multi-select that ships with every core component already enabled:

com_banners     com_cache       com_categories   com_checkin
com_config      com_contact     com_content      com_fields
com_guidedtours com_installer   com_media        com_menus
com_messages    com_modules     com_newsfeeds    com_plugins
com_redirect    com_scheduler   com_tags         com_templates
com_users

Remove an extension from this list and its events are silently dropped. No rows are written for it. Trimming this list is the single most effective way to reduce log noise on a busy site.

2.2 Content Lifecycle Events

For every loggable component, the recorder plugin subscribes to three content events:

So every article you save, every category you trash, and every menu item you publish writes one row.

2.3 User Lifecycle Events

User events are the most important for spotting account abuse:

One detail surprises people: failed logins with an unknown username are not logged. The plugin checks for an existing user first, which keeps automated scanner traffic out of the audit trail.

2.4 Extension Lifecycle Events

Anything that touches the extensions table is recorded:

This is pure gold for forensics after an incident. The question "when did we install that vulnerable plugin?" becomes one query away.

2.5 Configuration Changes

Joomla also records configuration saves:

• onApplicationAfterSave: Global Configuration was saved.
• onExtensionAfterSave with context com_config.component: a per-component Options screen was saved.

Both record which fieldset changed, but not the before and after values. If you need the exact diff, that takes a small custom plugin (see section 11).

2.6 Operational Events

A few housekeeping actions are logged too:

Yes, purging the log is itself logged. After a purge, you are left with exactly one row: "User admin purged the action logs." The audit trail is self-documenting.

2.7 API Requests (optional)

If you set Options → Log API Endpoints = Yes, Joomla records every Web Services API call as it dispatches. A second option, Logged HTTP Verbs, lets you choose which methods to capture. It defaults to GET only, but most production sites that enable this want POST, PUT, PATCH, and DELETE at minimum.

A warning: API logging fills the table fast. Turn it on for an investigation, then turn it off for steady-state operation. See section 8 for the numbers.

4. Export and Purge

4.1 CSV Export

The list view has two export buttons in the toolbar:

The delimiter is configurable under Options → CSV Delimiter. Choose a semicolon (;) if your spreadsheet locale (for example Dutch Excel) treats commas as decimal separators.

The export is streamed one row at a time, so even a log with a million rows will not run the PHP worker out of memory.

4.2 CSV Injection Protection

Joomla escapes any cell that starts with =, +, -, @, a tab, or a carriage return by prepending a single quote. This blocks the classic "Excel formula injection" attack, where a logged username like =cmd|'/c calc'!A1 would otherwise run as a formula when an admin opens the CSV.

If you ever write a custom exporter, keep that escaping. It is there for a good reason.

4.3 Purging the Log

The Purge button in the toolbar wipes every row from #__action_logs. The purge then writes one row of its own, so afterwards you have a single entry recording who purged the log and when.

Common reasons to purge:

• After a long migration period, when you want a clean slate.
• Before exporting only fresh activity.

There is no undo and there is no built-in scheduled purge. For automatic clean-up, use a Scheduler task (section 8).

6. Under the Hood

6.1 The Four Tables

Action Logs uses four database tables:

#__action_logs              one row per logged action
#__action_logs_extensions   the list of extensions that participate
#__action_log_config        how each content type renders
#__action_logs_users        per-user notification preferences

The main one is #__action_logs. The other three are small reference tables.

6.2 The Main Log Table

The core fields of #__action_logs are:

id                   auto-increment primary key
message_language_key the template key, e.g. PLG_ACTIONLOG_JOOMLA_CONTENT_UPDATED
message              JSON with the placeholder values
log_date             when the action happened
extension            context, e.g. com_content.article
user_id              acting user (0 = guest or system)
item_id              affected item id (0 if not applicable)
ip_address           real IP, "Disabled", or "Invalid"

The table carries several indexes on user_id, (user_id, log_date), (user_id, extension), and (extension, item_id). These are what keep the "show all actions for user X" filter fast, even on a log with millions of rows.

6.3 The Message JSON

This is the clever part. The message column does not hold the rendered text. It holds a JSON object of placeholders:

{
  "action": "update",
  "type": "PLG_ACTIONLOG_JOOMLA_TYPE_ARTICLE",
  "id": 42,
  "title": "About Us",
  "itemlink": "index.php?option=com_content&task=article.edit&id=42",
  "userid": 100,
  "username": "admin",
  "accountlink": "index.php?option=com_users&task=user.edit&id=100"
}

The message_language_key is the template, for example:

"User {username} updated {type} {title}."

At display time, Joomla substitutes the JSON values into the template and wraps the user name and the title in links. This is exactly why the log is translatable: the message is a key, not a fixed string. Install the Dutch language pack and "User admin updated..." becomes "Gebruiker admin werkte ... bij."

6.4 The Content-type Map

The table #__action_log_config tells the renderer how to read each content type. For each type it stores which column holds the id, which holds the title, the table name, and a text prefix used to build the language key:

type_alias              id_holder     title_holder   table_name
com_content.article     id            title          #__content
com_categories.category id            title          #__categories
com_redirect.link       id            old_url        #__redirect_links
com_modules.module      id            title          #__modules
...about 23 rows in Joomla 6

A custom component can register its own type by inserting a row here. That is the hook developers use to make their own extensions log-aware (section 11).

8. Performance and Scale

8.1 How Much Does It Grow?

For a normal content team, the log is tiny. A team of five editors might generate:

~50 article saves/day + ~20 menu/module saves/day + ~10 logins/day
= roughly 80 rows/day = ~2,400 rows/month = ~30,000 rows/year

Each row is around 500 bytes, so one year is about 15 MB. No problem at all.

API logging changes everything. A site serving 10 requests per second to its API would hit 864,000 rows per day. Do not enable it casually.

8.2 Pruning Strategies

A Scheduler task is the cleanest way to keep the log trimmed. A simple prune deletes everything older than 90 days:

DELETE FROM jos_action_logs
WHERE log_date < NOW() - INTERVAL 90 DAY;

For a smarter policy, keep the security-relevant events longer and prune only the routine content events:

DELETE FROM jos_action_logs
WHERE log_date < NOW() - INTERVAL 90 DAY
  AND extension NOT IN ('com_users', 'com_installer', 'com_config');

Logins, installs, and config changes are worth keeping longer than ordinary saves. Their forensic value grows over time.

8.3 Fast Queries vs Slow Queries

Because of the indexes, queries that filter on user and date, or on extension and item, are fast:

-- Fast: all actions by one user in the last 7 days
SELECT * FROM jos_action_logs
WHERE user_id = 100 AND log_date > NOW() - INTERVAL 7 DAY
ORDER BY log_date DESC;

Free-text search through the JSON message has no usable index and scans the whole table:

-- Slow: free-text search through the message
SELECT * FROM jos_action_logs
WHERE message LIKE '%phishing%';

The list view's search box is exactly this kind of LIKE '%...%' scan. It is fine for the occasional admin lookup, but do not build scripted polling on top of it.

8.4 Triage SQL You Will Use Often

Yesterday's failed logins, the brute-force canary:

SELECT user_id, COUNT(*) AS attempts
FROM jos_action_logs
WHERE message_language_key = 'PLG_ACTIONLOG_JOOMLA_USER_LOGIN_FAILED'
  AND log_date > NOW() - INTERVAL 1 DAY
GROUP BY user_id
HAVING attempts > 5
ORDER BY attempts DESC;

Recent extension installs, a supply-chain alarm:

SELECT log_date, user_id, message
FROM jos_action_logs
WHERE extension = 'com_installer'
  AND log_date > NOW() - INTERVAL 7 DAY
ORDER BY log_date DESC;

Remember to replace jos_ with your real database prefix.

10. Security and Compliance

10.1 The Audit Trail Is Itself a Target

An attacker who gains admin access often wants to do something malicious and then hide the evidence. The action log makes hiding harder, but it is not bulletproof. A super-user can purge the log, disable the recorder, or delete specific rows with raw SQL.

Sensible mitigations:

• Restrict the Delete permission to a single dedicated account.
• Stream the log offsite so a local copy alone cannot be the only record.
• Watch for the meta-events: a purge, or the recorder plugin being disabled.

Trust but verify applies to your own admins. The log is a deterrent and a forensic tool, not a guarantee.

10.2 Turning Logs Into Action

A log you only read after the fact gives you half its value. Action logs can also feed automated responses:

• Brute-force alerting: a Scheduler task runs the failed-login query and pushes an alert to Slack or email when attempts cross a threshold.
• Suspicious-install pager: a webhook on extension installs that pings the security team. An extension installed at 03:00 by a normally 9-to-5 admin is a red flag.
• Privilege-escalation watch: alert when anyone is added to the Super Users group. This should almost never happen.

The action log is your detection layer. Pair it with a response layer, either inside Joomla via Scheduler tasks and plugins, or wired to an external monitoring system.

10.3 The Minimum-viable Security Setup

For a production site you actually care about, about twenty minutes of setup buys you a lot:

1. Action Logs enabled for com_users, com_installer, com_config, com_plugins, com_modules, and com_templates.
2. IP logging on, with a 90-day retention task.
3. Notifications on for super-user accounts, watching com_users and com_installer.
4. The Delete permission restricted to a single dedicated security account.
5. A daily look at the failed-login query, or its dashboard equivalent.

It pays off the first time someone tries to be clever.

12. Action Logs vs Other Logs

12.1 Action Logs vs the System Log

Joomla also has a low-level system log written by Log::add(). The two serve different goals:

Use Action Logs for "who did what in the CMS" and the system log for technical events. They complement each other.

12.2 Action Logs vs Server Logs

Action logs live at the application layer. They are blind to anything that never reaches the Joomla event system. For a full picture you also need the infrastructure layer:

An example shows the difference. A 500-error on an article shows up in the PHP error log and the access log, but not in the action log, because the save event never fired. The opposite is also true: an editor quietly trashing a page shows up in the action log, but in the access log it is just one more POST with status 200.

For real forensic work you correlate timestamps across all of them. Action logs answer who; server logs answer how the request landed; together they tell you what actually happened.

14. Quick Reference

COMPONENT       Users → Action Logs
NOTIFICATIONS   Users → Action Logs Notifications
OPTIONS         Users → Action Logs → Options
RECORDER        System → Plugins → Action Log - Joomla
NOTIFIER        System → Plugins → System - Action Logs
MAIN TABLE      #__action_logs
LOGGED EXTS     Options → Logged Extensions (21 by default)
IP LOGGING      Options → IP Logging (OFF by default)
API LOGGING     Options → Log API Endpoints (OFF by default)
EXPORT          Toolbar → Export All / Export Selected
PURGE           Toolbar → Purge (no undo, self-logging)
PRUNE           com_scheduler → SQL Operations task
SINCE           Joomla 3.9 (May 2018)