Handle exceptions gracefully when saving node forms

Created on 23 October 2016, over 8 years ago
Updated 20 March 2025, about 1 month ago

Problem/Motivation

Node forms do not properly handle errors that occur while saving nodes.

Steps to reproduce:

It is possible to hide the node title or other required fields from the form display, but this causes an uncaught exception when saving the node/entity because a title/field actually is required:

Uncaught PHP Exception Drupal\\Core\\Entity\\EntityStorageException: "SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'title' cannot be null

  • Go to Structure -> Content types -> Basic page -> Manage form display
  • Drag Title to Hidden region then click Save
  • Add new content for Basic page
  • You will see "The website encountered an unexpected error. Please try again later."
  • Go to /admin/reports/dblog
  • You will see the Exception in the logs

Proposed resolution

Catch and log errors.

Doing this generically for other entities is handled by #3160721: Handle exceptions gracefully when saving entity forms β†’ . This fixes the most common use case, now, before attempting to fix everywhere in a more standard way ( See #63 πŸ› Handle exceptions gracefully when saving node forms Needs work ).

Remaining tasks

None.

User interface changes

A message is shown to the user if the node save fails.

API changes

None.

Data model changes

None.

πŸ› Bug report
Status

Needs work

Version

11.0 πŸ”₯

Component

node system

Created by

πŸ‡¨πŸ‡³China rcbcool

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • First commit to issue fork.
  • πŸ‡¦πŸ‡ΊAustralia acbramley

    Manually rolled into an MR

  • Pipeline finished with Failed
    about 1 month ago
    Total: 186s
    #452790
  • Pipeline finished with Success
    about 1 month ago
    Total: 738s
    #452797
  • πŸ‡ΊπŸ‡ΈUnited States smustgrave

    Does #76 still apply here?

  • πŸ‡¦πŸ‡ΊAustralia acbramley

    I'm not sure, the way I read it was that the current solution is fine for this. I haven't looked for another issue but that doesn't need to block this.

  • πŸ‡¨πŸ‡­Switzerland berdir Switzerland

    I think it we should do that, alexpott also agreed, the wrapped exception is almost useless.

  • πŸ‡¦πŸ‡ΊAustralia acbramley

    I think it we should do that

    Are you able to expand on exactly what we should do?

  • πŸ‡¦πŸ‡ΊAustralia acbramley

    So maybe we could just add $e = $e->getPrevious() ?: $e, at least until we have a better default handling of the backtrace including previous exception(s).

    From #72

    I'm guessing this is it? I've pushed that. Having issues getting gitlab to rerun the failed tests (assuming a random) but this should be ready for a re-review.

  • πŸ‡¦πŸ‡ΊAustralia acbramley

    Adding before/after screenshots.

  • πŸ‡¦πŸ‡ΊAustralia acbramley

    I tested the exception backtrace with and without the getPrevious() and IMO (for the issue described in the IS at least with missing a title) I find the backtrace without the getPrevious easier to parse.

  • πŸ‡¦πŸ‡ΊAustralia acbramley

    Uploading sample stacktraces

  • πŸ‡¬πŸ‡§United Kingdom jonathanshaw Stroud, UK

    I can see the argument that the previous is more precise. I don't think it matters either way.

  • πŸ‡¨πŸ‡­Switzerland berdir Switzerland

    > I find the backtrace without the getPrevious easier to parse.

    Yes, but it also has less information. It's kind of minor for the title case, but try it for when for example a hook_node_update() implementation that throws an exception (which is what the test is doing) because it tries to access a field that doesn't exist. Having that information in the backtrace is a lot easier to finding where it's coming from.

Production build 0.71.5 2024