Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 UTC on 18 March 2024, to get $100 off your ticket.
I am using PHP Version 5.4.6 on 1ubuntu1.1 and I keep getting this error when using mimemail with no file set. In the code, if no file is set then $file is given the value of the content, which in this case is a string, line 180 of mimemail.inc.
// We have the actual content.
elseif ($content) {
$file = $content;
}
Later on this value for 'file' is tested using is_file(), line 311
if (isset($part['file'])) {
$file = (is_file($part['file'])) ? file_get_contents($part['file']) : $part['file'];
$part_body = chunk_split(base64_encode($file), 76, variable_get('mimemail_crlf', "\n"));
}
Clearly my version of php does not like this when 'file' is a string such as contents of pdf. I'm not sure what the solution is but clearly a test is needed to determine whether or not the string passed is a valid path. But then, what is a "valid path"?
Comment | File | Size | Author |
---|---|---|---|
#22 | mimemail-2057703-22.patch | 1.75 KB | sgabe |
Comments
Comment #1
NewZeal CreditAttribution: NewZeal commentedAs an immediate fix I have done the following:
Added another value to the array called file_content which is a boolean so that in _mimemail_file() it is set to true when there is no file. Then the offending error can be removed thus:
Comment #2
dscutaru CreditAttribution: dscutaru commentedSomething similar in beta-1
Warning: realpath() expects parameter 1 to be a valid path, string given in drupal_realpath() (line 2269 of /var/www/drupal-7/includes/file.inc).
Warning: is_file() expects parameter 1 to be a valid path, string given in mimemail_multipart_body() (line 319 of /var/www/drupal-7/sites/all/modules/mimemail/mimemail.inc).
made small changes to fix, patch:
Comment #3
sgabe CreditAttribution: sgabe commentedPatch file attached based on #2, changing status.
Comment #5
pontoffeltier CreditAttribution: pontoffeltier commentedGot the same errors :-/
Anyone know a way around this? I am trying to send a PDF with this:
Comment #6
pasive CreditAttribution: pasive commented@pontoffeltier your solition should be working if you apply a full path to file rrv.pdf instead of just a file name, like this
Anyway thanks for a hint helped me to get file attachments working
Comment #7
pontoffeltier CreditAttribution: pontoffeltier commentedIsn't the file_create_url and file_build_uri taking care of the path? I checked the output and the url links correctly to the file...
Comment #8
pasive CreditAttribution: pasive commentedYes - true they do.
I had to spend another hour to figure out how it finally works.
At the endI wrote a blog post on this - how works correctly http://passivemanagement.net/blog/2014/01/let-drupal-send-email-attachme... . If you follow my example code then it should be working.
My example works with mimemail-7.x-1.0-beta1.
Comment #9
sgabe CreditAttribution: sgabe commented@pasive the filecontent key is for dynamically generated files, while the filepath key is for existing files stored on the server. You should only use (the proper) one of the two.
As a comment on your blog post I would like to note that the hook_mail() implementation in the module considers file attachments as a multiline string because it handles messages sent via Rules actions provided by MimeMail itself. For more information see drupal_mail().
Comment #10
pasive CreditAttribution: pasive commentedThanks @sgabe, a very useful comment.
As I was really struggling to find the right way of getting this working. Now I get more clearer understanding of filecontent and filepath keys.
Comment #11
SpadXIII CreditAttribution: SpadXIII commentedI ran into this issue myself as well. I'm using encrypted_files module. Because mimemail changes the file-uri (with ef://.. stream wrapper) into a full file path, the files weren't decrypted anymore. I added a mail_alter in which I looped the attachments, decrypting them myself and unsetting the uri and filepath. This gave an error in the exact same locations as the above patch.
I just re-rolled it against latest dev.
Comment #12
SpadXIII CreditAttribution: SpadXIII commentedComment #14
g.oechsler CreditAttribution: g.oechsler commented11: mimemail-2057703-11.patch queued for re-testing.
Comment #16
SpadXIII CreditAttribution: SpadXIII commentedSeems like there's a whole lot going wrong in the tests unrelated to the patch!?
Comment #17
sgabe CreditAttribution: sgabe commentedYep, no idea why the tests are failing.
Comment #18
bhavikshah9 CreditAttribution: bhavikshah9 commentedI was facing exactly similar problem to what is mentioned in Issue, comment#2 as well as in comment#5.
I applied patch specified in comment#2 manually and everything worked fine for me. Problem is resolved now.
I checked the log to find out the reason why that patch has failed but i really didn't understood the exact reason of failure.
I am in mixed feeling right now, happy that problem is resolved but worried about that mysterious test-case in which patch has failed.
Comment #19
flocondetoileSame issue et patch #11 solved it.
Thanks
Comment #20
martichka5 CreditAttribution: martichka5 commentedHi,
I have experienced the same problem.
After some debugging i found out that mpdf library does not return string for file_content if we want it as string.
Doeas anybody know somethig about this?
Thanks in advance.
Comment #22
sgabe CreditAttribution: sgabe commentedI think a little refactoring here would be a nicer solution. The attached patch has been committed.