Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Comment | File | Size | Author |
---|---|---|---|
#12 | Selection_002.png | 50.73 KB | juampynr |
#10 | 2864302-10.patch | 1.23 KB | marcoscano |
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
link
and the response does not include thecode
property to embed. You would need to file an issue with the Embed library itself.Comment #5
gge CreditAttribution: 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 CreditAttribution: 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
code
not 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 CreditAttribution: juampynr at Lullabot for NBCUniversal 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 CreditAttribution: juampynr at Lullabot for NBCUniversal commentedHere is how it looks like:
Comment #13
BarisW CreditAttribution: BarisW at LimoenGroen for KRO-NCRV 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 CreditAttribution: mpp at AmeXio for District09 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 CreditAttribution: navneet0693 as a volunteer and at Open Social 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 CreditAttribution: navneet0693 as a volunteer and at Open Social commentedComment #17
navneet0693 CreditAttribution: navneet0693 as a volunteer and at Open Social commentedIf the scope of this issue is just add a validation, then this can be set to RTBC again.