src="Array" if path to image is broken
mariuss - October 9, 2008 - 20:46
| Project: | Mime Mail |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Description
Instead of attaching images the generated HTML will have image tags that look like:
<img src="Array" ... />
#1
I'm noticing that it is properly adding any image that I have inline, but actually not changing the
#2
Turns out that I had the wrong path for images, everything is fine as soon as the right path was used.
I still think we have an issue here. Under no circumstances should "Array" be output here.
Ideally, if the image file cannot be loaded, then an error should be logged to watchdog.
#3
This problem is also there when using private setting for local files. This problem was there also in #43966: Not including 'private' images in the mail
The code for the image in the node is in my case:
<img width="120" height="120" align="left" src="/nl/system/files/image/Nieuws/images.jpg" alt="" />And that is replaced in the mail by:
<img width="120" height="120" align="left" src="Array" alt="" style="border:0;">I use FCKEditor to create the newsletter. This creates a relative path. When I manualy change the image URL to the full path it sends the right code.
#4
Hereby a patch for the mimemail.inc to change the file/url/path when the image source is a local file and private download is set (Relative path)
#5
(regarding the combination of mime mail and simplenews)
What actually should happen is:
- Online: use the correct on-site image path where the newsletter is displayed online.
- Email: use the attachment filename when the newsletter is sent as an email, if the image is included as an attachment.
- Email: use the correct absolute image url, if the image is not included as an attachment.
The author could include the image with an absolute or relative path, or using the "pathfilter" module, as if the email was a normal on-site text.
Mime Mail or Simplenews or an additional filter module could then do the rest: Look if the image is included as an attachment, and replace the path with the filename.
I hope this will work soon, it's a serious blocker for using drupal as a newsletter engine.
Thx, Donquixote
#6
See also the Simplenews issue Footer and Attatchment links do not work. (the typo is not mine!!)
#7
Can anyone review the patch in #4 and add it to the dev release?
#8
(This reply would also fit in the linked simplenews discussion, but the solution lies in mimemail, so I post it here)
I think I had some misconceptions about how mimemail works. Now I think I understand better.
- any absolute image url will remain as-is.
- any relative image url will be added as an attachment, using a
src="cid:md5encodedcontentid@mydomain.net".Problems:
- With clean URLs enabled, relative URLs do not work unless I have a baseuri defined in my header (which has other side effects that sometimes I don't want).
- If you have the pathfilter module installed, you will usually get absolute URLs anyway.
This means, people with clean URLs who don't have a baseuri defined have to choose between the following two evils:
a) When using absolute path: Image will not be included as an attachment, so the reader has to click "show images" in the mail client.
b) When using relative path: Images will not work in the online version of the newsletter issue.
The equation "relative path = add as attachment" is too simple. We need a better way to tell Drupal when to add an image as an attachment, and when to use a web URL.
We could allow people to specify an indicator in the URL (such as
<img src="attachment:path/to/image.jpg" />). The problem is that the input filters are usually the same for the online version and the mailed version. So whatever we use as an indicator will be visible in the source of the online version.One indicator that would not break the online version would be
src="http://absolute/path/to/image.jpg?attachment", but it still would appear in the online version and look just wrong.A solution without direct indicators:
- If the image is found in the mail's attachments, then refer to this attachment via explicit filename. (not via content id, because these attachments are usually added with filename - or not?).
- If the image is not an attachment, then use an absolute web path.
- This should work both for absolute and relative image paths given in the original body text.
This is still not 100% flexible, but in practice it gives complete choice.
#9
What we would need is an input filter that is applied only in the online version, not in the mail version. Does anyone know how this can be achieved? It would be very helpful for solving this issue.
#10
A problem with the
_mimemail_file()is that one time it returns an array, and another time a string. This is why we get thissrc="Array"bug.In those cases where the module outputs "Array", it assumes the given URL will not work anyway.
The following code will prevent this bug, and instead output the original relative URL. In some cases this is what we want. (sorry I have not yet studied how to write in the usual patch format)
<?php
function _mimemail_file($url = NULL, $name = '', $type = '', $disposition = 'related') {
static $files = array();
if ($url) {
$url = _mimemail_url($url, 'TRUE');
// If the $url is absolute, we're done here.
if (strpos($url, '://') || preg_match('!mailto:!', $url)) {
return $url;
}
else {
// The $url is a relative file path, continue processing.
$file = $url;
}
}
if ($file) {
if (!file_exists($file)) {
return $url; // this part has changed
} else {
$content_id = md5($file) .'@'. $_SERVER['HTTP_HOST'];
if (!$name) $name = substr($file, strrpos($file, '/') + 1);
$new_file = array(
'name' => $name,
'file' => $file,
'Content-ID' => $content_id,
'Content-Disposition' => $disposition,
);
$new_file['Content-Type'] = _mimemail_mimetype($file, $type);
$files[] = $new_file;
return 'cid:'. $content_id;
}
}
?>
This patch allows a workaround for yet another issue, that I will explain in the following post.
#11
Another very related issue (or question):
Right now it is not possible to embed a an attachment that was manually added as such as an image.
If you write
<img src="somepic.jpg"/>, where somepic.jpg is the name of one of the attachments, then mimemail will rip the filename apart and replace it with<img src="Array"/>, because it is neither a valid absolute path nor a valid on-site relative path.True, the url
somepic.jpgwill not work in the online version, but (as I understand) it would be the correct url when refering to an attached file. Right?The patch in my previous post will preserve this filename url in the mail version. (it will break the online version, that's the price)
In Outlook this will make the image appear correctly, but in my webmail interface (gmx) it does not work. Where is my misconception here? The md5-encoded image path DID work in gmx webmail, but then it does not appear in the list of attached files, correct? Or otherwise, it will be attached twice: One time as a normal attachment with the human-readable filename, and another time with the md5 encoded content id.
I hope one of you guys can shed some light in these questions.. a better technical understanding will make it easier to find useful solutions.
Sorry for my half-knowledge of html email.
Cheers,
Donquixote
#12
I'm having similar problems, except im using 6.x-1.0-alpha1
I tried using cid and relative url, but I am returned with src="array"
So now I am trying it with absolute url. My code is:
When I see it in my mail client (thunderbird) or online (gmail), I see the image box defined by the width and height attributes, as well as the correct alt text. The src text always displays outside. Attached image is what I see.
I have made sure my paths are correct, and my permissions are set to all read. The rest of the message (text effects) all display correctly.