Problem/Motivation
This is a follow-up to #3106659: Media types with missing source fields break the status report page.
The media system assumes that all media types' source fields are present and accounted for. It does not generally try to gracefully handle missing source fields. Normally that's okay, as it is an explicit assumption of the media system. However, it would be nice if media types with missing source fields were reported as errors on the status report page, so that site builders would be made aware that there is a problem, rather than being surprised with nasty fatal errors when people try to interact with the media system.
Steps to reproduce
Create a media type, and then delete its source field (using drush php or some other under-the-hood mechanism). If you then visit the status report page, you'll get a fatal error (before #3106659: Media types with missing source fields break the status report page is fixed), or no indication that the media type is broken (after).
Proposed resolution
media_requirements() should explicitly report errors for media types whose source field doesn't exist.
Remaining tasks
Write a patch with tests, then review and commit it. Awww yeah.
User interface changes
None.
API changes
None.
Data model changes
None.
Release notes snippet
TBD
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | interdiff_4-9.txt | 2.42 KB | danflanagan8 |
| #9 | 3205866-9.patch | 3.6 KB | danflanagan8 |
| #4 | 3205866-4.patch | 2.48 KB | danflanagan8 |
Issue fork drupal-3205866
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
phenaproximaI've obviously got zero control over this, but I recommend that this change be backported. It should be a big benefit to site builders, with near-zero risk of disruption.
Comment #4
danflanagan8Here's a patch to get the ball rolling here. We haven't defined exactly what the message should be. Not sure if we need UX to approve something. Anyway, this adds a reasonable error and updates the relevant test to check for it.
Comment #5
joachim commentedLGTM!
Comment #6
phenaproximaNo complaints from me either. Un-crediting myself, since I didn't do anything here.
Comment #7
phenaproximaActually, a couple of small requests.
First, this empty() check is now redundant. Could you remove it?
Secondly, it would be clearer if we moved the pre-existing comment, currently living just above your new code -- the one explaining the image stuff -- just above the is_a() check. Meanwhile, we should keep your new comment, about checking for empty fields, where it is. That would make it clearer what each check is actually doing.
Apart from these points, no complaints!
Comment #8
phenaproximaCrediting myself again for patch-shaping feedback. :)
Comment #9
danflanagan8Good ideas, I think. Does this look better? I moved the comments to the appropriate places within the foreach and I also got rid of the redundant empty check.
Comment #10
phenaproximaIt looks great. One small nitpick, if you have time to address it, is that in one line of the new requirement, you call
t(), and in the next line, you usenew TranslatableMarkup(). I think thatt()returns aTranslatableMarkupobject, so IMHO we should uset()in both places for consistency.However, that's not something I care to block commit over, especially since the use of
TranslatableMarkupdoesn't appear to have resulted in an additionalusestatement. So fix it if you feel up to it, otherwise enjoy this RTBC!Comment #11
danflanagan8That inconsistency is a little funny. I started by copying the array for the image style warning message in the same foreach. I think since the new message matches the older code around it, I'll just leave it as it is and revel in the RTBC.
Comment #12
alexpottCommitted and pushed d8b4e40b05 to 9.3.x and 3ea4389651 to 9.2.x. Thanks!
I think this is a bug fix - reporting errors that people need to fix is important.
I fixed the inconsistency - seeing these used next to each other is odd. FWIW now that bootstrap.inc is included by composer functional code can use t() without issue.