This PR has commit c509358 which is not part of this issue

Yes this is the reason for this commit 8741706 which reverts the commit you mention

ah....

@mbabker please review eedea83

I now get:

I have tested this item ✅ successfully on bbac936

JLIB_DATABASE_GENERIC_SQL_ERROR is not defined in the language files yet???

I found some info here #7073 ?

fixed 1f9c287

Imho just showing a message "An error has occurred." is a bit to generic. Can't we add a new string which gives the user a clue what happend? Maybe "An error occured with the database query in the 'foo' field, please notify the administrator" or something. The name of the field could be injected into the string so one at least knows where to look for,

The WHOLE POINT is that we DONT tell ANYONE what the column names in the tables are

Saying An error occured with the database query in the **'foo' field** is saying too much!

The "foo field" refers to the name of the custom field, not the database field.

I have tested this item succesfully.

RTC cause 2 successfully Tests?

@slibbe can you please mark your test in J-Issue as successfully?

I agree with Bakual. We could have a new string before RC1 when we will freeze languages.

I agree that we should hide errors about sql structure for end users.
But I want to have somewhere a reference what went wrong.

Can we add some log (or may I miss, where is it?) or simple code like:

JFactory::getApplication()->enqueueMessage(JText::_('JERROR_AN_ERROR_HAS_OCCURRED'), 'error');
trigger_error($e->getMessage()); // It generates a php notice

Using the JLog API you can either add a logger for the existing categories used to record errors or add your own logger subclass to do something like call trigger_error() (or really anything you choose).

Unrelated. I have found that I have to:

• enable "Plugin: System - Debug"
• set Log Categories to database-error
• and set Log Almost Everything to Yes
• now I can see sql errors in administrator/logs/everything.php

I thing that should be more simpler and won't require debug plugin which slow down production server.
But it is an idea for another PR.

To do it with the core distribution and no extra tools, you're right. But the platform is already there to support you adding your own plugin to catch messages logged with JLog::add() and handle them as you please. I don't think we need to work through core and add trigger_error() or error_log() calls every place an error condition is handled to push the condition to PHP's error handler.

Yes, I full agree. I mentioned about trigger_error() before I found above described settings in debug plugin.

RTC based on the tests by @slibbe and @PhilETaylor if you want to ship a new language string we can do this in another PR ?

Thanks for testing.