WordPress.org

Make WordPress Core

Opened 3 weeks ago

Closed 2 weeks ago

Last modified 2 hours ago

#51461 closed enhancement (fixed)

Update WordPress packages

Reported by: isabel_brison Owned by: jorgefilipecosta
Milestone: 5.6 Priority: normal
Severity: normal Version:
Component: Editor Keywords: 2nd-opinion has-patch
Focuses: Cc:

Description

@wordpress npm packages need updating prior to 5.6 Beta 1. This ticket tracks the first round of updates. There will be a second round after the release of Gutenberg 9.2, just before 5.6 Beta 1.

Change History (13)

This ticket was mentioned in PR #573 on WordPress/wordpress-develop by tellthemachines.


3 weeks ago

  • Keywords has-patch added

Update @wordpress npm packages that don't require associated PHP changes. Subsequent PRs will deal with the remaining packages.

Trac ticket: https://core.trac.wordpress.org/ticket/51461

This ticket was mentioned in PR #579 on WordPress/wordpress-develop by tellthemachines.


3 weeks ago

Updates block-library package and all related php and json files.

Trac ticket: https://core.trac.wordpress.org/ticket/51461

#4 @jorgefilipecosta
2 weeks ago

  • Owner set to jorgefilipecosta
  • Resolution set to fixed
  • Status changed from new to closed

In 49135:

Editor: update packages; Port block supports to WordPress core.

The following package versions were changed:
@wordpress/a11y: 2.11.0 -> 2.13.0
@wordpress/annotations: 1.20.4 -> 1.22.0
@wordpress/api-fetch: 3.18.0 -> 3.20.0
@wordpress/autop: 2.9.0 -> 2.10.0
@wordpress/blob: 2.9.0 -> 2.10.0
@wordpress/block-directory: 1.13.7 -> 1.16.0
@wordpress/block-editor: 4.3.7 -> 5.0.0
@wordpress/block-library: 2.22.7 -> 2.25.0
@wordpress/block-serialization-default-parser: 3.7.0 -> 3.8.0
@wordpress/blocks: 6.20.3 -> 6.23.0
@wordpress/components: 10.0.6 -> 11.0.0
@wordpress/compose: 3.19.3 -> 3.21.0
@wordpress/core-data: 2.20.3 -> 2.23.0
@wordpress/data: 4.22.3 -> 4.24.0
@wordpress/data-controls: 1.16.3 -> 1.18.0
@wordpress/date: 3.10.0 -> 3.12.0
@wordpress/deprecated: 2.9.0 -> 2.10.0
@wordpress/dom: 2.13.1 -> 2.15.0
@wordpress/dom-ready: 2.10.0 -> 2.11.0
@wordpress/e2e-test-utils: 4.11.2 -> 4.14.0
@wordpress/edit-post: 3.21.7 -> 3.24.0
@wordpress/editor: 9.20.7 -> 9.23.0
@wordpress/element: 2.16.0 -> 2.18.0
@wordpress/escape-html: 1.9.0 -> 1.10.0
@wordpress/format-library: 1.22.7 -> 1.24.0
@wordpress/hooks: 2.9.0 -> 2.10.0
@wordpress/html-entities: 2.8.0 -> 2.9.0
@wordpress/i18n: 3.14.0 -> 3.16.0
@wordpress/icons: 2.4.0 -> 2.7.0
@wordpress/is-shallow-equal: 2.1.0 -> 2.3.0
@wordpress/keyboard-shortcuts: 1.9.3 -> 1.11.0
@wordpress/keycodes: 2.14.0 -> 2.16.0
@wordpress/library-export-default-webpack-plugin: 1.7.0 -> 1.9.0
@wordpress/list-reusable-blocks: 1.21.6 -> 1.23.0
@wordpress/media-utils: 1.15.0 -> 1.17.0
@wordpress/notices: 2.8.3 -> 2.10.0
@wordpress/nux: 3.20.6 -> 3.22.0
@wordpress/plugins: 2.20.3 -> 2.22.0
@wordpress/primitives: 1.7.0 -> 1.9.0
@wordpress/priority-queue: 1.7.0 -> 1.9.0
@wordpress/redux-routine: 3.10.0 -> 3.12.0
@wordpress/rich-text: 3.20.4 -> 3.22.0
@wordpress/scripts: 12.1.1 -> 12.3.0
@wordpress/server-side-render: 1.16.6 -> 1.18.0
@wordpress/shortcode: 2.9.0 -> 2.11.0
@wordpress/token-list: 1.11.0 -> 1.13.0
@wordpress/url: 2.17.0 -> 2.19.0
@wordpress/viewport: 2.21.3 -> 2.23.0
@wordpress/warning: 1.2.0 -> 1.3.0
@wordpress/wordcount: 2.10.0 -> 2.12.0

