interfacelab

The latest version allows you to specify cache control and expires headers.

The next major update (1.3) features expanded filters at almost every point in the process.

Imgix is a CDN that happens to do image manipulation. So, you don’t need the CloudFront part because Imgix is doing what CloudFront does.

The way it works is that when you request an image from Imgix, it’ll load the original from your S3 bucket, do any manipulations such as resizing or cropping or whatever, and then cache that manipulated image on its CDN.

This media tools plugin was built for a very high traffic media heavy news website and we’ve had zero issues with Imgix as the CDN.

I got it.

The latest version allows you to define a “prefix” to be applied to files uploaded to S3. From the documentation:

This will prepend a prefix to any file uploaded to S3. For dynamically created prefixes, you can use the following variables: @{date:format}, @{site-name}, @{site-host}, @{user-name}, @{unique-id}, @{unique-path}. For the date token, format is any format string that you can use with php’s date() function. Note that specifying a prefix here will remove WordPress’s default date prefix. WordPress’s default prefix would look like: @{date:Y/m}

As for compatibility coming from Offload S3 to Media Tools, that I’m not certain and will have to do some testing to confirm.

I haven’t used WP S3 Offload for some time, so if you could give me more details on what that feature is, I can check it out. Is it in the free version?

Thanks!

Why do you have a cloud front distribution if you are using Imgix?

This is in version 1.1.0.

Here’s from the docs:

This will prepend a prefix to any file uploaded to S3. For dynamically created prefixes, you can use the following variables: @{date:format}, @{site-name}, @{site-host}, @{user-name}, @{unique-id}, @{unique-path}. For the date token, format is any format string that you can use with php’s date() function. Note that specifying a prefix here will remove WordPress’s default date prefix. WordPress’s default prefix would look like: @{date:Y/m}

No. Your media will be transferred to S3 and hosted there. Your URLs will change to point to S3 instead of your current WordPress site.

You also shouldn’t do this on a live site. If you do, make sure you backup your database first.

It’s not dead. I don’t update it on here very frequently because all of my WP development is done using composer these days and not installing plugins manually.

You can track the project at https://github.com/interfacelab/ilab-media-tools/

If there was an error communicating with S3, there’d definitely be error messages in the log.

What other plugins are you using? Which version of Media Tools?

That’s 100% an nginx log entry. ??

No need for a connection back.

That log is from nginx, we need the one from PHP. Check your php.ini and add these lines:

log_errors = On
error_log = /var/log/php-errors.log

Make sure /var/log/php-errors.log exists and your web process has write access to it.

sudo touch /var/log/php-errors.log
sudo chown www-data:www-data /var/log/php-errors.log

You may need to restart nginx and/or php-fpm.

I haven’t tested this with Multisite, btw, but if we can’t produce something useful from the log I will test it later tonight.

It’s certainly not an nginx issue. Do you have php error logging enabled? Can you paste in some logs when performing the upload?

The new 1.0.5 version should coexist peacefully with any other plugin using the AWS SDK.

We are using the newest one, which other plugins haven’t either update to or they are using the 2.8x version for compatibility with PHP 5.4 and lower. We re-namespaced the AWS SDK to prevent any collisions.

Let me know if you run into any problems!

My guess is that you are using PHP 5.4x or lower. I’ve updated the readme to indicate that you need PHP 5.5 or better.

https://stackoverflow.com/questions/30580770/installing-aws-php-sdk-unexpected-variables

Sorry for your troubles!

What PHP version are you using?