Contrib.social

Use php configs error_prepend_string and error_append_string

Open on Drupal.org →
Created on 11 April 2025, 13 days ago

Problem/Motivation

I'm a person who enjoys dark mode on all my things, and I had the bright idea of looking into styling the infamous php "White screen of death". There are options to prepend and append text strings to the standard PHP error response. So I tried setting up my local ddev environment with this custom my-php.ini:

[PHP]
error_prepend_string= "<style>@media (prefers-color-scheme: dark) {* {background-color: black;color: #ff6b6b;font-family: monospace;font-size: 1.2em;}}@media (prefers-color-scheme: light) {* {background-color: white;color: red;font-family: monospace;font-size: 1.2em;}}</style>";"

Which will follow the user's system's "prefers-color-scheme" directive, and optionally display a WSOD in dark mode.

To my confusion, this doesn't work in Drupal. While it did in my initial tests, which were composed of adding a call to a non-existent blah() function in index.php. I eventually figured out is due to Drupal overriding the error handler, and sending it's own response. My early testing worked in prepending the error response, because the error happened before Drupal's custom error handler's were loaded.

Proposed resolution

Can we either read the system's php config, and follow the intent of these options by prepending/appending these text strings to the response? I suppose we could also look into a more "Drupally" way of allowing devs to alter the error response, but it seems like if there are existing conventions provided by the system, we can use those?

Release notes snippet

Apply php's error_prepend_string and error_append_string configurations to Drupal's custom error php response page.

✨ Feature request
Status

Active

Version

11.1 🔥

Component

base system

Created by

🇺🇸United States bburg Washington D.C.

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

Comments & Activities

  • Issue created by @bburg
  • Comment 13 days ago →
    🇺🇸United States bburg Washington D.C.

    Just uploading an example patch to show how straightforward this could be.

  • Comment 13 days ago →
    🇺🇸United States bburg Washington D.C.

    And a 10.4.x version of the patch for those who want to try it out on that version.

  • Comment 13 days ago →
    🇳🇿New Zealand quietone

    Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → .

  • Comment 13 days ago →
    🇳🇿New Zealand quietone

    And while I am here, this needs a title update. The title should be a description of what is being fixed or improved. The title is used as the git commit message so it should be meaningful and concise. See List of issue fields → .

  • Comment 12 days ago →
    🇺🇸United States bburg Washington D.C.

    Thanks, I may have fat-fingered that version option. With some more testing, it seems there are actually different error handlers for thrown exceptions versus other fatal errors. Calling this_does_not_exist() will be handled by the code referenced in my patch file, but exception handling seems to be managed by Symfony, I poked at it for an hour or so, and don't see any way to get symfony to do the same as what we are trying here yet.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024