Determine if there is a better message for AJAX errors

@bnjmnm, thanks for making this issue.

I am concerned that the message does not help a non technical user. Something like the existing message, "Contact the site administrator if the problem persists." would point them in the right direction.

🐛 Ajax errors are not communicated through the UI Fixed landed!

What about making it configurable under admin/config/development/logging?

I agree.

The message is not clear. Plus, we should think about displaying a message only on error 500.

I guess this feature was made thinking about using Ajax with drupal css "use-ajax" and "use-ajax-submit" but you want to let developer be able to handle themselves other errors (such as 403 or whatever) on Drupal.ajax implementations.

I personally ended up created this patch for 10.1

We have a multi-step webform with ajax enabled. In user testing, a user got the "Oops" error when their device temporarily lost internet connection. With the patch in #6, the user sees no error and has no clue something is wrong. The webform simply doesn't respond. Here is another patch which which shows two different error messages depending on the XMLHttpRequest status:

1. Status 0 (request did not complete): "Oops, something went wrong. Check your internet connection and try again."
2. All other status codes: "Oops, something went wrong. Contact the administrator."

I see two problems with this functionality.
1. There is no conventional way to hide or change this message from display if necessary. (why can't it be just configurable?)
2. Each error displays every time on the new line and it looks wrong when some AJAX query repeats from time to time (Notifications as an example)

Regarding #7 and #8, from my POV, error handling should be done by project, and it's almost impossible to provide an all-in-one solution which will satisfy each Drupal website.

Hence, the idea of only handling error 500 or specific errors like maybe status code 0, even though this can be produced because of different reasons, see here and https://stackoverflow.com/questions/872206/what-does-it-mean-when-an-http-request-returns-status-code-0.

Even making a big config form with a custom message for each HTTP status code wouldn't make sense to me, as, for example, you might want to return a different error message on different 403 or 404 to your users on the same AJAX response:

Example, errors 403 returned by the same Ajax handler:

• You do not have the necessary permissions to access this resource.
• Your session has expired.
• Insufficient privileges to perform the requested action.
• Access to this resource is restricted from your current IP address.
• etc. etc.

In the spirit of continuing to improve the messaging, even if further follow-ups could be done beyond that, how about we just make the existing message configurable? The tone of the current message is simply inappropriate for many sites, let alone whether it could be more helpful, or different for various scenarios.

I've made a start on at least making the contents of the message configurable in https://git.drupalcode.org/project/drupal/-/merge_requests/8880 in the hope that this could help. I'm well aware some new tests are needed, but hopefully this start demonstrates my thinking. I've tried to take into account what's already been said on this ticket, and on the original 🐛 Ajax errors are not communicated through the UI Fixed .

If we made the contents of the message configurable like this, perhaps actually determining a better 'default' message could be a lower priority follow-up? At least this way sites can own the tone of their error message.

I'm also aware that maybe a follow-up could be needed to determine if there is a better message to describe AJAX errors on the configuration form, hah! At least we may be able to assume a bit more technical capability in that context. There's already mention of 'AJAX' in views' administration forms, for example, so I think it would be OK to mention AJAX there, even if the message itself should not.

james.williams → changed the visibility of the branch 3349901-d10-2-configurable-ajax-error-msg to hidden.

Added test that a changed error message does indeed show on an AJAX exception, which passes. (The test rightly fails in the tests-only scenario, because trying to save the new config property gets flagged as unsupported key.)

Adjusted issue summary etc as allowing the message to be customised might be a more achievable goal than actually finding & agreeing a better default message. I won't be offended if others disagree and this should be reverted! Just looking to keep this moving in a useful direction.

The string is wrapped in Drupal.t() so you should be able to use the standard translation mechanisms to alter the message already? We don't usually provide explicit settings for user-facing strings for this reason - the translation system is preferred, and it also handles the case of multiple languages by default (which I'm not sure the proposed solution does?)

We could still consider improving the default message in this issue.

@longwave thanks for your thoughts. So on a technical level, I can accept that translation could be the only option. But more pragmatically, if I have a enterprise client whose site is only in English, so need none of the language/translation modules, their only option would be to use hardcoded custom strings ($settings['locale_custom_strings_en']), or some extra module to allow translating English interface strings? That's a bit disappointing, but I'll accept it if that's definitely the thinking.

For what it's worth, I did set the new config property to be translatable (via the label type), and handle copying any existing interface translations for the existing string into language config overrides in the update hook in my MR.

Reverting my changes to the issue title & description now.

FWIW for sites where developers are purely in control of the strings I use the $settings option, or if the customer wants to modify strings themselves you can still install locale and interface translation modules, but only have English language installed, and let them edit the English strings in the UI.

Makes sense. The issue I have with that is that the locale module depends on the language module, which then 'pollutes' every entity display with its widgets/components, even when there's only one available language. Which might be fine in many cases, but is much less desirable for my client's case (which already involves a fair bit of complexity in its configuration, with splits for various brands etc).

Anyway, back to the attempt to refine the actual message. How about removing the 'Oops', and incorporating the suggestion from @quietone back in comment 1:

Something went wrong. Your browser's developer console contains more details. Contact the site administrator if the problem persists.

The 'oops' reminds me of the message that was removed from the redirect module over a decade ago - and I reckon Drupal's audience has probably shifted further away from where that tone is normal in the meantime.

james.williams → changed the visibility of the branch 3349901-configurable-ajax-error-msg to hidden.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

james.williams → closed merge request !8882

james.williams → closed merge request !8880

Is there an update on when the function for making this configurable is available?

Not sure a configurable message is the current proposal but more just a potentially better message

Least based on the current issue summary.