Skip to content
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

Fix/column width units #26757

Merged
merged 3 commits into from
Nov 9, 2020
Merged

Fix/column width units #26757

merged 3 commits into from
Nov 9, 2020

Conversation

tellthemachines
Copy link
Contributor

Description

Fixes #26096 and #26641

#24711 introduced two issues when column width attributes switched from being defined as numbers to strings:

  • Some of the utility functions for calculating width when changing column number broke as they expected to always receive numbers;
  • Templates defining widths as numbers broke as they expected a number to always be interpreted as a percent.

This PR:

  • changes two of the utility functions to parse strings for numbers and use them as such;
  • re-introduces the previous behaviour of adding a % to the end of a column width when it is defined as a number.

To avoid breaking columns already set with fixed widths, recalculation on adding/removing columns only takes into account the existing column widths if they are defined in percent, or if they are unitless (which should be interpreted as percent for back compat reasons).

How has this been tested?

Tested in browser:

  • Add a 30/70 columns block, add a new column to it and verify new widths look as expected.
  • Add/remove columns to various blocks with explicit widths defined. Check that widths defined in px don't get changed when adding or removing columns.
  • Check that unitless widths in a custom post type template are interpreted as %.

Also added a few unit tests for the changes in the utility functions.

Screenshots

Types of changes

Bug fix (non-breaking change which fixes an issue)

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • My code has proper inline documentation.
  • I've included developer documentation if appropriate.
  • I've updated all React Native files affected by any refactorings/renamings in this PR.

@tellthemachines tellthemachines added [Block] Columns Affects the Columns Block [Type] Bug An existing feature does not function as intended labels Nov 6, 2020
@github-actions
Copy link

github-actions bot commented Nov 6, 2020

Size Change: +47 B (0%)

Total Size: 1.21 MB

