field_storage_module needs to be field_storage_default in field.crud.inc [#683028]

Comment	File	Size	Author
#3	file.crud_.inc_.patch	682 bytes	litwol

#1	field_storage_module.patch	682 bytes	litwol

	field_storage_module.wtf_.patch	682 bytes	litwol

Comment #1

litwol CreditAttribution: litwol commented 13 January 2010 at 01:57

File	Size
field_storage_module.patch	682 bytes

Log in or register to post comments

Comment #2

litwol CreditAttribution: litwol commented 13 January 2010 at 01:58

Issue tags:

+Release blocker

Sorry for so many updated.. getting familiarized with submitting core patches.

Log in or register to post comments

Comment #3

litwol CreditAttribution: litwol commented 13 January 2010 at 02:10

File	Size
file.crud_.inc_.patch	682 bytes

Not sure why the patch was ignored.

Log in or register to post comments

Comment #4

litwol CreditAttribution: litwol commented 13 January 2010 at 02:31

Status:

Active

» Needs review

Hopefully that solves the mystery of the ignored patch.

Log in or register to post comments

Comment #5

chx CreditAttribution: chx commented 13 January 2010 at 10:25

Title:	field_storage_module needs to be field_storage_default in file.crud.inc	» field_storage_module needs to be field_storage_default in field.crud.inc
Status:	Needs review	» Reviewed & tested by the community

It's one of those absolutely trivial, small mistakes that undermine the huge efforts to make the storage engine pluggable. But it's so easy to fix. The original post lacks an explanation:

grep -n variable_get *
field.crud.inc:289:    'type' => variable_get('field_storage_default', 'field_sql_storage'),
field.crud.inc:426:  module_invoke(variable_get('field_storage_module', 'field_sql_storage'), 'field_storage_update_field', $field, $prior_field, $has_data);

the two variables need to be called the same and we opted on _default.