D6 port of Mailsave to CCK Imagefield

I did some hacking to get imagefield working with mailsave. This is not done yet; it's probably missing critical pieces like validation and needs cleanup/refactoring.

PHP imap sometimes fails to detect a filename for inline attached JPEG images, which is causing imagefield to not recognized the image file. I reported the issue over at #304720: Allow unnamed file attachments to be saved.

This version adds a couple lines of code to generate an appropriate filename if the filename is missing, though it only works with that other patch applied.

Just to be clear - #2 patch replaces #1 patch?

And #2 also needs patch from #304720: Allow unnamed file attachments to be saved?

R,
Coby

Yes, #2 is the same as #1 except it adds a call to mailsave_generate_filename() if the file is unnamed, to deal with inline-attached images. That function is provided by the patch over in #304720: Allow unnamed file attachments to be saved.

Got it thanks. Will give them a go and let you know how the tests work out so we can perhaps move this to CNR or RTBC?

@mfb sorry for the delay. might actually be to a point where i can test this in the next few days.

BTW, you should disregard the patch at #2 as the current version of the patch at #304720: Allow unnamed file attachments to be saved already takes care of this without any extra code needed here.

imagefield had a bit of a rewrite so here's an updated patch.

Thanks for this, but I'm getting a patch failure like this when trying to patch the clean 6x-1.3 version. Do I have to apply the other patches above or just this one?:

patching file mailsave_to_imagefield.info
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file mailsave_to_imagefield.info.rej
patching file mailsave_to_imagefield.module
Reversed (or previously applied) patch detected! Assume -R? [n]

Any advice appreciated. Thanks again for this update...I'd love to get this working!

You cannot apply patches to .info files from a package, because the .info file is modified by drupal.org's packaging scripts. You need to apply the patch to the CVS version of the module.

Ok cool. So The only patch I have to apply is that latest one you made correct? Sorry, just want to be sure I get it working. I have never used CVS so I guess I don't quite know what to do here...I've applied patches to downloaded modules which I guess is wrong! I better look into how to do this properly.

Wow this CVS stuff actually seems quite complex!? Is there any easier way to just get a working copy of the patched module? Sorry, but I'm a total newbie with CVS and patching.

Thanks again for your work on this!

watching

sub

I just applied the patch and it works wonderfully. Thanks a lot !

@mfb,
I have not forgotten about the great work you are doing here as well as my promise to test. I just got some funding to do a bit more email related work so it's moving back towards the top of the list.
Thanks,
Coby

Cool! Would you mind posting the working patched module? Some of us have patching problems ;) I tried to do it before but no luck.
Thanks alot!

still have not had time to test.

@superjames, i do not use CVS either and in theis case it was pretty easy to change the .info by hand to make it comply with D6. note you will not get any version info on this submodule since we are not using Drupal's packaging script to produce the attached zip.

hopefully this will hep get more testers.

Just opened an issue on this, see #478150: Mailsave_to_imagefield D6 port issue: it doesn't work if you're creating a hierarchy of directories to save your files into (at least with PHP 5)

@PGiro: Your fix looks reasonable to me. I haven't tested it yet myself but will try it soon.

Well, this isn't prime for production because I think we're still missing checks against people playing with "../../" type strings in the widget_path. It needs a little more thinking. What do you think ?

What do you think about this, which is more like how filefield itself does it?

I haven't yet tested trying to pass in "../../"

My bad, It looks like your latest patches are using the extension. I was still working off of the older patches you have further up the thread :-(

You can probably disregard the rest of this post.

I tried this out, and initially it wasn't working for me. I am using the imageFUpload widget to upload multiple images at a time through the admin screens, and that was causing problems with the check for the imagefield widget type. I'm not sure if there is a definitive way to determine if a CCK field is for an image, but I got it working on my site by making this change:

68c68
< if (($field_info['widget']['type'] == 'imagefield') || ($field_info['widget']['type'] == 'image_fupload_imagefield_widget')) {
---
> if ($field_info['widget']['type'] == 'imagefield_widget') {

Possibly a better check would be to look for $field_info['widget']['file_extensions'] matching the uploaded file's extension, but then that wouldn't be constrained to just images?

Thanks for your work!

Hi all,

I used the patch in #21 - but found problems:

this line was causing an undefined function error:
- $file = _imagefield_scale_image($file, $field_info['widget']['max_resolution']);
it seems the current version of imagefield does not use that function anymore.

and then after fixing that by adding a check for the function before running it, I encountered another error:
- cannot argument 1 by reference at the part where mailsave invokes hook file_insert

I traced the problem to the filefield_meta module and revised the code as follows:

The following is my setup:
Drupal 6.13
Filefield Meta 6.x-3.1
Imagefield 6.x-3.1
Mailhandler 6.x-1.8
Mailsave 6.x-1.3

However, aside from that, the patch worked.

Thanks :)

Hello All,

This is my first post in Drupal. First of all thanks a lot for coming up with this great module.

Secondly, I applied patch # 2 given at post #19 and tested it thoroughly. Everything seems to be working fine. It is able to save all inline image attachments perfectly.

However, during another round of testing I found that, if an email has format like given below,

The final output looks like this

When I looked closely, I found that the module perfectly attaches the inline images to the page, but it still retains the original img tags in the node body which still refers to the original inline image which doesn't exists.

In order to remove the original img tag, I applied one dirty fix to mailhandler.retrieve.inc file. The fix is as follow.

I placed this code inside mailhandler_process_message function.
This is temporary fix which just looks for inline img tags and remove it, since all the images are attached to the main page.

However, this is not a permanent solution. The format of the message should be look like this,

I'm not sure whether this issue is related to mailhandler or mailsave module.

Thanks.
Rahim.

sub

sub! :D