Here's my code:
function hfc_user_fboauth_user_presave(&$edit, $fbuser) {
// Save the user's location into a field provided by Profile module.
if (isset($fbuser->location->name)) {
$location = explode(',', $fbuser->location->name);
$settings = isset($location['location_settings']) ? $location['location_settings'] : array();
$edit['field_location']['und'][0]['#value'] = location_empty_location($settings);
$edit['field_location']['und'][0]['#value']['province'] = $location[1];
}
}
That's just trying to take the user's location from Facebook and store it in a location profile field. Here's the error I get:
PDOException: SQLSTATE[HY000]: General error: 1366 Incorrect integer value: '' for column 'field_location_lid' at row 1: INSERT INTO {field_data_field_location} (entity_type, entity_id, revision_id, bundle, delta, language, field_location_lid) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6); Array ( [:db_insert_placeholder_0] => user [:db_insert_placeholder_1] => 194 [:db_insert_placeholder_2] => 194 [:db_insert_placeholder_3] => user [:db_insert_placeholder_4] => 0 [:db_insert_placeholder_5] => und [:db_insert_placeholder_6] => ) in field_sql_storage_field_storage_write() (line 448 of /var/www/hfc-door3/modules/field/modules/field_sql_storage/field_sql_storage.module).
I don't understand why it's trying to post an empty string to field_location_lid. This is a new location (state only), so there is no existing lid to reference. I assume I'm just missing something in my code but I really get what I'm doing wrong. I've also been completely unable to find any examples of someone else trying to do something similar on d.o, so I'm truly stuck.
Comment | File | Size | Author |
---|---|---|---|
#11 | location-n1511638-11-pdo-exception-new-nodes.patch | 639 bytes | ttamniwdoog |
#9 | location-n1511638-8-pdo-exception-new-nodes.patch | 638 bytes | ttamniwdoog |
#6 | location-n1511638-6-remove-empty-check.patch | 779 bytes | ttamniwdoog |
Comments
Comment #1
Nikro CreditAttribution: Nikro commentedI had similar case, but I had to make a custom check for all of the values of the location container (country, state, etc). Use
location_is_empty
to check if the location is actually empty or not.Maybe that'll help.
Comment #2
tomogden CreditAttribution: tomogden commentedSame issue here. For some reason, the hook_save() functions miss saving the location entity first so that they can reference it in the new field value. This is not a problem with an existing location, where you're just changing the location field values.
I suppose I could manually save the location field entity myself before saving the new node entity, but I doubt that's the way it was designed to work. Most likely we are missing some preliminary.
Comment #3
tomogden CreditAttribution: tomogden commentedOkay, here's the answer:
Although the above result is not very graceful, it stems from presenting a location object or entity array that is not distinct enough, according to
location_is_empty()
, as mentioned in comment #1. If your only defined property for a location is the country, and that country is the U.S., then the module passes it as unchanged from the default and won't save it. This is true even if there is no default country defined for the field.Province name and country name are not checked, so If you define the province_name and the country_name, but not the province itself, then it will again see it as empty.
Comment #4
tomogden CreditAttribution: tomogden commentedComment #5
podarok#4 I`m confused
Did You mean it fixed?
Comment #6
ttamniwdoog CreditAttribution: ttamniwdoog commentedInvestigated where the INSERT is failing.
What I was able to determine is that the location['lid'] being FALSE is the reason why it fails.
Function location_save() in the location.module is where this value is being evaluated.
Just after the module does the array_merge() on the location we enter one of two conditions that both return FALSE.
By simply removing these two conditions, I was able to allow nodes to save successfully.
Comment #7
DamienMcKennaComment #9
ttamniwdoog CreditAttribution: ttamniwdoog at Mediacurrent commentedRe-rolling patch
Comment #10
ttamniwdoog CreditAttribution: ttamniwdoog at Mediacurrent commentedComment #11
ttamniwdoog CreditAttribution: ttamniwdoog at Mediacurrent commentedSorry I was rushing there and got sloppy on that last patch. Updated and needs review.
Comment #12
DamienMcKennaThis needs some tests.
Comment #14
podarokMerged. Needs tests.