Problem/Motivation
Tested the 8.5.x upgrade path on an internal distribution, it fails with this error:
Error: Call to a member function getSetting() on null in ../web/core/modules/datetime/src/Plugin/views/filter/Date.php on line 79
Somehow the field_name was missing in the configuration. This is filter on the end date of a date range field. Quite possibly there is a bug there, but it didn't fail in the UI, just the upgrade path.
Proposed resolution
After a bit of debugging, I noticed the difference, the UI called getHandler(), which adds all missing information dynamically to the plugin configuration from the views data and then calls createInstance(), the post update function calls createInstance() directly.
Remaining tasks
User interface changes
API changes
Data model changes
Comment | File | Size | Author |
---|---|---|---|
#2 | views-post-update-filter-fatal-2936457-2.patch | 831 bytes | Berdir |
Comments
Comment #2
BerdirI guess we can test/reproduce this by deleting some configuration in a default view on purpose in the upgrade path? Not sure if any other filter plugins fail already in the constructor though.
Comment #3
larowlanSo this is only because of broken config - I think we can let this in without a test - feels like we'd be testing something that is specific to a particular site?
Comment #4
larowlanI think this is critical, given it can cause data issues in the upgrade path.
We had a lot of issues in 8.4 update and I'd prefer this was resolved before 8.5.0 to reduce that churn.
If I'm being overzealous, let me know.
Comment #5
BerdirI don't think it causes data issues, the update simply fails with a fatal error without workaround... which happens to be another reason for making it critical. Fine by me obviously, it certainly is a blocking problem for us.
Views updates in general tend to be fragile for us, see also #2925890: Invalid config structures can result in exceptions when saving a config entity. It's complex configuration and re-saving all views does trigger a huge amount of code combined with possibly pretty old and broken configurations.
Comment #6
larowlanSame error on one of my 8.x sites. So yeah, lets resolve this early
Comment #7
Lendude@Berdir++ thanks for finding and fixing this, I'll use getHandler() from now on!
Comment #8
alexpottCrediting @larowlan for testing on his own 8.x sites.
Comment #9
alexpottCommitted and pushed 59a12084d3 to 8.6.x and 14e2ed669c to 8.5.x. Thanks!