tcS3

Description

This all-inclusive plugin uses the AWS SDK for PHP to facilitate uploads directly from your WordPress instance to S3. Amazon’s inexpensive, unlimited cloud storage system is an excellent asset backend for all websites and this plugin allows you to seamlessly interact with your S3 bucket right from within your dashboard. Best of all, this plugin requires nothing special from you — it has been tested for performance on shared hosting, VPS and dedicated servers and worked on each, out of the box, both on Apache and nginX. tcS3 has been tested on wordpress 3.7 – 4.9 and worked well on all versions.

This plugin is being released in beta — the wide popularity of S3 makes it difficult for me, the only developer on this project, to know every possible use case for it, so I’m relying on feedback from its use to provide further enhancements.

Important

Requires PHP >= 5.5.0 because of the AWS SDK.

Current capabilities

  • Use EC2 instance profile, environment variables or IAM keys to connect to S3
  • Upload directly to S3 (with the option to delete from your local instance immediately after a successful upload)
  • Delete media from S3 when it’s deleted from your library
  • Update URLs to point directly at your S3 bucket using the link you specify (adding flexibility to point to CDN services like CloudFlare or Cloudfront or pointing directly to your bucket)

Advanced features

  • The plugin’s use of the AWS SDK for PHP allows for a more flexible configuration. Out of the box the plugin is set up to do two things, and if you never change them you’ll probably be fine.
  • Set cache headers on your image so repeat visitors load the image faster and don’t cost you a GET against S3
  • Performs multithreaded uploads on files larger than 5MB — larger files can take longer for your webserver to send to S3… those can really slow down your site! So, the plugin will split your files up into chunks no smaller than 5MB and send them to S3 that way, seamlessly, without your having to ask.
  • Plugin kept light and fast by breaking plugin and dependencies up into classes and autoloading them via Composer

Install

This plugin is installed just like any other. Simply upload the zip file you can download from github and upload it using the WordPress dashboard or FTP. This plugin has been submitted to the WordPress team for review as well and will hopefully be available in the WordPress plugin repository soon.

Unsolicited advice

While S3 is relatively inexpensive (very inexpensive the more you use it), it’s not free and it’s not just how much you upload to it, but how much traffic you’re getting. If your bucket is receiving a lot of GET requests (which happens when you have a lot of traffic on your site) it could get expensive (take a look at Amazon’s S3 pricing guide). The cache headers being assigned by this plugin will certainly help, but if you sign up for a free Cloudflare account and set up your S3 bucket as a subdomain that Cloudflare is caching, responses to initial requests will come from S3, but many subsequent requests will hit Cloudflare and cost you nothing (and images will load faster because Cloudflare is a CDN).

Installation

This plugin is installed just like any other. Simply upload the zip file you can download from GitHub and upload it using the WordPress dashboard or FTP. You can also install it right from the WordPress Plugin Repository!

FAQ

Installation Instructions

This plugin is installed just like any other. Simply upload the zip file you can download from GitHub and upload it using the WordPress dashboard or FTP. You can also install it right from the WordPress Plugin Repository!

Reviews

Configuration is pretty poor

The configuration section is very difficult to use and doesn’t seem to be addressed from a user perspective. Also how about allowing the rewriting of the URL to a CDN URL?

Config is a comedy of errors, and doesn’t actually work

UPDATE: I’ve just tried another go at this one and found all the same fun as my original review. In addition, I actually had to edit the code to get file upload to work. Not sure how anyone could release code that doesn’t actually work without having tested it thoroughly themselves.

You’ll want to edit lines 39 and 47 of inc/wp_ajax.class.php to actually get this to upload. I’m not holding my breath, but I’m guessing the delete-after-upload still doesn’t work.

