Image Block: Don't render DimensionsTool if it is not resizable
#53181
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Size Change: +3 B (0%) Total Size: 1.44 MB
ℹ️ View Unchanged
|
t-hamano
added
[Type] Bug
|
I think, when wide or full width is shown, the unit control for width and height should be updated instead of hidden. This will require updating the unit control to support units other than cc @richtabor |
I would find it more useful if the aspect ratio control (and the scale control) remain available in wide and full width as well. However, it might be a good idea to hide the entire control (aspect ratio/scale/width/height) for now and test which controls should be available at wide and full width in the future. I have no strong opinion on this, what do you think? |
I think that all controls should always be available. Setting full width would just update the control to show width is 100%, and that could be changed by updating the dimensions tool rather than unsetting the full-width in the toolbar. I don't think that solution is really achievable in the short-term, and I'd rather not build in a shortcut to a less ideal solution to these controls. Folks are going to see it as an example of what to do and the controls are going to end up with a deprecated prop. That's why I suggested just hiding the whole thing for now. Users can get their support for object-fit in full-width images in 6.4 or a future Gutenberg release. |
t-hamano
force-pushed
the
image/hide-dimensions-tool
branch
from
59eec4d to
8f72a03
Compare
t-hamano
changed the title
isResizable propDimensionsTool if it is not resizable
|
For me the aspect ratio controls were still showing, so I added another commit to hide them. This suggests things aren't working as expected though as if isResizable is false we shouldn't output anything. |
|
I have made a change based on the discussion here to hide the entire control if it cannot be resized on the Image block side, rather than adding a new I have force pushed, so sorry if I have overwritten your commit. |
ajlende
approved these changes
Aug 4, 2023
ajlende
added
the
Backport to WP Minor Release
|
Based on my comment I would really appreciate if we could set custom aspect ratio also for full and wide aligned images. I found myself using this quite often and the only workaround recently is to upload a new cropped image just for this purpose. |
tellthemachines
pushed a commit
that referenced
this pull request
Aug 14, 2023
|
I just cherry-picked this PR to the update/bugfixes-6-3-1 branch to get it included in the next release: 21af8f7 |
tellthemachines
removed
the
Backport to WP Minor Release
|
@tellthemachines So, we will not be able to set aspect ratio for full & wide aligned images? (See my comment above.) |
This sounds like a good idea. Please would you be able to create an issue for it, so it doesn't get lost. |
|
@scruffian @webmandesign I created one here. Thanks for the feedback! #53652 |
tellthemachines
pushed a commit
that referenced
this pull request
Aug 31, 2023
tellthemachines
added a commit
that referenced
this pull request
Sep 1, 2023
* Update document title buttons radius (#53221) * Fix: Sync status overlaps for some languages in Patterns post type page (#53243) * Image block: Fix stretched images constrained by max-width (#53274) * Fix dragging to resize from stretching image in the frontend * Add image block v7 deprecation * Update deprecation comment * Prevent image losing its aspect ratio at smaller window dimensions * Revert "Prevent image losing its aspect ratio at smaller window dimensions" This reverts commit 8ac9f8c. --------- Co-authored-by: scruffian <[email protected]> * Image Block: Don't render `DimensionsTool` if it is not resizable (#53181) * Fix missing Replace button in content-locked Image blocks (#53410) * Revert "don't display BlockContextualToolbar at all in contentonly locking (#53110)" This reverts commit 5efce0e. * Alternative fix to hide BlockContextualToolbar when there are no controls * fix the go to for non pages by showing it only for pages (#53408) * Site Editor: Fix document actions label helper method (#52974) * Site Editor: Fix document actions label helper method * Add missing useSelect dep * Fix e2e tests * Move the label map at the file level to avoid recreating the object on every render * Image: Clear aspect ratio when wide aligned (#53439) * RichText: Remove 'Footnotes' when interactive formatting is disabled (#53474) Introduce a new 'interactive' setting for format types * Preserve block style variations when securing theme json (#53466) * Preserve block style variations when securing theme json Valid and safe block style variations were being removed by `WP_Theme_JSON_Gutenberg::remove_insecure_properties` when securing the theme.json. When this was a problem varied depending upon site configuration, but out-of-the-box it was a problem for administrators on multi-site installs. This change adds explicit processing of variations in `remove_insecure_properties` so that they won't get removed. * Add another variation sanitisation test This test checks that when removing insecure properties an unknown/unsupported property is removed from the variation. * Site editor: add missing i18n in `HomeTemplateDetails` (#53543) * Site editor: add missing i18n in `HomeTemplateDetails` * Lint fix * Fix: Snack bar not fixed on certain pages in the Site Editor (#53207) * Fix document title alignment in command palette button (#53224) * Fallback to default max viewport if layout wide size is fluid. (#53551) * Link Control: persist advanced settings toggle state to preferences if available (#52799) * Link Control: Create a preference for whether the advanced section is open * move the useSelect to the component that uses it * Supply preference setter via settings * Pass setter to Post Editor * Provide local state fallbacks in absence of preference store settings * Conditionalise display of settings drawer to “edit” mode only * Extract to constant to improve comprehension * Fix bug in preferences resolution * Improve comments * Add e2e scaffold * Fix e2e test to correctly assert on feature * Remove focused test * Reinstate original logic to hide settings when not required * Scaffold documentation * Revert providing prefs via settings * Refactor to use `core/block-editor` as preference scope * Update docs * Reinstate remaining original conditional * tentative fix for the e2e test * Try a different syntax for shiftAlt * another attempt to fix the e2e test --------- Co-authored-by: Dave Smith <[email protected]> Co-authored-by: MaggieCabrera <[email protected]> * Add tests for fluid layout + typography (#53554) * Fix support of sticky position in non-iframed post editor (#53540) * Fix support of sticky position in non-iframed post editor * Revert "Footnotes: Fix recursion into updating attributes when attributes is not an object (#53257)" This reverts commit ab04074. * Fix: indicator style when block moving mode (#53972) * Fix post editor top toolbar with custom fields in Safari (#53688) * Set top toolbar size dynamically (#53526) * fix the top toolbar size in the space remaining after plugin items are pinned * only resize above the tablet breakpoint * fix fixed block toolbar collapse button when icon labels are shown * Update height and scroll behavior * move the layout effect to the affected component, fixes for fullscreen, no block selected, icon labels height --------- Co-authored-by: jasmussen <[email protected]> * Roll back camelCase change in 96b6b1e --------- Co-authored-by: James Koster <[email protected]> Co-authored-by: Aki Hamano <[email protected]> Co-authored-by: Alex Lende <[email protected]> Co-authored-by: scruffian <[email protected]> Co-authored-by: Robert Anderson <[email protected]> Co-authored-by: Andrei Draganescu <[email protected]> Co-authored-by: George Mamadashvili <[email protected]> Co-authored-by: Dean Sas <[email protected]> Co-authored-by: Pascal Birchler <[email protected]> Co-authored-by: Dave Smith <[email protected]> Co-authored-by: MaggieCabrera <[email protected]> Co-authored-by: Mitchell Austin <[email protected]> Co-authored-by: jasmussen <[email protected]> Co-authored-by: ramon <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related to #51545, #53173
Update: The PR initially added a new
isResizableprop toDimensionsTool, which hidDimensionsTool's Width and Height controls. However, based on this discussion, the PR was changed to not render the entireDimensionsToolif it is not resizable.What?
This PR adds a newisResizableprop to theDimensionsToolcomponent. The default value for this property istrue, and if explicitly passedfalse, the width and height controls (WidthHeightTool) will not be displayed.This PR will not render
DimensionsToolin the image block if resizing is not possible.Why?
While looking into issue #53173, I noticed that the width and height controls are showing up even when the image block is wide or full width. WordPress 6.2 used the traditional
ImageSizeControlcomponent, which hides the width and height controls when wide or full width via theisResizableprop.I think a similar prop is needed for the newI don't think theDimensionsToolcomponentDimensionsToolcomponent should be rendered if the Image block is wide or full-width because when the Image block is wide or full width, it should not be allowed to change height or width.How?
Add newisResizableprop toDimensionsToolcomponent.In the Image block, pass theThis solves the following two problems:isResizableprop to theDiemsionsToolcomponent.Add a unit testMy other concern is whether the aspect-ratio control should remain controllable when the image is wide or full width.Testing Instructions
Block Editor (Image block, Gallery block)
Width and Height controlsDimensionsTooldisappear in the block sidebar.Width and Height controlsDimensionsTooldisappearwhen.isResizableis set tofalse6558ec431b5c8aeab0f6699d87c20082.mp4
Storybook
- Launch Storybook and access the DimensionsTool component.- Confirm that the Width and Height controls disappear whenisResizableis set tofalse.