I have tested this item ✅ successfully on 082ad0e

I have tested this item ✅ successfully on 082ad0e

I have tested this item ✅ successfully on 082ad0e

I’ve set up a local test environment and, as well as carrying out manual verification, I’ve also had the AI run through everything. The result: All three code paths log as described. A few suggestions below, none of them blockers.

Tested on 6.2.0-alpha4-dev, DDEV / PHP 8.3 / MySQL, PR head 082ad0ec.

Verification

Log excerpt with the secret removed:

2026-08-08T13:55:26+00:00	ERROR	172.18.0.5	security	No site secret configured in configuration.php.
2026-08-08T13:57:05+00:00	ERROR	172.18.0.5	security	No site secret configured in configuration.php.
2026-08-08T13:57:05+00:00	INFO	172.18.0.5	tokenfailure	Authentication failed

Other checks:

• Completeness: grep confirms these are the only three empty($siteSecret) sites in the token
  plugins — nothing missed.
• No duplicate entries: the plugin blanks the value first, so JoomlatokenField::getTokenForDisplay()
  returns early on empty($tokenSeed) and only one line is written per page load.
• No log noise for token-less API calls: the guard sits after the "no token supplied" / algorithm
  checks, so anonymous API requests don't trigger it.
• phpcs (Joomla ruleset.xml) is clean on both plugins.

Suggestions (non-blocking)

1. The category security makes the message invisible in a default configuration.
This is the main one. CMSApplication::setupLogging() only registers loggers for deprecated,
system and — if log_everything is on — everything else. I re-ran the test with the default
logging config (no log_everything, no log_categories) and no log file was written at all. So the
message only reaches someone who has already enabled "Log Almost Everything" — i.e. someone who
already suspects a problem, whereas the person hitting this bug just sees a blank field.

Category system at Log::ERROR is written to joomla_core_errors.php unconditionally
(Log::addLogger(['text_file' => 'joomla_core_errors.php'], Log::ERROR|…, ['system'])). I verified
this — with the category swapped and no configuration change at all:

2026-08-08T14:10:11+00:00	ERROR	172.18.0.5	system	No site secret configured in configuration.php.

2. Use an import instead of the inline FQCN. 89 core files do use Joomla\CMS\Log\Log;; the only
inline \Joomla\CMS\Log\Log:: uses in core are libraries/bootstrap.php / libraries/cms.php,
where the autoloader isn't available yet. phpcs doesn't flag it, but it's off-convention:

use Joomla\CMS\Log\Log;
…
Log::add('…', Log::ERROR, 'system');

3. Consider a language string. 219 of ~324 Log::add() calls in core use Text::, and the one
existing security-category log in core does too
(plugins/authentication/cookie → Text::sprintf('PLG_AUTHENTICATION_COOKIE_ERROR_LOG_LOGIN_FAILED', …)).

4. The message is identical in all three places, so the log doesn't say which subsystem produced
it, and it states the cause but not the effect. Since the stated goal is "explaining the reason for
the token to be blank", something like "No site secret configured in configuration.php — the API
token cannot be generated/verified" plus the plugin name would be more actionable.

5. Small inconsistency in api-authentication/token: the try { … } catch (\Exception) { return; }
around get('secret') returns without logging, while the two user/token files set $siteSecret = ''
and then fall through to the logged branch. Same root cause, different observability.

6. Branch target: the surrounding code is identical in 5.4-dev. If this counts as a diagnostic
fix rather than a feature it would apply cleanly there too — your call.

Repro

1. Enable plg_user_token + plg_api_authentication_token, open your own user account in the admin,
   save it once so a token is generated.
2. Set "Log Almost Everything" = Yes in Global Configuration.
3. Confirm the token is shown under Joomla API Token.
4. Remove the public $secret line from configuration.php.
5. Reload your user account → the token field is empty, and administrator/logs/everything.php
   contains the new ERROR … security … line. An API request with X-Joomla-Token produces the
   same line plus a 401.

Please consider implementing the following:

2. Use an import instead of the inline FQCN. 89 core files do use Joomla\CMS\Log\Log;; the only
inline \Joomla\CMS\Log\Log:: uses in core are libraries/bootstrap.php / libraries/cms.php,
where the autoloader isn't available yet. phpcs doesn't flag it, but it's off-convention:

@QuyTon based on @HLeithner dismissal of this I wont be wasting any more time on it until a maintainer makes a final decision

@QuyTon based on @HLeithner dismissal of this in #48275 I wont be wasting any more time on it until a maintainer makes a final decision