Filename Size Change
build/block-library/index.js 147 kB +47 B (0%)
ℹ️ View Unchanged
Filename Size Change
build/a11y/index.js 1.14 kB 0 B
build/annotations/index.js 3.78 kB 0 B
build/api-fetch/index.js 3.45 kB 0 B
build/autop/index.js 2.84 kB 0 B
build/blob/index.js 665 B 0 B
build/block-directory/index.js 8.72 kB 0 B
build/block-directory/style-rtl.css 943 B 0 B
build/block-directory/style.css 942 B 0 B
build/block-editor/index.js 133 kB 0 B
build/block-editor/style-rtl.css 11.2 kB 0 B
build/block-editor/style.css 11.2 kB 0 B
build/block-library/editor-rtl.css 8.96 kB 0 B
build/block-library/editor.css 8.96 kB 0 B
build/block-library/style-rtl.css 8.03 kB 0 B
build/block-library/style.css 8.03 kB 0 B
build/block-library/theme-rtl.css 792 B 0 B
build/block-library/theme.css 793 B 0 B
build/block-serialization-default-parser/index.js 1.88 kB 0 B
build/block-serialization-spec-parser/index.js 3.1 kB 0 B
build/blocks/index.js 48.1 kB 0 B
build/components/index.js 172 kB 0 B
build/components/style-rtl.css 15.3 kB 0 B
build/components/style.css 15.3 kB 0 B
build/compose/index.js 9.8 kB 0 B
build/core-data/index.js 12.5 kB 0 B
build/data-controls/index.js 771 B 0 B
build/data/index.js 8.8 kB 0 B
build/date/index.js 31.8 kB 0 B
build/deprecated/index.js 769 B 0 B
build/dom-ready/index.js 571 B 0 B
build/dom/index.js 4.46 kB 0 B
build/edit-navigation/index.js 11.2 kB 0 B
build/edit-navigation/style-rtl.css 881 B 0 B
build/edit-navigation/style.css 885 B 0 B
build/edit-post/index.js 306 kB 0 B
build/edit-post/style-rtl.css 6.41 kB 0 B
build/edit-post/style.css 6.39 kB 0 B
build/edit-site/index.js 22.6 kB 0 B
build/edit-site/style-rtl.css 3.91 kB 0 B
build/edit-site/style.css 3.91 kB 0 B
build/edit-widgets/index.js 26.3 kB 0 B
build/edit-widgets/style-rtl.css 3.12 kB 0 B
build/edit-widgets/style.css 3.12 kB 0 B
build/editor/editor-styles-rtl.css 480 B 0 B
build/editor/editor-styles.css 482 B 0 B
build/editor/index.js 42.8 kB 0 B
build/editor/style-rtl.css 3.85 kB 0 B
build/editor/style.css 3.85 kB 0 B
build/element/index.js 4.65 kB 0 B
build/escape-html/index.js 735 B 0 B
build/format-library/index.js 6.63 kB 0 B
build/format-library/style-rtl.css 547 B 0 B
build/format-library/style.css 548 B 0 B
build/hooks/index.js 2.16 kB 0 B
build/html-entities/index.js 623 B 0 B
build/i18n/index.js 3.57 kB 0 B
build/is-shallow-equal/index.js 712 B 0 B
build/keyboard-shortcuts/index.js 2.52 kB 0 B
build/keycodes/index.js 1.94 kB 0 B
build/list-reusable-blocks/index.js 3.11 kB 0 B
build/list-reusable-blocks/style-rtl.css 476 B 0 B
build/list-reusable-blocks/style.css 476 B 0 B
build/media-utils/index.js 5.34 kB 0 B
build/notices/index.js 1.78 kB 0 B
build/nux/index.js 3.42 kB 0 B
build/nux/style-rtl.css 671 B 0 B
build/nux/style.css 668 B 0 B
build/plugins/index.js 2.56 kB 0 B
build/primitives/index.js 1.43 kB 0 B
build/priority-queue/index.js 791 B 0 B
build/redux-routine/index.js 2.85 kB 0 B
build/reusable-blocks/index.js 3.06 kB 0 B
build/rich-text/index.js 13.4 kB 0 B
build/server-side-render/index.js 2.77 kB 0 B
build/shortcode/index.js 1.69 kB 0 B
build/token-list/index.js 1.27 kB 0 B
build/url/index.js 4.06 kB 0 B
build/viewport/index.js 1.84 kB 0 B
build/warning/index.js 1.14 kB 0 B
build/wordcount/index.js 1.22 kB 0 B

compressed-size-action

Copy link
Contributor

@ntsekouras ntsekouras left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @tellthemachines - thanks for working on this. I tested it and seems fine! I'm not really sure about the deprecation though about what cases wants to handle..

