I see that the extension has to be forced since the uploaded file in php temp doesn't have any extension and I can see this working fine several times during the execution of the first few commands, but it fails when calling the ->save('image') command as it internally calls the check_extension command without the force_extension which then in turn returns a "The library does not support this filetype for /tmp/php9NQl3p." error.
Before I had this problem I got a Call to protected method Fuel\Core\Image_Driver::_crop_resize() from context '' which you solved in another post by updating the image class to the 1.8. I copied the driver.php and gd.php from the 1.8/dev path but I'm not totally sure that this was enough. All other related files looked pretty old. The rest of the framework was a fresh 1.7 installation.
If I look at check_extension(), it first checks a forced extension. Which isn't there, as you correctly observed. Then it loops over the valid extensions array, and checks if the file has such an extension. If so, it will update $this->image_extension, and return the extension. This should not be the case with your temp file, so it returns false.
Then in parent;:save(), if check_extension() returns false, it will attach $this->image_extension (which contains your forced extension) to the filename, checks if it's writable, and return it. The save() method then adds it to the $vars method, to pass it on.
So this all seems ok.
Can you check in the gd driver, line 347, what $this->image_extension and $vars contain?
I checked the driver and what I got back looked alright to me:
string(3) "jpg"
array(3) { [0]=> &resource(112) of type (gd) [1]=> string(9) "image.jpg" [2]=> int(100) }
what struck me right now was that the wrong load() call is made after the line you asked for, when fuel reloads the image for some weird reason.
I found out that if I set persistance = true in the image config the faulty call isn't made anymore and the whole process runs through fine. So it looks like this fixes my problem :)
Thanks for your time and also thanks to the whole team for creating such an awesome framework - even if some parts are unfinished, I still find it a very good base to build applications on.
Image was a class contributed, but the developer hasn't been around for a long time, and nobody really knows how it works, as the code is a bit of a mess.
It will not be part of Fuel v2, it will have a different (and much better) image manipulation library.