Fixing WSOD On Az_person Views In Drupal: A Config Deep Dive

by Editorial Team 61 views
Iklan Headers

Hey guys,

We've been wrestling with a nasty White Screen of Death (WSOD) issue when trying to edit certain az_person Views in the Drupal Views UI. It's been a head-scratcher, especially since the Views YAML in our repository already looks like it's in tip-top shape. So, what's the deal? Let's dive in and figure out how to get those Views playing nice again.

The Curious Case of the WSOD

The Bug Explained

So, here's the lowdown: when you try to edit the az_person View through the Views UI, you're greeted with the dreaded WSOD. The error logs are screaming about a TypeError, specifically complaining about a null value sneaking its way into Html::escape(). This is happening while Views UI is trying to whip up the edit form. Imagine trying to bake a cake but one of your ingredients is just... nothing. That's kinda what's happening here.

The error trace points to the issue popping up when Views UI is building those nifty option links for the View display. It goes something like this:

  • Drupal\views\Plugin\views\display\DisplayPluginBase->optionLink()
  • Drupal\views_ui\ViewEditForm->buildOptionForm()
  • Drupal\views_ui\ViewEditForm->getDisplayDetails()
  • Drupal\views_ui\ViewEditForm->getDisplayTab()

It's like a chain reaction of functions, and somewhere along the line, a null value is crashing the party.

Steps to Reproduce the Issue

Want to see the magic trick (or rather, the not-so-magic trick) for yourself? Here’s how to trigger the WSOD:

  1. First, log in as a user who has the power to administer Views. You know, someone with the keys to the kingdom.
  2. Navigate to Structure → Views. This is where all the Views hang out.
  3. Find the az_person View (or any other View related to people that's giving you grief) and hit that Edit button.
  4. Boom! Observe the WSOD or the fatal error rearing its ugly head as the View edit form tries to load.

Decoding the Root Cause

Now, let's put on our detective hats and figure out why this is happening. Since the Views config in the repository seems all good, simply re-exporting the config won't solve the mystery. The problem seems to be that the active configuration on some sites isn't playing ball. It's like the config in the database hasn't been updated or normalized properly.

The suspicion falls on unexpected null values lurking in the active config, probably related to the Views pager configuration. It's like Drupal is expecting a 0 (zero) but finds a null instead. Awkward! This schema normalization issue is likely the culprit.

Proposed Solutions to Banish the WSOD

Alright, so how do we fix this mess? Here are a couple of approaches we can take to ensure those affected sites get their active configuration updated and those pesky null values are kicked to the curb:

Option 1: Quickstart Database Update to the Rescue

We could whip up a Quickstart database update that specifically targets and fixes the affected Views config in the active config. Think of it as a config janitor, going in and replacing those null values with 0s where appropriate. It's a surgical approach to cleaning up the data.

This ensures that every site running the update gets the fix applied directly to their database. The update script would need to:

  • Identify the affected Views, specifically those related to az_person or similar entities.
  • Locate the pager configuration within the View's settings.
  • Check for any instances where a pager setting is set to null.
  • Replace those null values with 0.
  • Run the drush updb command to apply the database updates.

Option 2: Investigate Drupal Core and Config Distro

Another avenue to explore is whether a Drupal core database update was supposed to handle this during a Views schema change. If so, we need to figure out why some sites missed the memo. It could be that Quickstart or config_distro behavior is interfering with the update process. It's like a game of telephone, and the message isn't getting through.

This involves:

  • Checking the Drupal core release notes and change logs for any relevant Views schema updates.
  • Examining the database update scripts in Drupal core to see if there was an intended normalization process for Views pager settings.
  • Investigating whether the config_distro module is preventing the core update from being applied correctly.
  • Adjusting the config_distro settings or updating the module to ensure compatibility with Drupal core updates.

This approach requires a deeper understanding of Drupal core's update mechanisms and how they interact with contributed modules like config_distro. It's a more involved process but can prevent similar issues from occurring in the future.

Related Prior Work

For some context, there's some related prior work that might shed some light on this issue. Check out this GitHub pull request for more details.

The Desired Outcome

What we're aiming for is simple: administrators should be able to edit az_person Views (and any other affected Views) through the Views UI without being slapped in the face by a WSOD. We want a smooth, frustration-free editing experience.

Additional Context and Observations

This issue isn't a one-off thing. It seems to be popping up across multiple sites, which suggests it's not just a quirky problem with a single View. Initially, the thought was to re-export the Views config, but as we've established, the Views YAML in the repo is already looking good. This reinforces the idea that the problem lies with site-level active config not being updated or normalized. This could be tied to config_distro behavior or a Drupal core Views schema update that was supposed to update existing Views config in the database but didn't quite make it.

Next Steps

To move forward, we need to:

  1. Prioritize creating that Quickstart database update to directly address the null value issue. This will provide an immediate fix for affected sites.
  2. Investigate the Drupal core update process and config_distro to understand why the core update didn't normalize the Views config as expected.
  3. Implement preventative measures to ensure that future Drupal core updates are applied correctly and don't get blocked by config_distro.

By taking these steps, we can not only resolve the current WSOD issue but also prevent similar problems from occurring down the road. It's all about creating a more robust and reliable Drupal experience for everyone.

Conclusion

So, there you have it! The WSOD issue with az_person Views is a bit of a puzzle, but with a combination of targeted database updates and a deeper understanding of Drupal's update mechanisms, we can solve it. Let's get those Views working smoothly again! And please, let me know in the comments if you have other tips.