Number.isFinite( block.attributes.width )
);
export function hasExplicitPercentColumnWidths( blocks ) {
return blocks.every( ( block ) => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you can simplify this a bit like:

const blockWidth = block.attributes.width;
return Number.isFinite(
	blockWidth.endsWith?.( '%' ) ? parseFloat( blockWidth ) : blockWidth
);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ooooh, much better, thanks!


const deprecated = [
{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not really sure about the deprecation here. For start it should have attributes or isEligible etc.. With just a save function, wouldn't it match if a Columns block was invalid for whatever reason? -cc @gziolo

Copy link
Member

@gziolo gziolo Nov 6, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would work without attributes, but as soon as they change, it might stop working. So it's safer to set them. isEligible is optional but it might be good idea if only width is important to trigger this deprecation.


const deprecated = [
{
Copy link
Member

@gziolo gziolo Nov 6, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would work without attributes, but as soon as they change, it might stop working. So it's safer to set them. isEligible is optional but it might be good idea if only width is important to trigger this deprecation.

} );

let style;
if ( width ) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible to modify the previous deprecation instead? The one that created the issue in the first place?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we have https://github.com/WordPress/gutenberg/pull/26757/files#r518737391 + #26774, then we might not need another deprecation.

@gziolo
Copy link
Member

gziolo commented Nov 6, 2020

It would be great to add some tests that verify if the originally introduced deprecation work as expected in the first place. We should also add a block fixture that is buggy to ensure it's resolved.

@gziolo
Copy link
Member

gziolo commented Nov 6, 2020

I opened #26774 that adds tests for the deprecation introduced in #24711. It also improves a bit the setup for the deprecation based on the suggestions from @ntsekouras. It would be nice to land first and rebase this PR to ensure this test still passes.

@@ -16,7 +16,10 @@ export default function save( { attributes } ) {
} );

let style;
if ( width ) {

if ( Number.isFinite( width ) ) {
Copy link
Member

@gziolo gziolo Nov 6, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

width can be undefined, so we still should keep the check, how about (I included code comment to ensure it doesn't get removed:

if ( width ) {
	// Numbers are handled for backward compatibility as they can be still provided with templates.
	style = { flexBasis: Number.isFinite( width ) ? width + '%' : width };
}

@tellthemachines
Copy link
Contributor Author

I addressed all the feedback, removed the deprecation and ran the integration tests locally; everything looks fine. Also tested with a few column blocks created on a previous branch and nothing breaks in the editor.

E2e failures don't seem related to this work; they're failing on every PR now 😩

Would be good to get this merged today though, so we can include it in Beta 4.

Copy link
Member

@aristath aristath left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍

if ( width ) {
style = { flexBasis: width };
// Numbers are handled for backward compatibility as they can be still provided with templates.
style = { flexBasis: Number.isFinite( width ) ? width + '%' : width };
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will explore it further, but seeing this PR again, I started thinking about whether new changes applied to edit are enough. Anyway, I can send a follow-up PR when I confirm it isn't necessary anymore. For now, better safe than sorry 😄

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tested it with the following diff:

diff --git a/packages/block-library/src/column/save.js b/packages/block-library/src/column/save.js
index c43edc8464..ccf1b64387 100644
--- a/packages/block-library/src/column/save.js
+++ b/packages/block-library/src/column/save.js
@@ -18,8 +18,7 @@ export default function save( { attributes } ) {
 	let style;
 
 	if ( width ) {
-		// Numbers are handled for backward compatibility as they can be still provided with templates.
-		style = { flexBasis: Number.isFinite( width ) ? width + '%' : width };
+		style = { flexBasis: width };
 	}
 
 	return (
diff --git a/packages/block-library/src/columns/variations.js b/packages/block-library/src/columns/variations.js
index 9f20699dee..6026a5f51e 100644
--- a/packages/block-library/src/columns/variations.js
+++ b/packages/block-library/src/columns/variations.js
@@ -74,8 +74,8 @@ const variations = [
 			</SVG>
 		),
 		innerBlocks: [
-			[ 'core/column', { width: '33.33%' } ],
-			[ 'core/column', { width: '66.66%' } ],
+			[ 'core/column', { width: 33.33 } ],
+			[ 'core/column', { width: 66.66 } ],
 		],
 		scope: [ 'block' ],
 	},

and it seems to work correctly. Do you think we should update codebase or do I miss some other case?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested this by adding a 30/70 columns block, and both columns are rendering with the same size. But that happens with or without your change to save.js, so looking for the issue now 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Scratch that, I was passing the template widths in as unitless strings 😅 . That's not something we'd ever expect to happen, is it?

I think it's fine to make this change, anyway!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it works properly only with numbers. I had the same issue with strings. We can always check the issue filed and previous setup before it was converted to percentages. If it worked with strings in the past, we might need another fix 😃

@gziolo gziolo added the Backport to WP 6.7 Beta/RC Pull request that needs to be backported to the WordPress major release that's currently in beta label Nov 9, 2020
Copy link
Member

@gziolo gziolo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good 🚢

Copy link
Member

@lukewalczak lukewalczak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested changes on mobile and didn't spot any breakage 🎉

@aristath aristath merged commit 0016f2d into master Nov 9, 2020
@aristath aristath deleted the fix/column-width-units branch November 9, 2020 14:05
@github-actions github-actions bot added this to the Gutenberg 9.4 milestone Nov 9, 2020
tellthemachines added a commit that referenced this pull request Nov 11, 2020
* Fix issues with different units in column widths

* Columns with fixed width should keep width on recalculation

* Address review feedback
tellthemachines added a commit that referenced this pull request Nov 12, 2020
* Cover block: Restore default overlay background (#26569)

* Restore default Cover overlay background

The default Cover block overlay background was removed. This changed the
style of existing blocks on existing sites.

Restore the default background in such a way that it does not conflict
with theme-provided background-color styles and there is no need to
artificially add extra specificity.

Fix regression: #26545

* Limit the interface skeleton to a max width of 100% to prevent some blocks managing to exceed the width (#26552)

* Cover Block: Restore opacity controls (#26625)

* Fix image block centering when resizing to a smaller size (#26376)

* Fix image block centering when resizing to a smaller size

* Revert previous 100% width fix

* Remove display: table when image block is resized to avoid centering of block

* Match frontend classes for alignment in editor

* Gallery: Remove caption fallback for alt attribute (#26676)

* Fix quote block default alignment (#26680)

* Gallery: Remove obsolete deprecation entry (#26736)

* Do not apply text color if it is being overriden (#24626)

* Fix: Preset colors don't work on button block style outline (#26707)

* Tests: Add fixture for Column deprecation (#26774)

* Fix/column width units (#26757)

* Fix issues with different units in column widths

* Columns with fixed width should keep width on recalculation

* Address review feedback

* fix undefined index notice in Social Link Block (#25663)

* fix undefined index notice

* use isset instead of array_key_exists check

* Update packages/block-library/src/social-link/index.php

Co-authored-by: Greg Ziółkowski <[email protected]>

Co-authored-by: Greg Ziółkowski <[email protected]>

* Adds in missing styling for toolbar when using text-only setting (#26769)

* Adds in missing styling for toolbar when using text-only setting

* Increases margin

* Moves style to correct file

* Inserter: Fix 'Browse All' in Quick Inserter (#26443)

* Inserter: Fix 'Browse All' in Quick Inserter

Maintain the insertion point in @wordpress/block-editor state when
moving from the Quick Inserter to the Inserter.

This fixes a bug where the insertion point is wrong after clicking a
block appender and selecting 'Browse All'.

Care is taken to not regress a previous bug where the insertion point is
wrong after clicking an inline insertion button and selecting 'Browse
ALl'.

* Inserter: Fix typo

Co-authored-by: Daniel Richards <[email protected]>

* Call getBlockInsertionPoint once

* Add useSelect dependencies

* Make setInsertionPoint unstable

* Avoid setting `isVisible` state when `SET_INSERTION_POINT` is triggered

* Make index required and clarify rootClientId usage

* Split insertionPoint into two reducers

* Fix getInsertionPoint selector that expects default state of reducer to be null

* Avoid resetting insertionPoint state on HIDE_INSERTION_POINT

Co-authored-by: Daniel Richards <[email protected]>

Co-authored-by: Jon Surrell <[email protected]>
Co-authored-by: Jacopo Tomasone <[email protected]>
Co-authored-by: Daniel Richards <[email protected]>
Co-authored-by: Bernie Reiter <[email protected]>
Co-authored-by: Greg Ziółkowski <[email protected]>
Co-authored-by: Oliver Juhas <[email protected]>
Co-authored-by: Jorge Costa <[email protected]>
Co-authored-by: Fabian Kägy <[email protected]>
Co-authored-by: Tammie Lister <[email protected]>
Co-authored-by: Robert Anderson <[email protected]>
@tellthemachines tellthemachines removed the Backport to WP 6.7 Beta/RC Pull request that needs to be backported to the WordPress major release that's currently in beta label Nov 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Columns Affects the Columns Block [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Correct column widths
5 participants