Closed janus-reith closed 6 years ago
On a side note: The brandAsset is also affected, uploaded png Files with transparency are converted to jpeg now, thus loosing transparency.
As far as I got it, reaction-file-collections
could be used with stores that are provided in a different way, including full size PNGs, and orginal files or at least custom sizes.
The root cause of this regarding product media seems to be in imports/plugins/core/files/server/no-meteor/setUpFileCollections.js
I chose to create the issue in this repo, as imports/plugins/core/files/server/fileCollections.js, which uses the setUpFileCollections
method, is retrieving MeteorFileCollection
from @reactioncommerce/file-collections
.
I'd appreciate a tutorial or a hint on how to modify/replace this using plugins, without touching core code and hope there is a way to do so.
By default the original is not stored, to prevent people uploading giant images that will take up too much space. But a very large crop is stored in "image" store, so .url({ store: "image" })
is like former .url()
.
If you absolutely need the unaltered original, you could add another store named "original" in the list in setUpFileCollections.js and have no transform
on it, and that would then store the original. This can't be done with plugins. Reaction is moving to a microservice architecture, so eventually this will move to its own files app. At that point, it's possible that the store/transform configuration might be moved into database config to allow admins to change parts of it without changing code.
@aldeed would the core team accept a PR that adds an original
store with no transformation so that this is supported without plugins?
@aldeed the "image" store is transforming to jpeg aswell, and therefore doesn't solve my issue. Maybe setUpFileCollections could be modified to transform based on the orginal file type, at least for some common types like png, with jpeg as Fallback?
@janus-reith Yes, there may even be an issue already about that in the Reaction repo, but I know it's been discussed and I do agree it should be smarter about retaining the original file type. We could accept a PR that does that.
If we were to remove the transform completely, we'd need a file size cap, but it seems nicer to allow large originals but shrink them down. We should not add "original" because "image" IS original, just poorly named. In the catalog, it actually is renamed to "original". So the transformation there is intended to be a protective measure that ideally would allow most files through untransformed. The fact that it's changing the file type is a mistake.
Probably neither of the conversions to "jpeg" should be happening because that loses transparency.
So @janus-reith, I recommend submitting an issue for this in the main reaction repo, or a PR if you want to fix it right away.
Okay, will try to figure something out. But just to mention it: When I upload my 180px wide png, the Media in image/original store is not cropped at 1600px width, but instead the file is sized to 1600px.
Tested with a 1024px jpeg, same result. The file in the store image is transformed to be 1600px wide.
It seems like the sharp parameter withoutEnlargement
could solve this behaviour.
Adding withoutEnlargement: true
to the transform call works.
However, will continue this in the main repo.
Before the new file collections were in place, I could just call
this.props.featuredMedia.url();
on a media prop to retrieve the url for the unaltered file. The url() function now requires a store, likethis.props.featuredMedia.url({ store: "large" });
How to get the original, non-transformed image url, is it even saved on the server?