-
Notifications
You must be signed in to change notification settings - Fork 800
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
Social: Fix media validation deadlock #38933
Conversation
Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.
Interested in more tips and information?
|
Thank you for your PR! When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:
This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖 The e2e test report can be found here. Please note that it can take a few minutes after the e2e tests checks are complete for the report to be available. Follow this PR Review Process:
Still unsure? Reach out in #jetpack-developers for guidance! |
isPublicizeEnabled && | ||
( hasEnabledConnections || | ||
attachedMedia.length > 0 || | ||
( Object.keys( validationErrors ).length !== 0 && ! isConvertible ) ); |
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.
In what case will there be no validation errors when the media is not convertible?
I mean if the media is not convertible, won't there already be validation errors?
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.
Good point.
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.
So you say we should only look for ! isConvertible
in that part of the logic?
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 am not sure but my concern is that if the media is not convertible, we should already show/have validation errors. If that is not the case then we may need to fix that first, otherwise, yes, we may only look for ! isConvertible
in that part of the logic.
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 am not sure but my concern is that if the media is not convertible, we should already show/have validation errors.
Yeah we do, I think it's true that if something is not convertible, that means we have at least 1 error
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.
Cool. Thank you for the confirmation.
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 only use that here too: MediaValidationNotices
I'll update that
const { attachedMedia } = useAttachedMedia(); | ||
const featuredImageId = useFeaturedImage(); | ||
|
||
const mediaId = attachedMedia[ 0 ]?.id || featuredImageId; |
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.
Why should featured image be a part of this logic?
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 thought that if the featured image is invalid, you still get the deadlock in the editor on the jetpack tab, until you remove the featured image. If we use it here, they can also use the attached media to upload a working image without having to change the featured image. What do you think?
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.
Fair enough. Thank you for the explanation.
const { isConvertible } = useMediaRestrictions( connections, useMediaDetails( mediaId )[ 0 ] ); | ||
|
||
const showSharePostForm = | ||
isPublicizeEnabled && ( hasEnabledConnections || attachedMedia.length > 0 || ! isConvertible ); |
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.
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.
So we need the full logic as before
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.
May be we don't need to use isConvertible
here?
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 think we do because otherwise we would show the modal even if the media is invalid but convertible. For example the featured image is too big, but can be converted, in that case I think we do not need it 🤔 This logic starts to get fiddly
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.
Yeah, this logic is going to be difficult to untangle in future.
May be we can add explanatory comments to that code.
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.
Works good
* Show SharePostForm if there is attached media * changelog * Show form if there is any validation error * Use only !isConvertible * Use validationErrors * Add a small comment to explain why we do that
Fixes https://github.com/Automattic/jetpack-reach/issues/478
Proposed changes:
Other information:
Jetpack product discussion
https://github.com/Automattic/jetpack-reach/issues/478
Does this pull request change what data or activity we track or use?
Testing instructions:
Go to an already published post and have only an Instagram connection
Go to an already published post and add a media that is invalid for all connections
Go to an already published post that has no errors and no media.