-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
adds new edit flow for the cover block #15519
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for splitting these out into separate PRs, makes it so much easier to do a thorough review!
I spotted a few things that would be good to address.
cdc0d64
to
2d153a5
Compare
} ); | ||
} | ||
|
||
this.toggleIsEditing(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like it might be safer if this could be called with an argument to force the value of isEditing
- this.toggleIsEditing( false )
. That would specifically turn off editing mode. That would prevent a scenario where onSelectUrl
is called when isEditing
is false
resulting in a transition back to the placeholder.
@@ -134,6 +161,8 @@ class CoverEdit extends Component { | |||
{} | |||
), | |||
} ); | |||
|
|||
this.toggleIsEditing(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same comment as above here. I think this should specifically set isEditing
to false
instead of just toggling.
</> | ||
<Toolbar> | ||
<IconButton | ||
className={ classnames( 'components-icon-button components-toolbar__control', { 'is-active': this.state.isEditing } ) } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still seem to have components-icon-button
class here, which can be removed.
Ah, that's a good point. If we can add that in, that'd be great. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @draganescu, cover supports video and images as backgrounds, and there is an attribute to differentiate between both, this PR does not changes that attribute, and we keep it equal to the previously used or we default to the image if the block was just created.
I think we should set this attribute in accordance with if the URL is an image or a video.
There are two ways to go:
- Add UI to allow the user to choose if an image or a video is being inserted.
- Automatically detect if the URL is a video or an image.
If we follow the UI path possible solutions are having two different buttons on that allows inserting an image and other that allows inserting a video. Or, we can have one button but add a select control at the side of the URL.
If we follow the automatic approach we have two options:
- Make a headers request to the URL and verify its mime type, for URL in other domains we may have cross-domain request problems.
- Add the URL invisible elements containing image and video, then use the DOM API to understand if the elements include an image or video I guess we can guess using the dimensions of the element and other properties that should only be available if the element loaded with success. This approach is hacky but is probably very reliable, I guess there may be some npm package that does this, and if not it may be interesting to create a simple one.
|
||
const onSelectUrl = ( newURL ) => { | ||
if ( newURL !== url ) { | ||
this.props.setAttributes( { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are not setting the media type so, If I have a video as the cover, and I switch to use an image by URL things fail because the media type is still video.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oups!
2d153a5
to
017179e
Compare
#11952 changed direction so closing this as it became irrelevant. |
Description
Closes #14795, #10853, #16350
This is a follow up to the image block edit flow update which ports the new flow to all the blocks which have media with an edit state.
How has this been tested?
For now I've only tested locally.
Types of change
New feature (non-breaking change which adds functionality)
Screenshots