Change behaviour or how exceptions are silently caught in production and edit mode

[florianschieder]

Description

PR https://github.com/django-cms/django-cms/pull/7423 introduced graceful plugin rendering which is a very reasonable and helpful solution regarding the edit mode.

However, this breaks with existing DjangoCMS code bases when trying to move forward to v4.1:

• If there are plugins raising an exception due to a bug, it's sometimes more reasonable to issue a HTTP 500 instead of simply skipping this plugin. This could have unintended effects since even if there is a monitoring to logging filter such failures, it's still a HTTP 200 and can be cached, read by crawlers and search engines etc.

• It may happen that there is a child plugin raising a specific exception which can be handled by its parent. This applies to the edit mode as well.

In discussion #7953 there was an agreement about introducing a new setting, e.g. CATCH_PLUGIN_500_EXCEPTION = True | False. This setting would only affect the live pages, in preview and edit you should still see the error and the other plugins, or otherwise they would not be editable.

Steps to reproduce

• Implement a plugin raising an Exception

Expected behaviour

Raising particular Exceptions in production should result in a HTTP 500 as in DjangoCMS 3 if a particular setting is set. In preview and edit mode you should still see the error so they are still editable.

Actual behaviour

Raising particular Exceptions in production does not result in a HTTP 500 as in DjangoCMS 3.

Additional information (CMS/Python/Django versions)

django-cms==4.1.1 django==4.2.13 Python 3.12.4

Do you want to help fix this issue?

• [ ] Yes, I want to help fix this issue and I will join the channel #pr-reviews on the Discord Server to confirm with the community that a PR is welcome.
• [X] No, I only want to report the issue.