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?
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.
Joomla throws following warning message.
Message : "JUser: :_load: Unable to load user with ID: %s"
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');
Labels |
Added:
?
|
Category | ⇒ | com_users |
As the report says - this may be caused by an extension.
The request is to make the message either friendlier or not displayed
Status | New | ⇒ | Discussion |
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.
I've tested this issue with Joomla 3.8.9-dev and successfully reproduced it
Expected workflow
Labels |
Added:
J3 Issue
|
Status | Discussion | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2019-03-12 06:00:43 |
Closed_By | ⇒ | joomla-cms-bot |
Closed_By | joomla-cms-bot | ⇒ | franz-wohlkoenig |
Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/20689
I've tested this issue with Joomla 3.8.9-dev an cannot reproduce it:
Single Article
with settingShow Author
:Show
.Thus I don't think that this is a core issue.