I'm adding embedded videos to nodes via Embedded Media Field (emfield), but I get an error with DailyMotion in a specific instance. Other Media providers (YouTube and Vimeo specifically, work fine).
If I preview my node before saving, I am unable to actually save the node with the embedded media due to an error..
PDOException: SQLSTATE[23000]:
Integrity constraint violation: 1062 Duplicate entry 'dailymotion://video_id/x1571hb' for key 'uri': INSERT INTO {file_managed} (uid, filename, uri, filemime, filesize, status, timestamp, type) 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, :db_insert_placeholder_7); Array ( [:db_insert_placeholder_0] => 1 [:db_insert_placeholder_1] => x1571hb [:db_insert_placeholder_2] => dailymotion://video_id/x1571hb [:db_insert_placeholder_3] => video/dailymotion [:db_insert_placeholder_4] => 0 [:db_insert_placeholder_5] => 1 [:db_insert_placeholder_6] => 1380751246 [:db_insert_placeholder_7] => video ) in drupal_write_record() (line 7139 of /site/includes/common.inc).
It looks like Media:DailyMotion is saving the file object in getFileObject()
without passing anything to the optional $use_existing parameter. It looks like this parameter in file_uri_to_object
in Media module is false by default, so it's trying to add the same file again instead of using the existing object.
Anyhow, changing this:
public function getFileObject() {
$uri = $this->parse($this->embedCode);
return file_uri_to_object($uri);
}
To this:
public function getFileObject() {
$uri = $this->parse($this->embedCode);
return file_uri_to_object($uri, TRUE);
}
fixed things for me.
Proposed patch w/ changes noted above attached.
Comment | File | Size | Author |
---|---|---|---|
media_dailymotion-useExistingFileObject.patch | 539 bytes | kristomo |
Comments
Comment #1
kristomo CreditAttribution: kristomo commentedComment #2
marvil07 CreditAttribution: marvil07 commentedI could not really reproduce the problem.
In the other side, the change does not really change current behavior, since default value for second parameter is TRUE.
If you know how to reproduce the problem, please reopen the issue with more details.
BTW the mentioned error sounds like one core bug that was solved on a point release.