[PP-1] 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.

RE: #20 and @quietone's proposed message

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

I don't like the 'Contact the site administrator if the problem persists.' It is too generic. There are lots and losts of other core error messages that you could append that sentence to. And IMO it would not be helpful. It sounds a little opinionated. 'Oops' is a little patronising at the other end of the scale. Opinionated in the sense that although every Drupal site has a user 1 'Site administrator' account, there will be plenty of organisations using Drupal who do not have a clear IT hierarchy with an identifiable 'Site administrator.'

It would be interesting to do a survey but I would guess that in a typical charity or SME business the whereabouts and identity of the 'Site administrator' might be unknown if not unknowable. There will often be several possible 'Web savvy Samantha or Bobs' or maybe the guy at the next desk.

I think the message should be pitched at those who know what browser developer tools are and how to access the console. If they dont know then we can assume they will reach out to others for help without our suggesting it.

RE #19 and #20, @james.williams, I believe a more clinical way of changing this error message is by an event listener, listening for kernel events ie in a custom module. If you are into Symfony the Symfony docs might help. I believe you can listen for the Error being triggered, intercept it and override the message.

There's nothing to review here now that the direction has changed. I think our next step is to propose and agree on a better default.

Perhaps

An Ajax-related error has occurred. Check your browser's console for further details.

I recently looked at a way on how to expose access denied messages a bit better instead of simply showing the "Oops" message and found this issue here.

Looking at the MR i think it's a good start and I had some ideas on how to improve this a bit further. Here some proposals:

1. we can actually make this a) more useful for developers (if error logging is set to verbose) by putting whatever is contained inside xmlhttp.responseText into the message instead of the hardcoded "Oops" or the configurable message from the MR above. That would be a nice DX improvement, it'd enable instant view of backtraces and error messages in the message instead of having to look that up in the console after an ajax error. This should probably only be happening when $config['system.logging']['error_level'] is set to verbose
2. As for cases where the "Oops" message is shown after an access denied exception inside an ajax call, we could possibly display access denied reasons based on the reason specified in an instance of AccessResultReasonInterface. This should probably be configurable as well.
3. Whenever an ajax error message is displayed it would probably make sense to scroll the window to the message as otherwise it's easy to miss on pages with a height that's higher than the viewport.

Adding a PoC patch that addresses the first two points here for reference. It's definitely not ready for production but could possibly serve as a base for making further improvements before merging the MR here. Note the todos and also that the patch is against 10.3.x.