Skip to content
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

Embed field values not saved consistently #203

Open
tomdavies opened this issue Oct 16, 2024 · 1 comment
Open

Embed field values not saved consistently #203

tomdavies opened this issue Oct 16, 2024 · 1 comment

Comments

@tomdavies
Copy link

Describe the bug

If I paste a video URL into an Embed Hyper field and then immediately save the page with CMD+S (without waiting for the client-side actions request to hyper/fields/preview-embed complete so you have to be quick), the value is not saved as expected.

Similarly, if I delete a value from an previously saved embed field and immediately save, the old value persists.

In both cases, if I wait a few seconds before saving the expected behaviour is observed (value saved / deleted correctly)

Alas AFAICS from the Craft core source there's not currently an easy way to prevent/defer element saves. ElementEditor.js has a beforeSubmit event, but it doesn't give us a change to cancel the submit

Steps to reproduce

  1. Create a hyper field of type "Embed" and attach it to an entry type
  2. One the entry edit form, paste an oembed URL into the field and immediately save the page using CMD+S
  3. Note that the new value is not saved

Craft CMS version

5.4.8

Plugin version

2.1.1

Multi-site?

Yes

Additional context

This is particularly noticeable in local dev under ddev, but also happens in conventional hosted envs too

@engram-design
Copy link
Member

engram-design commented Oct 19, 2024

That would be correct behaviour, at least for the moment. That's really because we don't want to save just the embed URL as the value of the link, instead we need to fetch (and wait) for the full embed data to consider it a valid embed link.

I did debate this with myself at the time on whether we should record it or not, but then it means fetching the data at a later stage, which isn't ideal for performance. There's also issues with that approach when there's a failure to fetch that data, we don't want to retry over and over again.

I'm open to suggestions, but for now you need to wait until it resolves the link.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants