-
Notifications
You must be signed in to change notification settings - Fork 139
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to check if asset exists when using "use this filename" option #1489
Comments
Hi, thanks for getting in touch and for all the info! We already use the value mapped under “Use this filename for assets created from URL” to check if the asset exists: https://github.com/craftcms/feed-me/blob/6.2.1/src/fields/Assets.php#L183-L185. I have tested this, and I can see it working as expected. In your case, I suspect the problem might be with the concatenation with That being said, it looks like, in the case of those very special URLs, we cannot determine the extension of the remote file, so providing a value under “Use this filename for assets created from URL” with an extension works as you’d expect it to. That takes care of the first import, but on the second import, assuming the filename from your data is That explains why the match is not being found, and I have raised a PR to adjust this check to account for an empty extension. The
|
Resolved in #1506 and will be included in the next v5 and v6 releases. |
Sorry I never replied to this! My apologies. For info and future reference if it helps, this was using an AWS filesystem, not local. The issue stems from the fact that the generated SharePoint image path, provides no usable filename, so I have to craft one from the available image metadata i.e. original filename and point FeedMe to use it, otherwise it just can't handle it on its own. I personally think the generated file value from the Microsoft Graph API is horrible so being able to supply a filename, is absolutely needed here, which we are doing with manipulating the data. These are the errors that are being reported, although doesn't block the image field being populated. |
@i-just I still think there's further areas around this that could be investigated. We still see errors like the above when feed imports occur, specifically for these images which have horrible URLs. It also triggered some undesired behaviour related to Amazon Cloudfront where Craft was sending invalidations specifically for these images constantly because Feed Me thinks they are new or can't be matched. Invalidations can be expensive, so this caused a bit of a spike in our AWS billing. The default cache max-age value wasn't set to a high value (which is completely on me) but Feed Me not being able to determine these images exist as assets, was also a contributing factor. Because the URL provides no obvious extension and mime type sniffing isn't going to yield anything because there's nothing to go on we have to pass a file extension in the filename. I suspect this might be the issue with the matching, but it's a catch 22, without doing this we can't even get Feed Me to import the asset URL. We unfortunately can't change the asset URL directly, only influenced a nicer filename through the use filename option. This however I think is part of the problem, but we also rely on it to even get the assets able to be created to begin with, a fun loop! |
Description
I have a feed which is importing assets to an entry, this is the feed configuration for reference relating to the asset field.
Options configured:
Strategy:
✔Create new Elements
✔Update existing elements
Asset field options:
✔ Create asset from URL
If exists: replace existing asset
Use filename for assets created from URL:
Specific field with filename value: A filename value is provided in the Feed Me mapping.
There's a bit of processing behind the scenes for this asset import initially, because it's coming from a Microsoft SharePoint site (Microsoft Graph API). The image URLs provided directly are not publicly accessible, because it is an intranet site, but there is a way to generate a public image URL with a token that last for 1 hour. This feed is being provided an image URL which is public and valid as it is generated on the feed being triggered, but only for 1 hour. However the idea is, Feed Me can import the asset from this temporary URL when the feed starts and then store this as a asset instead going forward.
The first issue which is unrelated to Feed Me is the URL generated from the Microsoft Graph API looks like this horrible mess:
One of the first major problems is there is no file extension to infer this is an image, which is a problem when importing to image fields with specific file type restrictions. Likewise getting any usable filename from the URL like this offers nothing valuable or remotely usuable.
However, using the filename option, we are providing something that works. The origin API data provides the original filename of the generated image even though this cannot be used as a image URL path, so a value such as "25938-Army-Careers.png" is provided to the "Use this filename for assets created from URL" option, which resolves this problem.
This allows the asset import to work and not get blocked by the lack of file extension, but every time the feed runs the asset import doesn't appear to be working entirely and is logging this error:
newImage is the field handle of the asset field.
It appears because of using the replace i.e. conflict option, it couldn't confirm if the image existed. However, the image does exist and was first imported on the very first time this item was imported. Any subsequent update however triggers the same error, across any item.
I originally had "Use existing asset" set, however I found on every feed run it was duplicate the same image but naming it with _xxxx and generated 1000s of images. With "replace existing asset" it appears to be throwing an error but doesn't duplicate images each time.
I'm not sure if there's a bug here, or if due to the exotic asset importing setup needed, it's going outside of the current scope of asset importing/handling.
Steps to reproduce
Additional info
The text was updated successfully, but these errors were encountered: