wp-graphql / wpgraphql-acf

Re-architecture of WPGraphQL for ACF
GNU General Public License v3.0
83 stars 12 forks source link

Allow oEmebed fields to be queried as "raw" or "rendered" #150

Open jasonbahl opened 9 months ago

jasonbahl commented 9 months ago

What problem does this address?

Oembed fields used to (in v0.6.* and prior) return the raw URL that was input to the field.

In v2.0, oembed fields return the "rendered" iframe embed.

Some users like the new functionality, but some prefer the old and want their client application to generate the embed.

What is your proposed solution?

Provide an argument on oembed fields allowing the client to decide how the field should be returned.

Similar to the content(format:RAW) or content(format:RENDERED) argument on content/title fields.

This would allow clients control of how the data is returned for their use case.

What alternatives have you considered?

Add a setting on the server allowing the server to configure the return type. This limits the client's flexibility, but might be worth considering still.

Additional Context

see: https://github.com/wp-graphql/wpgraphql-acf/issues/106#issuecomment-1884294816

amcc commented 8 months ago

Thank you for suggesting these features. I'm using the oEmbed field for essentially storing urls of videos and other embedded media. The reason why this field is great in the back end is that you get a preview. However on the front end you often want the source url.

Consider having a YouTube video you may want the iFrame, but you often also want a link to go to the YouTube page itself. (The src of the iFrame is not the correct YouTube page url so you can't parse it from the html).

In a custom front end I (and trans I work with) have normally created a custom plugin to deal with all the r embedded media. Players like React Player work very well and are predictable with many different display options. Often people want to embed something that doesn't automatically get iFrame html. The front end can deal with this easily with the url.

With an image you have access to multiple things like secSet and source url. Something like this would work well in the returned graphQL if that is possible.

jasonbahl commented 8 months ago

I see 2 options forward here:

1: provide an argument on the field, like:

myEmbedField( rendered: TRUE )

or

myEmbedField( rendered: FALSE )

2: change the shape of the field (breaking) that returns both fields:

  myEmbedField {
    rendered
    raw
  }

The former I think we can do in a non-breaking way, supporting both features and letting the client chose how to format the response. And via GraphQL Aliases the client could ask for both formats:

renderedEmbed: myEmbedField( rendered: TRUE )
rawEmbed: myEmbedField( rendered: FALSE )
amcc commented 8 months ago

my preference would be the second option - though having just looked through the current output i can see it may introduce breaking changes. Option 2 seems very useful, there are instances where i have wanted to use an iframe and the url (i.e. show the embed and put the link next to if if someone actually wants to go to the youtube site). Personally i'd do this via something like React Player, but others may want the iframe code.

Option 2 makes this much more similar to the image field - where you have a number of types of data you can receive (eg scrSet, sourceUrl, etc). Passing options to a field makes this one slightly unusual and perhaps less beginner friendly, plus as a developer its very useful to compare output in GraphiQL but including different options without passing options.

Is there perhaps a 3rd way (if you want to avoid breaking changes) where an option could be passed so we provide all potential options: myEmbedField( format: URL ) myEmbedField( format: IFRAME ) myEmbedField( format: OBJECT ) // contains both url and iframe