Joomla-cms: Warning message : JUser: :_load: Unable to load user with ID

Created on 8 Jun 2018  路  13Comments  路  Source: joomla/joomla-cms

Steps to reproduce the issue

Sometimes if an extension has not handled action "onUserAfterDelete".
like, delete/update user id value from the created_by column in the database table of that extensions,
then the Joomla throws following warning message.

Message : "JUser: :_load: Unable to load user with ID: %s"
Ideally, the extension should handle this but message looks messy to end user ( frontend ) and may lose trust on site. Can we do something here?

Expected Result

We can log the warning in the log file and Joomla should not throw warning message, the end user of any site may not able to understand the message.

Actual result

Joomla throws following warning message.
Message : "JUser: :_load: Unable to load user with ID: %s"

System information (as much as possible)

I found this from joomla
language/en-GB/en-GB.lib_joomla.ini:
JLIB_USER_ERROR_UNABLE_TO_LOAD_USER="JUser: :_load: Unable to load user with ID: %s"

libraries/src/User/User.php
\JLog::add(\JText::sprintf('JLIB_USER_ERROR_UNABLE_TO_LOAD_USER', $id), \JLog::WARNING, 'jerror');

J3 Issue No Code Attached Yet

Most helpful comment

We honestly need to sit down and start going through every JLog::add('FOO', WHATEVER, 'jerror'); call and figuring out what actually needs to be displayed in the UI and what doesn't. The fact the "jerror" log category arbitrarily pushes messages to the UI message queue is honestly more annoying than anything and that log handling mechanism really needs to be deprecated.

All 13 comments

I've tested this issue with Joomla 3.8.9-dev an cannot reproduce it:

  • Created an additional Administrator user.
  • Logged in (backend) with credentials of this new user.
  • Created an article and a menu item Single Article with setting Show Author: Show.
  • Logged out and logged in as a Super User.
  • Deleted the user above.
  • Afterwards I don't see an error message in frontend. Just in backend when I open the article which is Ok for me as a hint that I have to set a new created_by with an existing user.

Thus I don't think that this is a core issue.

As the report says - this may be caused by an extension.

The request is to make the message either friendlier or not displayed

Yes, I understand but I've learned some time ago here (plg_system_redirect) that it's forbidden to suppress core messages even if misplaced and even if SEO is concerned.

I think things like this should be solved by the 3rd extensions. The message is a good hint for extension programmers somehow.

We honestly need to sit down and start going through every JLog::add('FOO', WHATEVER, 'jerror'); call and figuring out what actually needs to be displayed in the UI and what doesn't. The fact the "jerror" log category arbitrarily pushes messages to the UI message queue is honestly more annoying than anything and that log handling mechanism really needs to be deprecated.

There are only 208 instances so shouldnt be that hard

and a much smaller number with jerror which I presume are the ones that are output to the ui and not just the logs

It's the "jerror" category that gets pushed to the UI. Every other log category in core only goes to log files.

And I guess we only need to be concerned about the errors pushed to the front end ui

Right. BUT, we shouldn't be introducing application conditional behavior into library classes (there are some messages in the file cache adapter that get to the UI) or something like the User class which is supposed to be a data model type object. So, that makes things a little tricky if you really do want to display some kind of notice in the admin but not on the frontend.

In the case of this instance in the User class, I'd just change it to a $this->setError() call like the other error conditions in the class do (yes I'm aware JObject, we can address those uses later) then anything doing $user->load() and getting a boolean false return can decide how to handle that error and not have our API arbitrarily enqueue a message to show in the UI. If we want to keep the log statement use a different logging category that doesn't actually push the message to the UI.

Thus I don't think that this is a core issue.

See #13864 where restoring a content version from a sample data causes this in the core.

I've tested this issue with Joomla 3.8.9-dev and successfully reproduced it

  1. Created a registered user.
  2. Logged in to the backend.
  3. Created an article and a menu item Single Article.
  4. Created custom USER field using com_fields interface and assigned the newly created field to an article.
  5. Now I have assigned registered user value to the custom field of an article.
  6. Now I have deleted the registered user assigned to the newly created article.
  7. Next, I have visited the article menu and it throws the reported warning with the deleted user id.

Expected workflow

  1. This should be handled silently.
  2. Show warning only if the debug mode is enabled. (If the showing warning is really important.)

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/20689

closed as having Pull Request #24166

Was this page helpful?
0 / 5 - 0 ratings