Do not include AWS S3 URLs in documents or database, do not use "href" in production

[di]

Currently, when we are storing an image in S3, we are storing a reference to it's static URL on AWS. For example, for all cover photos:

'cover': [{
    'href': 'https://s3.amazonaws.com/lime_95705a37fcff2f32d49c430a57a2eddf/IMG_3180.JPG', 
    'resize_href': '/image/IMG_3180.JPG'
}]

Now that we have the /image/ endpoint, we need to stop including this reference and stop using it in templates and in Lime.

The main reason is that, in this example, the static AWS url is for all intents and purposes identical to the /image/IMG_3180.JPG href, and thus redundant.

The reason why this just has become a problem is because during migration between development and production, the AWS bucket does not remain the same, and thus all of these links would point to the bucket of the development user.

Steps to complete this issue:

1. Make attribute redundant when saving in frontend (Ryan);
2. Make href redundant to resize_href in all DB entries (Dustin);
3. Remove attribute from model when saving in backend (Dustin);
4. Remove attribute from model when saving in frontend (Ryan);
5. Check Lime for usage, and switch to href (Ryan);
6. Check production sites for usage, and switch to href (Ryan);
7. Remove all references to resize_href in production DB (Dustin).

[ryanhinkel]

Lime now saves both the href and the resize_href (deprecated) for both a Vertex.Medium.Photo and for cover images as "/image/

So I believe we can move on to step 3 - making hrefs redundant to resize_href in all DB entries. Explicitly, I think this means that all hrefs will be changed from the absolute s3 path to the relative /image/ path. This should not break any templates, right?

[di]

This should not break any templates, right?

It will not break any templates, but due to the image-rendering bug, the images might not show up immediately. After I do step 3 we can hit all the sites to make sure the images render... and eventually we will fix that bug too.

[ryanhinkel]

Ah, but doesn't /image/ without a resize just pass right through?

[di]

Yes, this is true.

[di]

We're now onto steps 4/5/6.

[ryanhinkel]

Step 4 was the only instance where Step 5 usage was happening.

We are on to step 7

[di]

All references to resize_href have been removed from the production DB.