Cover Block: Add Image Resolution options #62926
Conversation
|
Size Change: +385 B (+0.02%) Total Size: 1.77 MB
ℹ️ View Unchanged
|
|
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 Unlinked AccountsThe following contributors have not linked their GitHub and WordPress.org accounts: @Bladed3d. 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. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
@t-hamano could use review here. |
|
If we do this, it should go in the "Settings" panel, like the Image block does. |
|
Flaky tests detected in 7a50d21. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/10512593025
|
|
@richtabor If we have to transfer I see you've raised an issue (#64703) to provide background support to the cover block as a popover, like we do with the group block. If we're going to incorporate it in the cover block, I believe we should also include a resolution option in the background support. What do you think? |
|
@aaronrobertshaw @andrewserong Thank you for the feedback!
In my experience, if any media was used in the block, the class names Here is one purpose of this class that I could find. It seems to be used to apply styles only to images uploaded via WordPress. If this class is not necessary for the Cover block, we should not need to add the deprecation.
Yes, we did not expect the refactoring initially, but we needed to use
I think this is a very good question. If I compare the background image support with the ad-hoc control of the Cover block, the only thing that background image support is missing is the resolution option, and the functionality is almost the same. And considering the performance of the website, background image support should also have a resolution option. One concern is that the cover block supports the featured image, and if the featured image is used, background image support itself needs to be disabled. As far as I can tell, there is no way to dynamically control whether block support is enabled/disabled based on a specific block's attributes. Ultimately, is the best solution the approach of refactoring using a |
|
Could use your review on #65432 |
There was a problem hiding this comment.
Thanks for your patience here @akasunil 🙏
The current Settings panel does not use the ToolsPanel component, so the entire settings panel is refactored.
When you get a chance could you update the PR description to reflect the current state of the PR?
In the meantime, I've finally had a chance to give this another look after #65432 has been merged and this PR rebased.
It mostly works well except for some issues around resetting the new resolution control. I've left an inline comment on a thread to follow to fix it.
Screen.Recording.2024-10-18.at.12.21.35.pm.mp4
| // Try to use the previous selected image size if its available | ||
| // otherwise try the default image size or fallback full size. |
There was a problem hiding this comment.
| // Try to use the previous selected image size if its available | |
| // otherwise try the default image size or fallback full size. | |
| // Try to use the previous selected image size if it's available | |
| // otherwise try the default image size or fallback to full size. |
Nit: Typos
| @@ -219,6 +256,7 @@ export default function CoverInspectorControls( { | |||
| </ToolsPanelItem> | |||
| </> | |||
| ) } | |||
|
|
|||
There was a problem hiding this comment.
Nit: Accidental whitespace change after rebase?
| <ResolutionTool | ||
| value={ sizeSlug } | ||
| onChange={ updateImage } | ||
| options={ imageSizeOptions } | ||
| /> |
There was a problem hiding this comment.
The reset behaviour for this control seems pretty odd.
I think it might be missing the defaultValue prop otherwise it shows as having been modified before the user touches it. It's also used when resetting the control individually.
If the default value prop isn't provided it will fall back to the first option in the available sizes which in my testing was thumbnail. That is different than how this panel's resetAll is resetting the sizeSlug.
There was a problem hiding this comment.
It should be working fine now, i have set default value to "Full Size"
Edit-Post-.Test.-.-gutenberg-.-WordPress.webm
|
Thank you @aaronrobertshaw for quick review.
I have updated the description. |
There was a problem hiding this comment.
Thanks for sticking with this one @akasunil 💪
The resetting behaviour now works for me after the latest updates. I think this is good to go 🚢
Screen.Recording.2024-10-21.at.12.17.44.pm.mp4
| const { gradientValue, setGradient } = __experimentalUseGradient(); | ||
| const { getSettings } = useSelect( blockEditorStore ); | ||
|
|
||
| const imageSizes = getSettings().imageSizes; |
There was a problem hiding this comment.
It appears as though there are a large number of places in the codebase where the presence of imageSizes in the settings is assumed. This could still be a touch more robust in the face of future changes if we fell back to an empty array if it isn't available. Up to you if you'd like to tweak it before landing this.
There was a problem hiding this comment.
If imageSizes is set to empty, ResolutionTool wont be visible. We could set fallback value for this, but if user have set imageSizes setting to empty array, should we fallback it to default value again?
Also, We could create hook to set default value if imageSizes setting is empty.
There was a problem hiding this comment.
If it is null or undefined, the filter and map call below would throw an error.
There was a problem hiding this comment.
I have added optional chaining operator to avoid errors. Thanks for the feedback.
|
I'm curious why the resolution setting isn’t available when a feature image is used. Are there specific reasons for this limitation? |
|
Yes, we really need this for featured images. It seems to have been missed and is using the full size. |
Featured images work differently, so they likely need specific handling. My understanding is that this was outside the scope of this PR. With the complexities encountered here, it makes sense to refine that and ensure the approach is solid before expanding the scope to featured images as well.
If there isn't an issue already dedicated to this, it would be great if you could create one. Having a dedicated issue creates awareness and helps any contributor that is interested to jump in and propose fixes and enhancements. |
|
It looks like this is the dedicated issue: |
* Add attribute for resolution of image in cover block * Add resolutionTool into cover block for background images * Relocate the resolution control in inspector control * Add image size class to image on save * Retain previous value of sizeSlug attribute on image change * Update url based on selected image size * Update setting panel using ToolsPanel component * Remove clear media button from setting panel * Remove Resolution Tool component from dimension panel * Update role of setting panel in unit test * Remove unneccessory code * Remove typecasting for boolean variable and update default value * Set default value to full size for media size slug attribute * clear whitespace and typos * Set default value for image resolution * Fix empty image sizes condition Unlinked contributors: Bladed3d. Co-authored-by: akasunil <sunil25393@git.wordpress.org> Co-authored-by: t-hamano <wildworks@git.wordpress.org> Co-authored-by: aaronrobertshaw <aaronrobertshaw@git.wordpress.org> Co-authored-by: richtabor <richtabor@git.wordpress.org> Co-authored-by: andrewserong <andrewserong@git.wordpress.org> Co-authored-by: codebymikey <codebymikey@git.wordpress.org>
Hi @aaronrobertshaw, Maybe I'm missing something, but isn't it just a matter of passing the |
|
Thanks for the question @huubl 👍
Unfortunately, there's more to it than that. Your suggestion only covers the rendering of the featured image for the block on the frontend. It misses updating the editor. The edit component for the block will need to be updated to make sure it is using the correct featured image media url for the selected image size. The featured image can also be updated outside of the block itself so there'd be a filter handling that url that will need tweaking further. With the benefit of having landed the handling of image resolution options for normal images already, it should now be a smaller step to supporting featured images as well. In other words, the existing code for uploaded images can serve as a reference for anyone that would like to take a run at extending the image resolution support. This enhancement isn't something I have the bandwidth for at the moment but I'd be very happy to help out with reviews if you'd like to put a PR together? |
|
Thanks for the detailed explanation, @aaronrobertshaw! That clears things up. I see @akasunil has made a pull request which is already merged. That's awesome! |
What?
Fixes: #58819
Why?
Resolution option were missing from cover block for background images
How?
This PR add
ResolutionToolto cover block, when cover has background imageTesting Instructions
Screenshots or screencast
cover-block-image-resolution-control.webm