There has been a critical error on this website.

[dandavince]

When you present us with this generic error you might as well tell us more so we get a chance to debug. WordPress encounters an error and you HAVE info to give us. So pls make it a useful message that can help us find the bug. YES it is often plugins or themes - but give us a hint pls!

Today I upgraded WordPress. I only use 6 solid well known plugins and the DIVI4 theme. Everything worked BEFORE the update but not after.

You already know at this time in execution, a lot about the error. Give us that info on this page instead of a generic message! Make this a useful debug page. NO not the debug log - ordinary users dont stand a chance. Info on this page pls!

[rollybueno]

Hello, there's a reason why this is a generic message since it's on the public facing. What you can do is enable debugging on your config file, which provides more detailed logs regarding your bugs and start from there.

Check more on ​https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/

Also, I'm not sure if this will be treated as trac ticket since this is more on support forum side in my opinion. I'll leave to the commiter to decide if this should be closed or we improve the message.

[johnbillion]

I agree that more often than not, it's frustrating seeing this critical error screen without it including any technical information about the error. It adds extra steps to the debugging process.

I would be in favour of including the error message and stack trace but hiding it behind a toggle (eg using a <details> element so functional JavaScript isn't required). The idea being that a regular visitor to the site should not see technical information unless they click through to it, and the site owner can still access the info when they need it.

The main concern is whether it's undesirable to expose technical details when WP_DEBUG is not set to true. This is the reason the underlying error message is only shown on the critical error screen when WP_DEBUG is true.

I think this deserves some more discussion. Needs to take into account recovery mode too.

[aarti1318]

@dandavince I understand the need to avoid exposing technical details publicly, and fully agree that the current screen exists to protect sensitive information for non-technical site owners.

However, I think there is a middle ground that improves the user experience without compromising security.

My suggested direction:

• Continue showing the generic “There has been a critical error” message by default.

• Add a non-JS <details> debug section only visible to logged-in administrators, even when WP_DEBUG is false.

• The section could include:
  • the error message (sanitized)
  • the file + approximate line
  • a short suggestion like “This is most likely caused by plugin: X” if detected from the stack trace

• For visitors, nothing changes — they still only see the generic safe error page.

• For recovery mode, the enhanced information would integrate with the existing “broken plugin” identification logic.

This keeps technical info secure + only accessible to admins, while finally reducing the frustration of having to enable debug mode (which many users don’t know how to do or don’t have file access for).

This would make the critical error screen both safer and more useful, and aligns with the idea that the site owner should get actionable information without needing hosting-level access.

I’m happy to work on testing or refining this approach if the core team is interested.