Any idea why the width and height of an uploaded image are not being returned on Heroku servers?

[robksawyer]

I'm currently using the S3 transport with your plugin and everything works fine locally. But, when I try to upload on my testing Heroku server, the width and height are not being found on the image and therefore this messes up the transport. Note: I had to add the imagemagick extension manually in order to get it to work on Heroku.

May be an issue: The vendors folder within app/Plugin/Uploader is not getting uploaded to Heroku. However, the uploader files are in app/Vendor/ and in core.php I've added require_once dirname(__DIR__) . '/Vendor/autoload.php';.

[milesj]

So do the Uploader files actually exist in the Plugin folder? A bit confused by that. And I'm assuming the same for Transit in Vendor?

[robksawyer]

The uploader files exist in plugins and I've even made sure that the vendors exist. It seems like there may be a problem with the tmp folder not being writable. I can't seem to get my logs to write either. :(

I'm basically getting the blank screen of death when adding an entry that includes an attachment with no logs to check. Fun.

On Aug 19, 2013, at 4:42 PM, Miles Johnson notifications@github.com wrote:

So do the Uploader files actually exist in the Plugin folder? A bit confused by that. And I'm assuming the same for Transit in Vendor?

— Reply to this email directly or view it on GitHub.

[milesj]

That reminds me of something when I tried Heroku. Heroku is a read-only system: https://devcenter.heroku.com/articles/read-only-filesystem

You would have to change the tmp folder for the Uploader and Cake to point to Heroku's /tmp.

[robksawyer]

Yeah, I thought I had all of that sorted. The temporary file should be writing to tmp, right? Ah, I bet it's only allowing a tmp folder outside of app folder to be writable. ./tmp not app/tmp Maybe?

On Aug 19, 2013, at 6:29 PM, Miles Johnson notifications@github.com wrote:

That reminds me of something when I tried Heroku. Heroku is a read-only system: https://devcenter.heroku.com/articles/read-only-filesystem

You would have to change the tmp folder for the Uploader and Cake to point to Heroku's /tmp.

— Reply to this email directly or view it on GitHub.

[milesj]

It's Heroku's tmp folder, which is at the root of the linux box. So /tmp instead of ./tmp (which is current dir).

[robksawyer]

So I've managed to stop the file doesn't exist errors by updating www/lib/Cake/bootstrap.php TMP constant, so it seems that the file is writing temporarily. But for some reason, it's not transporting. The files are trying to upload to files/uploads and this clearly won't work on Heroku. Note: This is working locally. Any ideas? Any tips on where I should start debugging?

[robksawyer]

To confirm: The transforms happen after the file is uploaded to the 'uploadDir', correct? And then transports happen, right?

[robksawyer]

So it seems when I set uploadDir to TMP it tries to upload to http://www.mywebsite.com/tmp/myfile.png instead of the actual root tmp folder on the dyno. Any ideas?

[milesj]

Set finalPath to an empty string and try setting uploadDir to /tmp instead of TMP.

[robksawyer]

The final path for the image ends up being /img/theimage.jpg now. It seems as if the S3 transport is failing or something. No exceptions or errors are being thrown that I can see, though. The file isn't uploading to S3.

[milesj]

Does the file upload in general without using S3?

Also is it saved in the DB as /img/theimage.jpg or theimage.jpg?

[robksawyer]

Nope, because img/ isn't writable. However, I'm not getting the File Not Found errors that I was getting when the tmp directory was not configured properly. So it seems as if the file is actually uploading to tmp. I also debugged statements in beforeTransport and those are firing.

[milesj]

Nothing in the Uploader is hardcoded to /img/, that's why I'm asking what's actually saved in the DB. I have no idea where that img is coming from.

[robksawyer]

I'm thinking that it's coming from /libs/Cake/bootstrap.php (see snippet below). When I add 'finalPath' => '/', I get an image path of /myimage.jpg which makes sense, however, I think that it's using relative path in the Uploader somewhere instead of an absolute server path. So, if I put 'finalPath' => '/tmp' it ends up trying to add file to /app/www/tmp instead of /tmp.

/**
 * Web path to the public images directory.
 */
if (!defined('IMAGES_URL')) {
    define('IMAGES_URL', 'img/');
}

[robksawyer]

I finally managed to get some feedback to log inside of Heroku using ConsoleLog and a little hackery and this is what I saw.

2013-08-21 00:19:16 Debug: Reading exif data requires the exif module

For the record: Here's my attachment model. https://gist.github.com/robksawyer/6291290

[milesj]

The Uploader doesn't append /app/www either so I'm not sure where you are getting that. Are you calling HtmlHelper::image()? The path is literally uploadDir + finalPath + filename.

Try enabling the exif module? It comes packaged in PHP.

[robksawyer]

It appears that exif isn't enabled in the default Cedar install. So, I need to make a custom build pack – which is a real pain in the arse. Computer software... I swear.

[milesj]

I'll have to update Transit to remove that exception. You can try commenting it out and see if the process finishes. I'm curious of the exception stops the upload process.

[robksawyer]

I've managed to find a build pack that I think will work for me (https://github.com/taeram/heroku-buildpack-php-columbo). But in the meantime, while I'm precompiling binaries, I'll try commenting out the exception to see if it uploads.

[robksawyer]

So I commented out throw new RuntimeException('Reading exif data requires the exif module'); on line 171 of src/Transit/File.php and the upload worked. Awesome! BTW: Thanks for your patience and the help.

[milesj]

Ok cool. I'll just remove that exception from Transit since it really shouldn't break the upload process.