added support of insert from url option in cover block

[akasunil]

Currently it isn't possible to insert images or video via url for cover block.

What?

Fixes 10853

Testing Instructions

Please include step by step instructions on how to test this PR.

1. Go to post edit.
2. Insert a Cover Block.

Screenshots or screencast

[akasunil]

@Mamaduka can you please review this PR.

[Mamaduka]

Thanks for working on this, @sunil25393.

Unfortunately, using regex to detect media type won't work with URLs that don't have extensions attached. E.g. - https://avatars.githubusercontent.com/u/61308756?s=200&v=4.

[akasunil]

Thanks for working on this, @sunil25393.

Unfortunately, using regex to detect media type won't work with URLs that don't have extensions attached. E.g. - https://avatars.githubusercontent.com/u/61308756?s=200&v=4.

Have addressed feedback. please review it again.

[akasunil]

Any more feedbacks ?

[akasunil]

@Mamaduka can we merge this PR if there isnt any more feedback.

Thank you.

[Mamaduka]

Hi, @sunil25393

Sorry, I didn't get a chance to test or review changes here.

Quick notes:

• We shouldn't add a new dependency to use fetch. The window.fetch should work here. Example in core - https://github.com/WordPress/gutenberg/blob/trunk/packages/api-fetch/src/index.js#L101.
• Have you tested that getContentTypeFromUrl doesn't produce CORS errors in the console?

[akasunil]

Hi @Mamaduka

I have addressed feedback, and tested to make sure that isn't any CORS errors in the console.

[akasunil]

Waiting for PR review.

[Mamaduka]

I pinged some folks who recently worked on the Cover block for the reviews.

[draganescu]

Hi @sunil25393,

Generally this works well if the host that we're linking to allows it. For instance I can easily run into:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://jsoncompare.org/LearningContainer/SampleFiles/Video/MP4/Sample-MP4-Video-File-Download.mp4. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 200.

But this other host https://vod-progressive.akamaized.net/exp=1661274774~acl=%2Fvimeo-prod-skyfire-std-us%2F01%2F3603%2F14%2F368016235%2F1522131611.mp4~hmac=1558863b3bea9ef9660af2cfd3e6e8adce91ae3310367141d718837f2f1b198f/vimeo-prod-skyfire-std-us/01/3603/14/368016235/1522131611.mp4 works just fine.

This inconsistency has to be treated better, not sure how, but at this point as a user I have no idea why it does not work.

I have tested with URLs that allow remote linking and the features work as expected. We just need to figure out what to do if:

• the media is being blocked by CORS
• the media is not image or video, and we supply a link to a pdf - in the other cases we limit the "picker" to media files, but a user may paste any URL to any kind of file.

[akasunil]

i see, do you know how we do for external image on image block ?

[draganescu]

We don't do it there perfectly either. We can link to a pdf file and get an empty block.

Nevertheless in the image block we don't have to deal with CORS because the <img> tag used in the block's rendering is not subject to CORS policies, hence we don't do anything.

In the case of the cover block it is in your implementation of getContentTypeFromUrl where the CORS problem is triggered as we cannot read cross origin files by default. The CDN example allows it by default because its their policy but the other domain has the standard policy in place. Since we cannot detect the type because CORS prevents us, we would need a way to ask the user what they're linking to.

Added a needs design feedback for this.

[akasunil]

Thank you @draganescu. as you said, we should add field for content type of link.

[richtabor]

Added a needs design feedback for this.

Do we just need a better alert/fallback state when there's a failure?

[draganescu]

@richtabor no, we also need to ask what kind of file are we linking to.

[akasunil]

@draganescu need some design input for this, how we can implement content type field ?

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @Wolf-DieterFiege.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Unlinked contributors: Wolf-DieterFiege.

Co-authored-by: sunil25393 <[email protected]>
Co-authored-by: Mamaduka <[email protected]>
Co-authored-by: draganescu <[email protected]>
Co-authored-by: richtabor <[email protected]>
Co-authored-by: Soean <[email protected]>
Co-authored-by: talldan <[email protected]>
Co-authored-by: bph <[email protected]>
Co-authored-by: joemaller <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.