Image-Uploading #419

New Issue

2026-06-29T08:38:09Z

rob commented

2026-06-29 08:38:09 +00:00

Important

This ticket is for specification and estimating. I'm opening another ticket for discussion so I can get answers I need to finish this one.

Image uploading currently sucks. This is a bit of a meta-ticket, as there are two broad things I want to fix, both of which are probably estimates in their own right.:

Allow uploading of images directly to product/combo info pages. Consider ditching bulk-upload for now, or if we must keep it, re-implement that as well.
Stop hosting pictures on our web servers. Stick them in S3 instead, for cheap, durable, scalable storage. See #120

After further thinking, this issue should be the primary one, since it's probably more efficient and cleaner to just implement this stuff in one go. The current image handling code is ancient, and in pretty bad shape due to a bunch of old updates/hacks.

Questions

Requirements

Existing image URLs must be maintained, even if deprecated by new URL structure.
New URL structure could support include customer-domain. ex: http[s]://rdmobile.estack.com/img/101222/some-image-file.jpg
- There may be trade-offs here which we don't like. If necessary, it's acceptable to have URLs like: http[s]://img.estack.com/rdmobile/101222/some-image-file.jpg.
- Keeping estack.com as the main domain while supporting https, means we need to proxy requests through our servers, or set up CloudFront with SSL.
Multi-file image upload functionality added to product images tab, as well as combo-edit screen.
Original image filenames (some-image-file.jpg) should be maintained when possible. If a file with the same name is re-uploaded, some variation should be created (some-image-file.[1,2,3,...].jpg).
The system should be be smart enough to recognize identical files (by comparing data in the files). If a dupe is uploaded, it should be ignored.
Upon successful upload/validation, the files are placed in an S3 bucket, with a path that encodes custId and SKU.
A migration script to transfer existing images from eStack infrastructure to S3 will be necessary.

Implementation

Due to version issues with Amazon AWS SDK, we probably want a standalone command-line estk-s3-copy command that main eStack calls. Invokation would look like estk-s3-copy /tmp/some-uploaded-file.jpg /rdmobile/101222/some-uploaded-file.jpg.
ImagesController should simply proxy HTTP

Estimates

Set up AWS account
- Provision an account
- Create an S3 bucket

# Important This ticket is for specification and estimating. I'm opening another ticket for discussion so I can get answers I need to finish this one. Image uploading currently sucks. This is a bit of a meta-ticket, as there are two broad things I want to fix, both of which are probably estimates in their own right.: 1. Allow uploading of images directly to product/combo info pages. Consider ditching bulk-upload for now, or if we must keep it, re-implement that as well. 2. Stop hosting pictures on our web servers. Stick them in S3 instead, for cheap, durable, scalable storage. See #120 --- After further thinking, this issue should be the primary one, since it's probably more efficient and cleaner to just implement this stuff in one go. The current image handling code is ancient, and in pretty bad shape due to a bunch of old updates/hacks. # Questions # Requirements * Existing image URLs *must* be maintained, even if deprecated by new URL structure. * New URL structure *could* support include customer-domain. ex: `http[s]://rdmobile.estack.com/img/101222/some-image-file.jpg` * There may be trade-offs here which we don't like. If necessary, it's acceptable to have URLs like: `http[s]://img.estack.com/rdmobile/101222/some-image-file.jpg`. * Keeping estack.com as the main domain while supporting https, means we need to proxy requests through our servers, or set up CloudFront with SSL. * Multi-file image upload functionality added to product images tab, as well as combo-edit screen. * Original image filenames (`some-image-file.jpg`) should be maintained when possible. If a file with the same name is re-uploaded, some variation should be created (`some-image-file.[1,2,3,...].jpg`). * The system *should* be be smart enough to recognize identical files (by comparing data in the files). If a dupe is uploaded, it should be ignored. * Upon successful upload/validation, the files are placed in an S3 bucket, with a path that encodes custId and SKU. * A migration script to transfer existing images from eStack infrastructure to S3 will be necessary. # Implementation * Due to version issues with Amazon AWS SDK, we probably want a standalone command-line estk-s3-copy command that main eStack calls. Invokation would look like `estk-s3-copy /tmp/some-uploaded-file.jpg /rdmobile/101222/some-uploaded-file.jpg`. * ImagesController should simply proxy HTTP # Estimates * Set up AWS account * Provision an account * Create an S3 bucket

rob closed this issue

2026-06-29 08:38:09 +00:00

Sign in to join this conversation.

No Label

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: rob/pms3#419