You may have seen the error message "JUser: :_load: Unable to load user" and wondered if it would be possible to easily update all articles that display an error after the author or editor of the article has been deleted from the system on purpose or by accident.  The alternative, manual editing and updating each article, even though easy, can be boring and subject to mistakes, and it can take longer than expected.

If you have the numeric id of another user, who is going to replace the author or modifier of the article, the updates can be done through a SQL query.

Run the attached SQL statement first in a test environment, for example a cloned copy of  the website, hosted on your workstation, using a bundle like Wampserver from  Make a backup of the content table before the test, in case something goes wrong.

The attached SQL script replaces the author of all articles created by the deleted original user, whose name and other details cannot be found from the users table in the database.  The first SQL statement sets the user id of the new author.  After that a CREATE statement creates a temporary table  so that the article ids can be stored by the subsequent query, which finds all the articles where the author has been deleted and adds the article id to a temporary table. 

The same pattern can be used to update the column 'modified_by'. Replace 'ep28r' with your own table prefix.

SET @author = 181;
`id` int(10) unsigned NOT NULL, PRIMARY KEY (`id`)
SELECT FROM ep28r_content c
LEFT JOIN ep28r_users u ON c.created_by =
UPDATE ep28r_content c SET c.created_by = @author
WHERE IN(SELECT FROM deleted_users d);

If listing users with custom fields is a one-off requirement or only super users need to do that task from time to time, registered users and the contents of their custom fields can be listed by a custom query using phpMyAdmin or a similar MySQL client.

The following example creates temporary tables before generating the list. The query assumes that there are three custom fields, field4, field5 and field6, where the field ids are 4, 5 and 6. Replace 'epr28r' with your own table prefix.

SELECT,, FROM ep28r_users u
INNER JOIN ep28r_user_usergroup_map m ON = m.user_id
WHERE m.group_id = 2 AND u.block = 0;

SELECT, v.value AS field4 FROM ep28r_registered r
LEFT JOIN ep28r_fields_values v ON = v.item_id
INNER JOIN ep28r_fields f ON = v.field_id
WHERE = 4;

SELECT, v.value AS field5 FROM ep28r_registered r
LEFT JOIN ep28r_fields_values v ON = v.item_id
INNER JOIN ep28r_fields f ON = v.field_id
WHERE = 5;

SELECT, v.value AS field6 FROM ep28r_registered r
LEFT JOIN ep28r_fields_values v ON = v.item_id
INNER JOIN ep28r_fields f ON = v.field_id
WHERE = 6;

SELECT,,, w4.field4, w5.field5, w6.field6 FROM `ep28r_registered` r
INNER JOIN `ep28r_work4` w4 ON =
INNER JOIN `ep28r_work5` w5 ON =
INNER JOIN `ep28r_work6` w6 ON =;

It was time to take inventory of third party extensions and remove those that were not needed on a test site.  Found only a couple of extensions and the Akeeba Release System (ARS) was one of them.  This was going to be easy! Clicked the Uninstall button, only to see a nasty PHP fatal error displayed on a blank page about a missing file in a library.  The site was rendered unusable.  How come?

A closer look at the error identified that the Admin Tools extension was trying to load the fof30 library.  Interesting, one extension by Akeeba disabled the other!  The manifest file of ARS revealed that the uninstallation of the package is done by the script  /administrator/manifests/packages/ars/script.ars.php

The uninstall() function has two lines of comments about the uninstallation of the FOF library possibly failing if other extensions are dependent on it.  Instead, the relatively old version of the uninstallation script of the unsupported extension missed the existence of the latest version of Admin Tools completely and zapped the library.

Solution:  comment out the following line from the uninstall() function before starting to uninstall.

// $this->uninstallFOF($parent);

The moral of this true story:

  • run the uninstall script once on a test site before installing a new extension on a live site
  • avoid unsupported extensions unless you are prepared to troubleshoot

Sometimes websites produce warnings or error messages without giving any clues what caused the issue. Surely this has happened to everyone and it is annoying, especially if it happens at a website you are supposed to maintain. 

Recently someone reported that they are unable to update articles because every time they try they get the message "Warning, Registration failed. Please try again."  Clearly this message does not belong anywhere near the editing process where articles are updated or created. Something must have gone wrong in a third party extension or a home grown plugin.

If you have a similar situation where a seemingly unrelated error or a warning is reported in the browser, search for the text string from the website or clone or simply download the filesystem of the site and search on your workstation. A utility like grep or Windows grep are the easiest to use.

The text of the message is most likely to be found in one of the language files.  This of course assumes that the extension that produced the message follows Joomla best practice of keeping the message texts in separate files, consisting of language constants and language strings.

Language Files

Third party extensions add their own language files into the languages folder either at the front end or the back end of the site, or both.  Extensions can also install their language files in a subfolder in the same folder where the extension itself is installed. Therefore a text search utility is the best approach to find any obscure messages where the origin can be anywhere in the system.

Language File Example

Once you find a match in a language file, copy the language constant from the start of the line and then search for that constant from the website filesystem or its copy exactly the same way, using a utility like grep or Windows grep. This way you can identify the file or all the files where the language constant has been used and you will be able to identify the extention.

If the message is not defined in one of the language files, it would have had to be hard coded in a third party extension, for example a plugin, which you may then be able to unpublish.


If your Joomla! site has issues in connecting to your SMTP mail server, it is possible to get a detailed log of all the messages exchanged between your Joomla site and the SMTP server.  Inspecting this low level transaction log allows you to see what is going wrong between the two servers and then get your IT department or hosting provider to resolve any connectivity issues. 

Go to Extensions - Plugins and configure the system plugin 'System - Debug' with the following settings:

  • Allowed Groups: Super Users
  • Log Priorities:  All
  • Log Categories: mail
  • Log Almost Everything


20180425 system debug plugin 20180425 system debug logging


Go to Global Configuration and turn on the debug option in the System tab - Debug Settings - Debug System.  

20180425 debug settings


Go to the Server tab - Mail Settings and click the button Send Test Mail. 

20180425 mail settings


The test result, success or failure, will then get displayed as a system message, but you can download the detailed log file 'everything.php' from the Joomla log folder, usually administrator/logs, or, if your site was installed much earlier, from the /logs folder in the main Joomla folder.

20180425 everything example

 And this is the email we would like to receive from the website:

20180415 test mail

More about logging from the Joomla! Documentation at