39 $path = $tcS3->wp_media_->get_path_from_file($file);
40
41 $success = $upload;
42
43 if (isset($file_data[“sizes”])) {
44 foreach ($file_data[“sizes”] as $size => $details) {
45 $file = $path . “/” . $details[“file”];
46 $key = $tcS3->aws_ops_->build_attachment_key($file);
47 $upload = $tcS3->aws_ops_->s3_upload( $tcS3->wp_options_->options[“local_path”] . ‘/’ .$file, $key);

I’m downgrading to a one-star.

I’m going to move on to S3-Uploads

Here’s my original review:
———————————————————
I would love to rate this higher, but just can’t bring myself to do it without seeing some improvement.

** Configuration **

1. It’s obvious that the user will need to create or get AWS key and secret (whether environment or standard). Providing a link directly to the AWS user creation page within the console right on that page would be awfully handy.

2. The labels on the Authentication tab should match exactly the labels on the AWS user page. They don’t match. It’s still clear which fields from AWS to copy into which field in the plugin config, but a 100% field match shows a focus on the user instead of “a plugin I hacked for myself and since I wrote it I know what everything means, you may have to figure it out” approach – which seems common through the rest of the errors I’ll cite.

3. S3 configuration tab -> S3 URL. Two issues here. First, you have to know to put the trailing / (slash), if you don’t, the code won’t correct this for you, and the only way to figure out why your images aren’t loading is to look at their URL and start tinkering with the settings until you happily realize this setting was the one causing the code to build an invalid URL. Second, even though in the field above, S3 Bucket Path, you just entered the “path inside the bucket” – you have to make sure you also put it here on the end of the url, again ending with a slash. Since the code uploads to “S3 Bucket” + “S3 Bucket Path”, the code could also check when you save the config and add the “S3 Bucket Path” to the end of the “S3 Bucket URL” if it doesn’t end in it. It won’t work without it.

4. Advanced Tab. Both “Local Path” and “URL” should be fetchable from wp calls. If they are, either (a) these calls are broken (less likely) or (b) this plugin doesn’t use them. I installed this on a multisite/network, and I have no problems with any images not loading or image plugins not figuring out where the images are on disk or their URLs. I’m guessing that’s because the wp calls correctly return the (real) path and urls. In order for me to fill these values in I had to determine the site ID and piece the upload path together myself.

For all of the above, I would give the plugin a 4. I get it, sometimes that initial config can be a little painful, but once that’s done and the plugin works, you’re good to go.

But wait, there’s more.

** (Not) Functioning as advertised **

5. File delete. I had this enabled from before I entered the S3 credentials (and double-checked that it’s still enabled at this writing). My site had no images in the media library until after I had the plugin config completed. I stumbled my way through the config issues above with one image until I got everything working. I confirmed it was uploaded into s3, but noticed the file didn’t get deleted on the local disk. I thought maybe it was because the config wasn’t “just right” when I first uploaded the file, so I tried again since the config was now working correctly. I confirmed the image displayed on my site correctly, being pulled from s3, and saw all the 100×100 type files that are generated by wp on upload were all populated in s3 – so the upload was working.
However, the files still exist on the local disk – they aren’t being deleted.

Having something not work that’s advertised as working (this last item) lost another star, thus the 3.

TL;DR

Config could use some UX thinking. Delete functionality may not be working as advertised.

I appreciate the effort on this tool and after 2 years and 2 release versions later, it still feels like it’s in beta – so much so that the dev didn’t even care to update the plugin description, leaving the “it’s in beta” still there.

If all the above were working, I’d still probably rate this as a 4, because I think two critical things are missing:

1. The ability to “pause” the auto-upload or have s3 upload “off” by default, and use the “sync” button to push files up. Reasoning – There are a number of gallery tools (like envira) that do things post-upload, like watermarking, allowing you to crop/resize, etc. It’d be handy to not have this auto-upload, which would give space for the user to upload files, do those edit operations, and then push the finals on up to s3.

Right now, the only way I can think of accomplishing this is to disable the plugin, then re-enable it when I’m ready for an upload and then do “sync” and hope it’s not to overwhelming for the server to catch up on all those files at once.

2. Selective upload. This builds off of the last idea. Again, having “upload” off by default, and providing a list of all the files that haven’t been pushed to s3, allowing them to be selected and pushed up to s3 on a file-by-file basis.

I’m a photographer and can come back from a trip/shoot/whatever with a couple hundred files. It’d be nice to upload them all to wp, and then as I work through the gallery-tool edits, select handfulls of the files that I’m done editing and have them uploaded to s3, but leaving the rest on the local disk until after I’m done with their edits.

Read all 6 reviews

Contributors & Developers

“tcS3” is open source software. The following people have contributed to this plugin.

Contributors

Translate “tcS3” into your language.

Interested in development?

Browse the code, check out the SVN repository, or subscribe to the development log by RSS.

Changelog

2.1.1

  • Fixes bug where browserify breaks JS

2.1.0

  • Improves language on the configuration page
  • Adds some validation to the configuration page
  • Fixes bug that prevents images from being deleted after push to S3
  • Moves JS to ES6

2.0.1

  • Fixes network activation bug
  • Fixes issue with uploading to bucket root

2.0.0

  • Redesigns options page
  • Allows for instance override of network config in WPMU
  • Upgrades to latest version of the AWS SDK
  • Adds additional AWS regions
  • Improves configuration experience
  • Reduces plugin footprint

1.9.1

  • Reverts accidentally released ads feature. Sorry for the mishap on this — the selectors were broad and still a work in progress (ads showing on non-plugin pages). Elements of the wrong branch got introduced into this release inadvertently.

1.9

  • Upgrades to the latest AWS PHP SDK

1.7.2

  • Grunts the plugin and object orients the JS.

1.7.1

  • Corrects some bugs that are resulting in notices

1.7

  • Users have expressed use cases where the automated S3 push is needed but they wish to not modify the attachment URL. Adds this option
  • WP 4.4 added functions for defining the srcset polyfill. This functionality is now supported by tcS3.

1.6

  • Adds fallback option where users can opt to use the tcS3_media endpoint OR link directly to their S3 bucket
  • Increases hook priority to 20 to allow for various image editing plugins to have their work pushed to S3
  • Adds support for the use of environment variables to store AWS keys and secrets

1.1

  • Bug fix where some environments don’t show menu options for plugin when plugin installed from the WordPress repository
  • Bug fix where some environments choke on upload of non-images

1.0

  • Initial Release