The errors should be logged and currently that requires proper configuration of debug. Consider that not sufficient. The product should have a logger enabled for errors.

It can be default enabled but there are conditions to keep in mind:

• A hosting platform where Joomla can't write log files (due to poor config or a user implementing extra "security" measures)
• Failing to write to the log shouldn't trigger a fatal error (I think I've seen instances where this may happen, in part due to the lack of permissions)
• Reviewing where we are actually using JLog now. We have a log callback that enqueues messages for the 'jerror' log category (which IMO is really not optimal; if we want to log and display a message just call both...). We don't want to be writing logs on every request a site gets; those files blow up pretty quickly, especially if catching deprecations or logging all database queries.

On Friday, April 10, 2015, sovainfo notifications@github.com wrote:

The errors should be logged and currently that requires proper
configuration of debug. Consider that not sufficient. The product should
have a logger enabled for errors.

—
Reply to this email directly or view it on GitHub
#6710 (comment).

Guess you missed the second word: ERROR
Added this to cms.php:
JLog::addLogger(array(), JLog::ERROR, array('deprecated'), true);
Then created an error in the featured query, it was logged and embarrassingly enough also shown:

the point is how the core modules,plugins,ect handle db errors ( #6591 ) ?

showing a generic message

JFactory::getApplication()->enqueueMessage('blah blah ', 'warning');

or something different like

if (JFactory::getUser()->authorise('core.admin'))
{
 JLog::addLogger("blla bla");  
........
}

i would prefer the keep it simplest stupid "bla bla" msg

but not sure to understand what exactly is the "family feeling"

i'm missing something?

p.s
a special thanks to all #pbfnl

Me and @roland-d just had a chat about this. We have made an executive call that we show a generic "blah blah" message to users and then just add the exception message into the Logs. Just make sure it isn't in a category that will be shown to the frontend user.

done
i've used a ready lang string maybe something different?

I think probably something different. I'll ping @brianteeman in the language string group on glip

@wilsonge Any update on this?

@brianteeman recommended as it's a string to frontend users we either display a hugely simplified string of "There has been an error" or don't show a string at all.

@test Works as described, after generating an error, I get a simple error message that the database connection is not there.

To test, I changed the plugins/search/categories/categories.php file on line 152 and changed THEN to THN. On the frontend, I used the search function to search categories only and received the error page with a large DB query. After applying the patch and making the same change, I now receive a graceful message.

@roland-d i'm sorry for my pr patchworks
look at this one please #7073

p.s
maybe this one could be closed

@alikon There are a lot of these db PRs. Is there a comprehensive list with all of them that should be tested?

@roland-d my search string

is:open is:pr author:alikon Handle DB 

;)

Did same testing procedure like @roland-d - successfull

RTC

Closing in favour of #7073