Props isabel_brison, youknowriad, mcsf.
Fixes #51461.

#5 @prbot
2 weeks ago

jorgefilipecosta commented on PR #585:

@mcsf your feedback was applied.

#6 follow-up: @ocean90
2 weeks ago

  • Keywords needs-patch 2nd-opinion added; has-patch removed
  • Resolution fixed deleted
  • Status changed from closed to reopened

Is there a reason why an array.php file was introduced for just one function? I think the function should be moved into wp-includes/functions.php instead.

#7 in reply to: ↑ 6 @SergeyBiryukov
2 weeks ago

Replying to ocean90:

Is there a reason why an array.php file was introduced for just one function? I think the function should be moved into wp-includes/functions.php instead.

Yes, I had the same thought here. We already have a couple of array functions in wp-includes/functions.php:

  • wp_array_slice_assoc()
  • wp_is_numeric_array()

It makes sense to move wp_array_get() there as well.

This ticket was mentioned in PR #597 on WordPress/wordpress-develop by tellthemachines.


2 weeks ago

  • Keywords has-patch added; needs-patch removed

Addresses feedback on recent package update. Cc @ocean90 @SergeyBiryukov @jorgefilipecosta

Trac ticket: https://core.trac.wordpress.org/ticket/51461

#9 @SergeyBiryukov
2 weeks ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 49143:

General: Move wp_array_get() from a separate file to wp-includes/functions.php, for consistency.

Add missing @since tag, adjust the DocBlock per the documentation standards.

Follow-up to [49135].

Props isabel_brison, ocean90.
Fixes #51461.

#10 @SergeyBiryukov
2 weeks ago

In 49144:

General: Move wp_array_get() next to wp_array_slice_assoc(), for a bit more consistent placement.

Follow-up to [49135], [49143].

See #51461.

#11 @dd32
2 weeks ago

Just wanted to note that the new wp_array_get() function seems.. weird, and I'm not entirely sure it's worth treating as a publicly available function, perhaps it should be marked internal-use? or skipped entirely?

In all cases, it's being used without making use of it's sub-array functionality, mostly replacing code similar to this:

isset( $block->supports['field'] ) ? $block->supports['field'] : false

In a PHP7+ world, wp_array_get( $block->supports, array( 'field' ), false ) could be replaced with $block->supports['field'] ?? false (which seems far easier to read than this function, same as the isset() is easier to understand)

There's also an edge oddity around null values (that while not used in core, might present in others usage of it) such that wp_array_get( [ 'key' => null ], [ 'key' ], true ) returns true as the key isn't considered set in the input. Perhaps that would be thought of as expected behaviour.

edit: had to add array syntax around the $path var param in examples which I missed.

Last edited 2 weeks ago by dd32 (previous) (diff)

#12 @iandunn
2 weeks ago

I had the same thought when I saw it. It doesn't seems to follow the guideline about clever code.

I'd personally suggest removing it, and writing simple, descriptive isset() statements like in Dion's example.

Last edited 2 weeks ago by iandunn (previous) (diff)

#13 @jorgefilipecosta
2 hours ago

Hi @dd32, @iandunn,

The function wp_array_get got introduced to be an equivalent of JavaScript lodash get https://lodash.com/docs/4.17.15#get.

The lodash get is very used on Gutenberg client-side and we have functions that need to work on both the client and the server. So in order for the code to be an almost direct translation of JavaScript to PHP, it seemed good to introduce an equivalent function in PHP.

The usages we have now in fact could easily be implemented using an alternative approach and they don't use the subarray functionality where the power of this function relies on.
But soon we will have in core code where the function with subarray functionality is needed https://github.com/WordPress/gutenberg/blob/ba5cecc8c82665ee7d89e36457e7d47de5d81131/lib/global-styles.php#L689 where even the path is not static but a variable itself.

I like the idea of marking the function as internal-use at least for now until the function proves useful in some cases.

Is there any guide on how to mark a function as internal-use?

Note: See TracTickets for help on using tickets.