Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
When building a site with lots of fields, using features, I got this Fatal error:
FieldUpdateForbiddenException: Cannot update a list field to not include keys with existing data. in list_field_update_forbid() (line 350 of /.../modules/field/modules/list/list.module).
Unfortunately, the error message gives _no_ clue as to which field is causing the update error.
The attached patch simply adds the field name to the error message, as the $field variable is already in scope, it's a trivial change but helps the debug process immensely.
Same example with patch
FieldUpdateForbiddenException: Cannot update a list field (field_somefield_name_here) to not include keys with existing data. in list_field_update_forbid() (line 350 of /.../modules/field/modules/list/list.module).
See attached.
DT
Comment | File | Size | Author |
---|---|---|---|
#14 | drupal-improved_error_reporting_7.x-1294264-14.patch | 874 bytes | budda |
#9 | drupal-improved_error_reporting-1294264-9.patch | 894 bytes | budda |
#5 | drupal-improved_error_reporting_7.x-1294264-5.patch | 923 bytes | budda |
#4 | drupal-improved_error_reporting-1294264-4.patch | 943 bytes | budda |
better-data-exists-debug-info.list_.module.patch | 928 bytes | davidwhthomas | |
Comments
Comment #1
marcingy CreditAttribution: marcingy commentedI'm thinking this is really a task, it needs to go into d8 first on the surface the message seems ok but I'd like more input from others before rtbcing.
Comment #2
larowlanGot caught with this one too.
Comment #3
webchickFix makes sense. The grammar in that sentence is frightfully awkward. Since we're breaking the string anyway, can we make it something like:
"A list field (@field_name) with existing data cannot have its keys changed."
Comment #4
buddaAlso caught by this confusing message
Improved error message. Drupal 8 patch attached.
Comment #5
buddaAnd for Drupal 7 the same patch attached (but with the right file structure).
Comment #7
buddaPatch on comment 4 is for drupal 8 and implements the requested string change from comment 3.
Comment #8
Dries CreditAttribution: Dries commentedThe wrapping seems to violate our coding standards.
Comment #9
buddaI've removed all wrapping as the line isn't as long as others in the same list.module
Using Features in D7 seems to kick this error up frequently so will be happy when it's in and back-ported so it makes some sense!
Comment #10
marcingy CreditAttribution: marcingy commentedLooks good only change from #5 is wrapping
Comment #11
buddaI've got the Drupal 7 backport patch ready to upload here too. That's the one I want sooner.
Comment #12
budda#9: drupal-improved_error_reporting-1294264-9.patch queued for re-testing.
Comment #13
catchLooks good. Committed/pushed to 8.x. Moving back to 7.x for backport. This is a string change, but it's also an error message so seems OK to tweak.
Comment #14
buddaAttached is the Drupal 7.x version of the message patch.
Comment #15
buddaThe patch is the same as the already reviewed and committed Drupal 8.x one, except on a different file path.
We're using it already internally at Ixis without problems for past 3 weeks.
Comment #16
xjmHmm, I thought error messages were the worst strings to break translations for? So I'm not sure we can backport this.
Comment #17
buddaIt's a technical error message rather than a user interface string. So not being covered by a translation doesn't seem so critical?
Comment #18
budda.
Comment #19
webchickYeah, generally we aren't supposed to backport these, however in this case the error message is so unhelpful as to be considered a bug.
Committed and pushed to 7.x. Thanks!
Comment #21
webchickx
Comment #21.0
webchickFormatting fix