Media ContentItems updated to Assets with different extensions will not be reflected in pre-existing Blog Posts about cortex HOT 11 CLOSED

@MKwenhua so neither of the given solutions would be the ideal path for this issue, allow me to detail:

• If we were to save all the images as .jpg or .image it would not make sense from a data perspective (or even really from a human perspective) we would effectively lying to everyone and hoping the browser is smart enough to call us out. For the purpose of Cortex being entirely (or at least primarily) API-centric this does not make sense to proceed with
• Again this does not make a whole lot of sense from a data perspective, if a client application were to consume raw data, or even a developer poking around in the backend, accessing the URL of the object should simply be a matter of reading the metadata (as it is for the most part now). Additionally throwing this into the mix for every read action on an image becomes extraordinarily expensive over time.

Instead I would recommend looking into intercepting the metadata and overwriting previous assumptions made about the image (technically the previous file type no longer matters), I have a relevant PR on this - check into overwriting this in either the styles hash, existing metadata hash, or both as the case may be.

from cortex.

@ElliottAYoung Ok agreed, making all images have a uniform extension is misleading so how about this:

• Depending on whatever the current Uberflip setup allows for blog posts to update when the model changes, we could just pull all ContentItems that use the image and replace the img source with the updated image url. (This would only happen if the extensions are different)

• Also currently I noticed that when I just saved and created a blog post with an embedded image asset that the model did not seem to have the content_item_id saved:
  

• Do we currently have a has_and_belongs_to_many association between ContentItems like an asset could have many blog posts and a blog post could have many ContentItems

from cortex.

@MKwenhua We've had a few stories / PRs in the past that deal with this kind of asset consistency, I would recommend taking a look at them and seeing what we've done. It isn't necessarily trivial, but it is wholly possible to intercept the filetype of the asset before the metadata hits the Paperclip initialization.

I would begin by digging through old, relevant PRs in the core plugin and going from there

from cortex.

@ElliottAYoung I have been reading through PRs, but the issue isn't really related to Paperclip. Right now if an Asset ContentItem gets updated, that Asset content type will be the new file. The problem right now is that in a blog post if I embed an image of an Asset Type of id: 119717ea-1681-4590-8ee3-c7d3c722c029 with the url asset_field_types/assets/the_kong-original.jpg and then later I happen to change the image of that asset to a png the URL will now be asset_field_types/assets/the_kong-original.png which is ok if I were to create a new post, but the previous post still references the jpg extension.

Anyways I think I know a pretty standard solution, @toastercup what do you think?

from cortex.

@MKwenhua while it may not be a paperclip issue those urls are being generated by the metadata passed into the paperclip initializer in the asset_field_type model:

Paperclip::HasAttachedFile.define_on(self.class, :asset, existing_metadata)

I would be willing to bet dollars to donuts that your problem lies in the generation of the style urls, which are what's being used for the on-page rendering of the asset. This is further backed by the fact that the image of a different file type has no problem uploading and being viewed at a direct url (asset_field_types/assets/the_kong-original.png will still show the correct picture)

My recommendation is to look into how we are handling the style_urls in the asset_field_type model - play around with them a bit and see what happens to them when you switch file types.

from cortex.

I think we discussed this last week - if getting the URL to update is an issue, my recommendation is to just produce an error to the user if they try to upload the wrong extension.

To address some of your points:

Change the embedding code to use a ContentItem id and use that to look up the asset's URL

This is already what we do - it might require some additional tweaking if it's not grabbing the latest asset URL on every save of the Blog Post, but this is exactly what our widgets/shortcodes were designed for.

Also currently I noticed that when I just saved and created a blog post with an embedded image asset that the model did not seem to have the content_item_id saved:

If this is the case, then that is definitely a regression and we should address it - it might be why things aren't getting updated. Is this for the Featured Image field?

from cortex.

PS just to clarify - we would revisit the wrong-file-extension-error in a future story

from cortex.

@toastercup Ok I will just switch it to a validation error.

from cortex.

👌

from cortex.

@MKwenhua is this issue ready to close? Also, would you mind cleaning up the grammar and tightening up the length of the Issue title? (this project could be open-sourced one day!)

from cortex.

@toastercup Ok I will fix up the grammar, shorten the title and close it.

from cortex.