API returns incorrect URLs after file manager URL prefix is changed

[owenfarrell]

Version

5.37.4

Operating System

n/a

Browser

n/a

What are the steps to reproduce this bug?

• Add a new file to the file manager
• Create a headless CMS model that includes a type of file
• Create a new instance of the CMS model, and reference the file
• Update the file manager setting for srcPrefix
• Make a graphql request for the headless CMS model

What is the expected behavior?

File URLs in the API response are prefixed with the new file URL prefix.

What do you see instead?

File URLs in the API response are prefixed with the old file URL prefix.

Additional information

The workaround for this bug is to manually go in and replace files with the exact same file.

I'm not sure if this included in the intended scope from #3269. Mentioning here as it sounds like FM enhancements might include this.

Possible solution

Option 1: Store relative URLs and pre-pend the URL prefix just-in-time Option 2: Batch update URLs when the file URL prefix is updated

There are a handful of downsides to option 2:

• How should published vs. unpublished vs. draft records be handled? Does this necessitate a need to create a new revision? How does modifying published records (at rest) impact an audit trail? etc.
• Updating large tranches of files could run in to serious performance constraints

[Pavel910]

@owenfarrell existing file references will not get updated after you change the file URL. So if you create a content entry, or a page, and select an image from File Manager, we store an exact URL which is generated at that point in time. Changing of URL settings will only affect new records.

The issue you linked is actually already released, and the problem you're describing was not considered in that issue.

It would be nice to have a way to handle this dynamically, but at this point in time it's not possible. One of the reaons is that the file CMS field is implemented in a very weird way, and it stores a string value, so you don't even know the file id, at runtime, so you can't dynamically do anything with it.

Batch updates are really not an option, as that kind of background updating is not scalable. So for now, you just have to configure your settings before creating production content.

As a custom solution, you could create your own file field plugin, which would store more information about the file, like { id, key }, and then handle the resolution of the URL in your API plugin.