interfacelab

When using Imgix, you can only use the image cropping tool that comes with the our plugin.

This should be fixed in 2.1.6.

The best way to do an import, though, is from the command line via WP CLI:

wp mediacloud import

You can debug output:

wp mediacloud import --debug=mediacloud

Fixed in 2.1.6

Fixed in 2.1.6

The actual fix is only hijacking the upload directory naming stuff when a file is being uploaded.

WooCommerce, for some reason, calls upload_dir() before the user stuff is loaded.

Yes, there is a regenerate thumbnail function.

However, this is why I urge people to use Imgix. You’d avoid all of this by using them.

Support for Backblaze is going away in 3.0.

People have asked for an “import from s3” feature but it’s not really possible unless you are using Imgix.

The problem is generating thumbnails for your library. If you are using Imgix with S3, then no problem because Imgix is going to generate those thumbnails when they are requested. But, if not, you’d have to copy down the files from S3 to your local server, generate the thumbnails and upload the whole thing again.

Fixed in the 2.1.6

It should work out of the box.

Media Cloud inserts itself in the upload chain at a level of 10000. These plugins will have to insert themselves < 10000.

However, if they aren’t overwriting the original uploaded file then Media Cloud probably won’t see the optimized versions.

I’ll be honest, it’s not likely I’ll change much here to accommodate these plugins. I use Imgix, I tell others to use Imgix, all of my clients use Imgix. Imgix takes care of all this stuff for you plus future proofs all of your assets without having to jump through hoops to get it in line with any front end changes you’ve made. It’s $10 a month and you can slap Cloudfront in front of it to avoid CDN charges.

That said, it is open source and I’m open to pull requests ??

Nope, did a bunch of testing today and no issues. Are you using the WordPress crop tool or the Media Cloud crop tool?

This is the minimum IAM policy you need to have:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:DeleteObjectTagging",
                "s3:ListBucketMultipartUploads",
                "s3:DeleteObjectVersion",
                "s3:ListBucket",
                "s3:DeleteObjectVersionTagging",
                "s3:GetBucketAcl",
                "s3:ListMultipartUploadParts",
                "s3:PutObject",
                "s3:GetObjectAcl",
                "s3:GetObject",
                "s3:AbortMultipartUpload",
                "s3:DeleteObject",
                "s3:GetBucketLocation",
                "s3:PutObjectAcl"
            ],
            "Resource": [
                "arn:aws:s3:::YOURBUCKET/*",
                "arn:aws:s3:::YOURBUCKET"
            ]
        },
        {
            "Effect": "Allow",
            "Action": "s3:HeadBucket",
            "Resource": "*"
        }
    ]
}

Is your AmazonS3FullAccess tied to a specific bucket or resource?

This is what I would do:

– Create a new bucket (use default settings)
– Create a new IAM user
– Attach the above policy to the new user (replace YOURBUCKET in the policy with the name of the bucket you want to use).
– Plug the new info into the media cloud plugin and see if you still get the error.

If you still get the error, try the WP Offload S3 plugin and see if you still have problems. If you do, then there is something else going on. If not, there is an issue with Media Cloud, but I doubt it.

Stop using {unique-id} ??

I’ll look into adding empty folder deletion soon.

What compatibility issue is there with Revolution Slider? I know some of these slider plugins do their own upload stuff, side stepping WordPress’s upload, or they try to get fancy and directly grab URLs from the DB which they shouldn’t do.

I took it down, it was costing money and nobody was using it.

Do you have imgix examples you can share?