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.
Hi, I'm using a custom fetcher/parser after upgrade (2012-05-30) I got a "Invalid enclosure" for remote attachments.
This is caused by a string concatenation in $destination in feeds/plugins/FeedsParser.inc, FeedsEnclosure::getFile
$destination .= trim($destination, '/') . '/';
$destination = trim($destination, '/') . '/';
Comments
Comment #1
pedrop CreditAttribution: pedrop commentedThank you muka, this worked for me.
Comment #2
5n00py CreditAttribution: 5n00py commentedSame issue!
Comment #3
conantp CreditAttribution: conantp commentedExperienced the same issue, the suggested fix worked for me!
Comment #4
wolffereast CreditAttribution: wolffereast commentedSame problem, Thanks for the fix!
Comment #5
Anonymous (not verified) CreditAttribution: Anonymous commentedExperienced the same issue, I found (by myself) the same fix.
I just add an additional error message in order to allow search engine to locate more easily this fix.
"The specified file temporary://file could not be copied, because the destination directory is not properly configured. This may be caused by a problem with file or directory permissions. More information is available in the system log."
"Le fichier spécifié temporary://file n'a pas pu être copié car le répertoire de destination n'est pas correctement configuré. Cela peut être dû à un problème de permissions sur le fichier ou le répertoire. Plus d'informations sont disponibles dans la journalisation du système."
Comment #6
coreyp_1 CreditAttribution: coreyp_1 commentedMarking as a duplicate of #1611656: Images import doesn't work.
Comment #7
Rob_Feature CreditAttribution: Rob_Feature commentedReopening this issue and marking #1611656: Images import doesn't work as duplicate since there are more comments here who have confirmed that this fix works for them. Also marking as reviewed and tested unless anyone else has had issues with this fix?
Comment #8
franzThis was introduced by #1515204: Malformed destination uri in FeedsEnclosure, I should've noticed, but at that time my testing didn't point any failure.
Committed this.
Comment #9
p55mac CreditAttribution: p55mac commentedWorked for me. Thanks!
@Teenage, good idea.
Comment #10
kdhartstrom CreditAttribution: kdhartstrom commentedFix worked for me.
Comment #12
wel3kxial CreditAttribution: wel3kxial commenteddone this but still invalid enclosure...
Comment #13
wel3kxial CreditAttribution: wel3kxial commentedUsing feeds-7.x-2.0-alpha5
Comment #14
dallen CreditAttribution: dallen commentedHi wel3kxial,
Are you on a multi-site install perchance?
I'm on a multi-site install and it's not working for me either.
Thank you.
Comment #15
wel3kxial CreditAttribution: wel3kxial commentedno I am just sing site install. the code was orignially $destination = trim($destination, '/') . '/';
but still error.
Comment #16
dallen CreditAttribution: dallen commentedWe are send nodes from on site to another via XML. But both sites are on the same stack or in the same docroot.
The problem was in function getFile in FeedsParser.inc.
The function drupal_realpath test was returning that the image file was local because we're on multi-site.
But the file_copy function was unable to find the image file in the site's file folder.
---
I've temporarily 'fixed' it by replacing "if (drupal_realpath($this->getValue()) {" with "if (drupal_realpath($this->getValue()) && strpos($this->getValue(), "http")===false) {".
---
Thank you.
Dave.
Comment #17
MrPeanut CreditAttribution: MrPeanut commentedI'm getting this same issue on a local install (single site). I successfully imported 707 items, but 176 received the invalid enclosure error. The code is correct in FeedsParser.inc.
I found that my issue was with duplicate file names. Might be something worth checking into.
Comment #18
BiigNiick CreditAttribution: BiigNiick commentedthe original fix worked for me, but in fields where invalid images do not produce an error. it just shows an empty file field with the ? in it on the node.
Comment #19
enricotersi CreditAttribution: enricotersi commentedFix worked for me.
Comment #20
Jorrit CreditAttribution: Jorrit commentedThe fix works for me as well. I'd love to see a new alpha release. It has been a long time since the last alpha release.
Comment #21
kurtzhong CreditAttribution: kurtzhong commentedI still get this error with the patch
Comment #22
Jorrit CreditAttribution: Jorrit commentedWhen I click that image link, it isn't working for me either, so I think there is just something wrong with the link, not the code.
Comment #23
kurtzhong CreditAttribution: kurtzhong commentedSo my problem is that i am importing from a remote CSV file that got too many broken image urls in it. Is there a good workaround to handle the timeouts? I find it takes too long to finish the import. I noticed that in the code, seems like for each broken link the it will wait 30 seconds until it fails:
curl_setopt($download, CURLOPT_TIMEOUT, variable_get('http_request_timeout', 30));
So by setting the variable
http_request_timeout
to a lower value will help shorten the import time? And will this have some other impact?Comment #24
kurtzhong CreditAttribution: kurtzhong commentedSo my problem is that i am importing from a remote CSV file that got too many broken image urls in it. Is there a good workaround to handle the timeouts? I find it takes too long to finish the import. I noticed that in the code, seems like for each broken link the it will wait 30 seconds until it fails:
curl_setopt($download, CURLOPT_TIMEOUT, variable_get('http_request_timeout', 30));
So by setting the variable
http_request_timeout
to a lower value will help shorten the import time? And will this have some other impact?Comment #25
kurtzhong CreditAttribution: kurtzhong commentedSo my problem is that i am importing from a remote CSV file that got too many broken image urls in it. Is there a good workaround to handle the timeouts? I find it takes too long to finish the import. I noticed that in the code, seems like for each broken link the it will wait 30 seconds until it fails:
curl_setopt($download, CURLOPT_TIMEOUT, variable_get('http_request_timeout', 30));
So by setting the variable
http_request_timeout
to a lower value will help shorten the import time? And will this have some other impact?Comment #26
kurtzhong CreditAttribution: kurtzhong commentedSo my problem is that i am importing from a remote CSV file that got too many broken image urls in it. Is there a good workaround to handle the timeouts? I find it takes too long to finish the import. I noticed that in the code, seems like for each broken link the it will wait 30 seconds until it fails:
curl_setopt($download, CURLOPT_TIMEOUT, variable_get('http_request_timeout', 30));
So by setting the variable
http_request_timeout
to a lower value will help shorten the import time? And will this have some other impact?Comment #27
Jorrit CreditAttribution: Jorrit commentedThe error is returned pretty quickly, so I don't think that is the problem.
Comment #28
walker2238 CreditAttribution: walker2238 commentedI still get this error as well...
Comment #29
walker2238 CreditAttribution: walker2238 commentedAfter further testing I noticed the errors don't appear if I change the image fields directory to be specific to the content type.
Comment #30
glynnr CreditAttribution: glynnr commentedIn case this helps anyone struggling with this. I had this error as well, and after using the temporary fix in #16 (thanks Dave) found this thread :
http://drupal.org/node/1246418
Which is also quoted here : http://api.drupal.org/api/drupal/includes%21file.inc/function/drupal_rea...
Comment #31
salade-de-phalanges CreditAttribution: salade-de-phalanges commentedHello,
For local file (with csv), i have a good result with this solution. Surely not the best but some fast.
put your images in the public repertory of Drupal (surely sites/all/files). Create a hook_feeds_after_parse (or rewrite your csv).
CSV IMPORT
To escape files doublon
modify feedsParser.inc in line 355 :
$file = file_copy($file, $destination, FILE_EXISTS_REPLACE);
like this drupal don't create another "file". if you read the code, you can see thaht a file_copy is made with is default argument (FILE_EXIST_RENAME), so the file is always rename when a file with the same name exist. This solution is usefull if you have a same image attatch to several content.
Comment #32
ieta_maher CreditAttribution: ieta_maher commentedHello,
For images the errors occurs when we have an url like this : http://blogs-images.forbes.com/thumbnails/blog_1370/pt_1370_727_o.jpg?t=...
but if the image ends normally there isn't a problem.
Comment #33
Summit CreditAttribution: Summit commentedHi,
I needed to do http://drupal.org/node/1612246#comment-6326658 before it worked!
Can this temporally fix may be become real fix? May be to set this through the GUI that images are local or remote?
Thanks for considering.
Greetings, Martijn
Comment #34
Summit CreditAttribution: Summit commentedHi,
Latest Feeds the change was
from:
to:
I am not in position to build patch, please build patch and commit!
Greetings, Martijn
Comment #35
k.dani CreditAttribution: k.dani commentedI have some problems with the parsed data, when I would like to save an image in Drupal from an external source. I use the latest dev release of Feeds 7.x-2.x and Feeds XML Parser.
I relaized that all of the parsed data is structured like that: "\nSOME VALUE\n"
It seems that the file_save_data() can't handle the starting and ending new line and throw an error. If I trim the return value of getValue() method in FeedsElement class, the problem disappears.
Change code
from:
to:
Comment #36
twistor CreditAttribution: twistor commentedThis issues was opened 6 months after it was closed. It was a very specific issue that was fixed. Please! don't re-open old issues.
Edit: removed ranting.
Comment #37
k.dani CreditAttribution: k.dani commentedSorry, I didn't realize it was closed. I've created a separated issue for that.
Comment #38
chefnelone CreditAttribution: chefnelone commentedIs this commited to dev? If not, where is fix?
Comment #39
WSVereen CreditAttribution: WSVereen commentedLate to the discussion here but I am verifying that the original solution did not work for me as the code already had been changed as other users had stated. I did find a solution to the invalid enclosure problem by adding a Feeds Tamper plugin of Strip Tags to the image field.
Comment #40
ethanhinson CreditAttribution: ethanhinson commented#16 worked for me! Based on the documentation for drupal_realpath, a different check should be used to determine the location (ie local vs remote) for files.
Comment #41
CyberBizness CreditAttribution: CyberBizness commentedI replace the line 348 of FeedsParser.inc by :
if (drupal_realpath($this->getValue()) && !(stripos($this->getValue(), "http:")>-1) && !(stripos($this->getValue(), "http:")>-1) ) {
and it's ok for me ;-) C'est peut-être pas "élégant". But it works!
- stripos instead of strpos (just in case http is in capitals)
- "http:" instead of "http", cause some files may have "http" somewhere in their name.. or path.
- added a stripos for "https:"
- compare integer returned value instead of using bolean value
*** And make sure you don't have any 401 error regarding basic authentification.
and commented out line 378 : $destination = trim($destination, '/') . '/';
Comment #42
nazarioa CreditAttribution: nazarioa commentedSo I just ran into this issue with version '7.x-2.0-beta1' of the module.
I altered the module's code per Summit's description (from almost two years ago) and it worked like a charm.
Comment #43
molenick CreditAttribution: molenick as a volunteer commentedI'm also getting this error with 7.x-2.0-beta1, it pops out on line 407 of FeedsParser.inc.
I tried @nazarioa's change but it wasn't enough - the full error showed that a %20 was being prepended to my url. I did a quick and dirty test of replacing 407 to:
This is a multisite install, which I'm mentioning because others had a similar problem much earlier. Not sure why the %20 or whitespace is getting prepended, it's not in the original data source.
Comment #44
helmo CreditAttribution: helmo at Initfour websolutions commentedThe separate issue @k.dani mentions in #37 is #2202817: New line in parsed url breaks image saving
I've posted a patch there to continue the discussion.