Update WordPress packages

[isabel_brison]

@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.

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

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

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

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

[jorgefilipecosta]

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.

@mcsf your feedback was applied.

[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.

[SergeyBiryukov]

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.

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

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

[SergeyBiryukov]

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.

[SergeyBiryukov]

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.

[dd32]

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.

[iandunn]

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.

[jorgefilipecosta]

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?

According to feedback received at https://core.trac.wordpress.org/ticket/51461. This PR contains makes wp_array_get internal.
After more core code uses it we can decide if the function is valuable and something we want to expose or not.

Trac ticket: core.trac.wordpress.org/ticket/51720

[SergeyBiryukov]

Follow-up: #51720

[SergeyBiryukov]

In 50964:

Tests: Add missing tests for the _wp_array_get() function.

Follow-up to [49143], [49144], [49580].

Props jorgefilipecosta, johnbillion.
See #51461, #51720, #52625.

[SergeyBiryukov]

In 50970:

Tests: Remove trailing commas in function calls in _wp_array_get() tests.

This fixes parse errors on PHP 7.2 and lower versions.

Follow-up to [49143], [49144], [49580], [50964].

See #51461, #51720, #52625.