Foundation.mozilla.org: Return full URL for `glyph` values in News model

[gvn]

Currently only getting a path, eg:

images/news/visit-the-internet-s-dark-side-at-this-demented-apple-store_1490306555.svg

Should be:

https://ASSET_DOMAIN/network/images/news/visit-the-internet-s-dark-side-at-this-demented-apple-store_1490306555.svg

(FWIW: thumbnail has the correct behavior already.)

[gideonthomas]

@Pomax any idea how to fix this? it looks like we use filebrowser_safe for the glyph field which internally treats it as a simple CharField so when we call stron it, it returns just the path and not a fully qualified url. Do you know how to get the actual url? I'm having a hard time figuring it out because I keep getting an error saying that there is no file attached to the actual field.

[Pomax]

Hmm, we should be using filebrowser_s3, which hooks in the FileField, so switching the type should fix things?

[gideonthomas]

I might need your help with this. filebrowser_s3 provides the backend for storage, which is great. What it doesn't seem to have is the front-end form field that allows you to pick from the media library. I think this is why filebrowser_safe was used. But clearly we can't use filebrowser_safe because it doesn't really deal with a File object (so our paths get screwed up). So it looks like we might need to copy/paste some of the form field stuff over to filebrowser_s3. Or maybe there is an easier way to do this. Let's try to figure out a solution tomorrow.

[Pomax]

based on some investigative work, this will become two issues:

1. updating the News serializer.py so that the glyph field gets an override that prepends the asset domain explicitly, while maintaining the FileBrowserField type tied to Mezzanine's filebrowser_safe (this issue)
2. updating our filebrowser_s3 library drop in that replaces filebrowser_safe functionality so that in addition to taking over the FileField, it can also take over the FileBrowseField, effecting file uploads to an S3 bucket rather than the local filesystem. (issue #781)

[gvn]

I'm still seeing only filepaths for glyphs on the response.

[Pomax]

The PR had not yet landed - should be in master now.

[gvn]

Glyphs are now URLs, but they are broken if you follow them...

[Pomax]

hmmmm... @cade would you be able to tell what is missing in the absolute paths based on a deeper knowledge of how we AWS-organize data?

[Pomax]

looks like the AWS_LOCATION variable is still missing.

bad glyph (current response): https://assets.mofostaging.net/images/news/the-woman-whose-phone-misdiagnosed-hiv_1492475903.svg
good glyph: https://assets.mofostaging.net/network/images/news/the-woman-whose-phone-misdiagnosed-hiv_1492475903.svg

Difference between the two is the AWS_LOCATION (network in this case) in between the host and the asset path.

[cade]

From the original writeup in the issue, I'd be surprised if

https://ASSET_DOMAIN/network/images/news/visit-the-internet-s-dark-side-at-this-demented-apple-store_1490306555.svg

actually works. Usually websites need a .com or .net or .holdings or something before all the slashy bits. Did you try ASSET_DOMAIN.com?

Maybe @cadecairos knows more about how the tubes get routed than I do... 🤷‍♂️

[ryanwarsaw]

@Pomax ^^ the beer count just keeps going up higher and higher 🍺

[Pomax]

I'm okay with that.