It is import that files are stored in the private file system on my site for legal reasons.

On some occasions I need to send emails with an image but linking does not work with a private mail system. I have removed the check from "Link Images Only" but images are still sent as links.

I am not using a template, I have simply added theme_image_style() to the body wrapped inside a l() to make the image clickable.

Do I also have to add the images as attachments manually or am I missing something?

Thanks
Simon

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

sgabe’s picture

Did you try the "Send arbitrary files" permission?

justdave’s picture

I'm having the same issue, I can't get my images to embed, and I'm using a private filesystem. Which is precisely WHY the images need to be embedded, because you can't link to them. I do have "Send arbitrary files" permission enabled for all roles except the anonymous user... does anonymous need permission for the mail to send?

sgabe’s picture

If you are using the Simplenews module, which is switching to the anonymous user for sending messages, then you need to grant the "Send arbitrary files" permission for anonymous users.

justdave’s picture

I'm using the Subscription module to send node updates actually. I thought it was using the permissions of the person who made the change to the node, but maybe it's using anonymous, too. I'll try it anyhow and see what happens.

justdave’s picture

That didn't help, even with anonymous granted to send arbitrary files, I still get a link to the image in the email.

justdave’s picture

For completeness, I do have "Link Images Only" unchecked.

I'm also using Pathologic to change the links to relative because another post I found via Google suggested that for this situation. I'm going to try disabling that now and see what happens on the next mail that goes out.

justdave’s picture

OK, did that, still no luck :|

sgabe’s picture

Please post here a sample URL of an image you are trying to send as it appears in the message source.

justdave’s picture

OK, looking at what went out, I think Pathologic wasn't out of the way yet (it was probably already in the queue). I'll have to try again on the next one. But anyway...

In the "edit source" mode in the node editor, the image link looks like this:

<img alt="" src="/system/files/gerber_sign_small_0.jpg" style="width: 180px; height: 120px; float: left; margin-right: 1em;">

I the source of the email that went out, it looks like this:

<img alt=3D"" src=3D"system/files/gerber_sign_small_0.j=
pg" style=3D"width:180px;height:120px;float:left;margin-right:1em;border:=
none;" align=3D"left" vspace=3D"5" hspace=3D"5">

The lack of the / in front indicates Pathologic's "make it a relative path" thing actually happened.

sgabe’s picture

Please use the <code> tag so it will not be filtered out.

justdave’s picture

nice. ok, I edited the comment so you can see it :)

sgabe’s picture

Is the site running on Drupal 6 or was it updated to Drupal 7?

justdave’s picture

D7.

sgabe’s picture

You should use the private file wrapper in the URL like private://gerber_sign_small_0.jpg, or use the full URI like /home/username/system/files/gerber_sign_small_0.jpg.

justdave’s picture

Is there some module or wrapper I need to have installed for that to work? I just get an empty image placeholder in the preview on the web page if I do that.

quicksketch’s picture

Category: Support request » Bug report

I ran across this today as well. I'm pretty sure that this is a bug when dealing with private files. The _mimemail_file() function includes this bit of code:

    $public_path = file_default_scheme() . '://';
    $no_access = !user_access('send arbitrary files');
    $not_in_public_path = strpos(drupal_realpath($file), drupal_realpath($public_path)) !== 0;
    if (@is_file($file) && $not_in_public_path && $no_access) {
      return $url;
    }

This basically says, "if the file is not in the public files directory, don't allow it to be embedded". Since the private files directory isn't in the public directory (usually), this will prevent private files from being embedded (unless the "send arbitrary files" permission is granted). Oddly if you set the default file system to private, that would also allow access (but that causes a lot of other problems).

justdave’s picture

I have "send arbitrary files" enabled on my system and it still doesn't work.

ecvandenberg’s picture

Same here in the case of sending attachments with webform.

Access right "send arbitrary files" enabled for all users.
Option "Send attachments" in Webform enabled.

Mime Mail 7.x-1.0-beta3
Webform 7.x-3.20

agoradesign’s picture

I've had the same problem after updatint Mime Mail to 1.0-beta3. Webform is at 4.0. I've enabled the "send arbitrary files" permission for everyone and - as I also use Simplenews - the "link images only" variable is also enabled.

The root of the problem is, that as soon as you have "link images only" enabled, the file gets never attached, if it is an image (having png, gif, jpg or jpeg as filename suffix). I've added another check, if the disposition is set to "attachment" - if yes, the image gets never linked only. Have a look at the attached patch and try it!

I've tested webform submissions, that now correctly send the emails WITH attachments, and I've also tested Simplenews, which still links the images only, like it should.

best regards,
Andy

agoradesign’s picture

Updated patch file: is functionally still the same, but I think this is the proper format / way to create a patch file

agoradesign’s picture

Status: Active » Needs review
justdave’s picture

The root of the problem is, that as soon as you have "link images only" enabled, the file gets never attached

Isn't that the point of "link images only"? Having that checked means it's supposed to put a link to the image in the email instead of embedding the image. The default action if that box is NOT checked should be to attach and embed the image.

agoradesign’s picture

I disagree. There's a small difference, if you embed an image inline, or just attach it to the e-mail, like you would do with any other files (PDF,...). If I enable the "link images only" setting, I expect, that all images, that are embedded inside my mail body, are linked rather than sent along with the e-mail, BUT if I explicitely send files as attachment, I want them to be really attached, no matter, if the files are images, PDFs, or any other kind.

And less technically spoken: if you have customer, that both uses Simplenews to send newsletters, and Webform with file upload fields, it is really very important to have the possibility to send the uploaded files from the form to e.g. the customer's secretary, while still having the possibility to only link the images in the newsletter (which is also very important!). Before you say now, that the links in the webform confirmation e-mail must be enough: no, they aren't! First of all, it's inconvient. The secretary may has to login first, before he/she can continue and download the files. And it's also possible - like it is with our customer, for whom I made this patch - that the secretary/responsible employee does not have editor permissions on the website. Of course, you could still configure a special user role, that effectively only is allowed to download private files. But that would be really very inconvient, having to login to the website just for the downloads...

justdave’s picture

OK, it sounds like you're trying to solve a different problem (the attachments not getting included in the email).
This ticket is about images not being embedded in the emails at all when they are supposed to be (which is still the case for me, with or without your patch).

steniya’s picture

Is there any solution for this same issue in drupal 8?

johnnieg’s picture

I do not have time to create a patch but in case this helps someone, I got images from the private filesystem embedded in a mimemail email by making the following changes:
in function _mimemail_file

Replaced this line
$local_path = preg_replace('!^' . base_path() . '!', '', $local_path, 1);
with
$local_path = preg_replace('!^' . $GLOBALS['base_url'] . '!', '', $local_path, 1);
because base_path() returns just '/' instead of the real base path.

Also, added
$local_path = str_replace('/system/files',variable_get('file_private_path'),$local_path);
after
$local_path = preg_replace('/\\?itok=.*$/', '', $local_path);

This is in addition to the patch above and removing the check for $in_public_path from comment #16.

TR’s picture

Status: Needs review » Active

In regards to comments #19, #20, #21, #22, and #23:

That is indeed a separate issue, which was raised in #2502047: Anomaly attaching image files and has a patch similar to that in #20. If you are interested in seeing that issue fixed, please participate in that other thread.

Setting this back to "Active" because there is no patch here that is intended to fix the original issue.