Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 11 months ago

#51461 closed enhancement (fixed)

Update WordPress packages

Reported by: isabel_brison's profile isabel_brison Owned by: jorgefilipecosta's profile 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 (17)

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


4 years ago
#1

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


4 years ago
#2

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

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

#4 @jorgefilipecosta
4 years 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.

jorgefilipecosta commented on PR #585:


4 years ago
#5

@mcsf your feedback was applied.

#6 follow-up: @ocean90
4 years 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
4 years 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.


4 years ago
#8

  • 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
4 years 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
4 years 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
4 years 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 4 years ago by dd32 (previous) (diff)

#12 @iandunn
4 years 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 4 years ago by iandunn (previous) (diff)

#13 @jorgefilipecosta
4 years 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?

This ticket was mentioned in PR #692 on WordPress/wordpress-develop by jorgefilipecosta.


4 years ago
#14

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

#16 @SergeyBiryukov
4 years ago

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.

#17 @SergeyBiryukov
4 years ago

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.

Note: See TracTickets for help on using tickets.