Support » Plugin: tcS3 » 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.

    • This topic was modified 2 years, 1 month ago by rpickett. Reason: tried it again, found more problems
Viewing 1 replies (of 1 total)
  • Plugin Author TC McCarthy

    (@tcmccarthy1)

    Thank you for the thorough review. I have addressed a number of the concerns in this review.

    1. I have updated the inline instructions to include links to the aws s3 IAM keys.
    2. I have updated the language to match the references in the IAM section of AWS dashboard
    3. Trailing and leading slashes are now being JS enforced where appropriate. Good catch! This is a pet project of mine that I developed on my own, serving as my own QA so things like this slipped through.
    4. With regards to the local path and URL, I am populating initial values via the WP_CONTENT_PATH and WP_CONTENT_URL constants, which can be overridden. If you had an older version of this plugin initially I didn’t replace those values since there were hundreds of people out there whose configurations could be hosed by the upgrade. There are regular expressions in my code for building the S3 keys in a multisite environment. This plugin is in use in 3 enterprise-level multisite installs (that I know of) without issue. One of them even uses the multinetwork plugin and it’s fine. Unless I’m not understanding your issue correctly, it seems you had an issue specific to you.
    5. With regards to the delete local files option, you’re right! I had an unset call for non-image uploads but neglected to supply one for my image upload handler. That’s now included in the latest version.

    Your nice-to-haves are truly nice to have — I will try and accommodate in coming releases but, fair warning, my development cycle is based on juggling real life. Most of this plugin’s maintenance happens organically as I use it in my business.

Viewing 1 replies (of 1 total)
  • The topic ‘Config is a comedy of errors, and doesn’t actually work’ is closed to new replies.