Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
Hello,
The Embed library can extract info from BBC or CNN, but this module wont.
URL Embed should work with everything that works with the Embed library or I'm missing something?
With Youtube or Facebook the module works as expected.
I believe that as of today this module works with any adapters that implement the ::getCode() method. Not all of the supported ones do.
You can go to https://oscarotero.com/embed2/demo/ and test the URL you are trying to fetch. Wathever you see under the CODE section on that page is what is going to be rendered when embedding this URL into a wysiwyg.
You can see in the Embed library responses that it's returning a type of link and the response does not include the code property to embed. You would need to file an issue with the Embed library itself.
It might make sense to kind of re-purpose this to help avoid this problem for others in the future. What if we added validation to the Embed form that checks to make sure the URL is actually embeddable?
+1 for the validation.
This was more or less the idea behind #2761187: Improve how the module deals with non-embeddable URLs (although looking now at that patch I'm not sure I agree with that solution either...). Whatever gives the user some feedback is going to be useful.
Glad to see this re-opened :) The proposal #2761187: Improve how the module deals with non-embeddable URLs is a good start, but I don't understand why valid URLs should be considered only those with code not empty.
I think if that property is empty, the user should have an option to embed other properties like title, description, image.
Yeah, I think that's totally valid, but also a much more complex issue since we're having to build new things to support that workflow. Right now restricting to things that have an embeddable 'code' is easy since it's there for us, which is why adding the validation now might make sense to avoid the problem in the near future, while we figure out what the longer-term way to solve it.
This works great. At the moment if you enter an unsupported URL, the <drupal-url> tag is created but the editor does not render it, nor it is shown when the content is viewed which is confusing for editors.
#10 works but shouldn't we solve this with a Constraint on the link field?
This would require an API change as the field itself needs to be marked as a "url_embed" link and we'd need an isApplicable() on the FieldFormatter to check if the field is a url_embed field.
I wouldn't say this fixes the original problem of handling the non-embeddable URLs. Adding a validation which stops user from adding a link altogether is not a viable solution.
Comments
Comment #2
marcoscanoComment #3
marcoscanoI believe that as of today this module works with any adapters that implement the
::getCode()method. Not all of the supported ones do.You can go to https://oscarotero.com/embed2/demo/ and test the URL you are trying to fetch. Wathever you see under the CODE section on that page is what is going to be rendered when embedding this URL into a wysiwyg.
Comment #4
dave reidYou can see in the Embed library responses that it's returning a type of
linkand the response does not include thecodeproperty to embed. You would need to file an issue with the Embed library itself.Comment #5
gge commentedI did notice that empty property, but I thought that URL Embed will grab the image instead.
Thanks for clarifying!
I will file an issue on GitHub.
Comment #6
dave reidIt might make sense to kind of re-purpose this to help avoid this problem for others in the future. What if we added validation to the Embed form that checks to make sure the URL is actually embeddable?
Comment #7
marcoscano+1 for the validation.
This was more or less the idea behind #2761187: Improve how the module deals with non-embeddable URLs (although looking now at that patch I'm not sure I agree with that solution either...). Whatever gives the user some feedback is going to be useful.
Comment #8
gge commentedHi,
Glad to see this re-opened :) The proposal #2761187: Improve how the module deals with non-embeddable URLs is a good start, but I don't understand why valid URLs should be considered only those with
codenot empty.I think if that property is empty, the user should have an option to embed other properties like title, description, image.
Thanks.
Comment #9
dave reidYeah, I think that's totally valid, but also a much more complex issue since we're having to build new things to support that workflow. Right now restricting to things that have an embeddable 'code' is easy since it's there for us, which is why adding the validation now might make sense to avoid the problem in the near future, while we figure out what the longer-term way to solve it.
Comment #10
marcoscanoSomething like this seems to work for me.
Comment #11
juampynr commentedThis works great. At the moment if you enter an unsupported URL, the
<drupal-url>tag is created but the editor does not render it, nor it is shown when the content is viewed which is confusing for editors.Comment #12
juampynr commentedHere is how it looks like:
Comment #13
BarisW commentedGreat patch! Based on this code, I added an alter hook in this validation, to be able to block certain providers: #3033293: Add an option to alter the list of providers
Comment #14
mpp commented#10 works but shouldn't we solve this with a Constraint on the link field?
This would require an API change as the field itself needs to be marked as a "url_embed" link and we'd need an isApplicable() on the FieldFormatter to check if the field is a url_embed field.
Comment #15
navneet0693 commentedI wouldn't say this fixes the original problem of handling the non-embeddable URLs. Adding a validation which stops user from adding a link altogether is not a viable solution.
Comment #16
navneet0693 commentedComment #17
navneet0693 commentedIf the scope of this issue is just add a validation, then this can be set to RTBC again.