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.
Notice: Undefined index: type in drupal_write_record() (line 6663 of /Users/dave/Sites/drupal-head/includes/common.inc).
Notice: Undefined index: type in drupal_write_record() (line 6700 of /Users/dave/Sites/drupal-head/includes/common.inc).
This is because $info['type'] does not exist on these fields.
Comments
Comment #1
dalinI believe this just needs a few isset($info['type']), but I'm not familiar enough with cross-db data types to know for sure.
Comment #2
Crell CreditAttribution: Crell commentedIMO we should look into why $info['type'] doesn't exist in the first place. I'd consider that a deeper bug. Really, isset() is a bad way to respond to undefined variables in a definition array. :-) Proper defaults are the right way.
Comment #3
dalin@crell most of the time I would agree with you. However I should have elaborated, this happens when you have a field something like this:
As I understand it, it isn't possible to come up with a value for 'type' in this case.
Comment #4
Damien Tournoud CreditAttribution: Damien Tournoud commentedI would just add a NULL 'type' in _drupal_schema_initialize().
Comment #5
jbrown CreditAttribution: jbrown commentedThe 'type' key is not optional.
Comment #6
Damien Tournoud CreditAttribution: Damien Tournoud commented@jbrown: yes, it is.
Comment #7
dalinAdded a NULL 'type' in _drupal_schema_initialize().
Comment #8
moshe weitzman CreditAttribution: moshe weitzman commentedagree with the fix.
Comment #9
webchickThis needs tests.
Comment #10
Vacilando CreditAttribution: Vacilando commentedRan into the same problem, found this issue, applied dalin's patch from #7 and the notices disappeared.
Comment #11
j4 CreditAttribution: j4 commentedworks for me too..
Jaya
Comment #12
naringas CreditAttribution: naringas commentedHad this problem in 7.10 using my custom module code (which also has a schema like #998632-3: drupal_write_record() throws PHP notices if any fields use DB-specific data types).
I applied patch in my development server and it fixed the issue (after a cache flush).
Comment #13
Vacilando CreditAttribution: Vacilando commentedBump. The patch in #7 has worked for me again, on a different system, in D7.14.
Comment #14
cjoy CreditAttribution: cjoy commentedpatch in #7 worked fine on 7.15, no more notices caused by the following schema field:
Comment #15
tonylegrone CreditAttribution: tonylegrone commentedAdding a NULL type to hook_schema also fixed this bug for me without applying the patch.
Comment #16
poker10 CreditAttribution: poker10 at ActivIT s.r.o. commentedThis is a bit old, but according to the schema documentation (https://www.drupal.org/docs/7/api/schema-api/schema-reference):
According to this I think that it would probably be sufficient to update the schema documentation page to include an information, that if someone uses a DB-specific type, it is also needed to put a
NULL
to thetype
parameter (like it was mentioned in #15).If we want to go the other way and add a "safety net" (see #7), then I have created a test for this. Reuploading the original patch (with slightly modified comment) with the test added. We will discuss which approach will be better in D7.
Just a note,
_drupal_schema_initialize()
was removed in D10, so we can proceed independently with this D7 issue.Comment #17
mcdruidI think this looks good.
Here's a test-only patch.. I'll also re-upload the full patch from #16 so we can have the most recent patch passing.
Comment #19
mcdruidI'm happy to RTBC (/ RTBM) this as my last patch was just splitting out the tests to show that they fail in isolation.
Comment #21
poker10 CreditAttribution: poker10 at ActivIT s.r.o. commentedCommitted, thanks everyone!