#48303 closed task (blessed) (fixed)
Docblock improvements for 5.4
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| Milestone: | 5.4 | Priority: | normal |
| Severity: | normal | Version: | |
| Component: | General | Keywords: | |
| Focuses: | docs | Cc: |
Attachments (6)
Change History (112)
#2
@
5 months ago
wp_enqueue_script, wp_enqueue_style, wp_register_script and wp_register_style parameter $deps could be narrowed from array to string[].
#3
@
5 months ago
wp_unslash parameter and return value could be narrowed from string|array to string|string[].
This ticket was mentioned in Slack in #docs by atachibana. View the logs.
5 months ago
@
5 months ago
Docs: Moved the @link tag for Customize API in WP_Customize_Manager::add_setting() and WP_Customize_Setting
#33
in reply to:
↑ 26
;
follow-up:
↓ 34
@
5 months ago
Replying to Marcio Zebedeu:
Can you please confirm? I had my doubts about naming patch.
Thanks for the patches! However, [46647] and [46691] are changesets, not tasks. These are changes that are already committed and generally don't require additional patches, unless you notice a typo or any other inaccuracy :)
#34
in reply to:
↑ 33
@
5 months ago
Replying to SergeyBiryukov:
Replying to Marcio Zebedeu:
Can you please confirm? I had my doubts about naming patch.
Thanks for the patches! However, [46647] and [46691] are changesets, not tasks. These are changes that are already committed and generally don't require additional patches, unless you notice a typo or any other inaccuracy :)
Oh...thank. I'm still learning :)
#71
@
2 months ago
Hi, I started by looking at the function get_the_post_thumbnail and its parameter $size, which is currently of the type string|array. I think this could be narrowed down to string|int[] by examining its source and all the functions and hooks it calls. As such, I think these functions and hooks could have their parameter $size narrowed in the same way. The ones I encountered:
Functions:
get_the_post_thumbnailwp_get_attachment_imagewp_get_attachment_image_srcimage_downsizeimage_get_intermediate_sizeimage_constrain_size_for_editor
Hooks:
begin_fetch_post_thumbnail_htmlend_fetch_post_thumbnail_htmlwp_get_attachment_image_srcimage_downsizeimage_get_intermediate_sizeeditor_max_image_size
However, I'm pretty sure there are more.
#74
@
2 months ago
Hi, OK, thanks.
6 more functions that can have parameters narrowed:
is_pagecan have parameter narrowed toint|string|int[]|string[]is_singlecan have parameter narrowed toint|string|int[]|string[]is_singularcan have parameter narrowed tostring|string[]WP_Query::is_pagecan have parameter narrowed toint|string|int[]|string[]WP_Query::is_singlecan have parameter narrowed toint|string|int[]|string[]WP_Query::is_singularcan have parameter narrowed tostring|string[]
Partially covered by #48354
#97
in reply to:
↑ 89
@
4 weeks ago
Replying to johnbillion:
In 47394:
@johnbillion I can't seem to figure out when the first parameter of the image_downsize filter can be an array. The filter is used in two places, and both pass false as the first parameter. Was the change to bool|array intentional?
wp_image_resize_identical_dimensions uses a similar approach, and the first parameter is still documented as bool there.
#98
follow-up:
↓ 99
@
4 weeks ago
@SergeyBiryukov It can be an array if another filter is filtering the value and returning an array intended as the short-circuited return value.
Good point though - Core is not consistent in documenting the types for these short-circuit filter parameters. Worth a separate ticket?
#99
in reply to:
↑ 98
@
3 weeks ago
- Resolution set to fixed
- Status changed from new to closed
Replying to johnbillion:
It can be an array if another filter is filtering the value and returning an array intended as the short-circuited return value.
Indeed, thanks! That could be clarified in the description though.
Good point though - Core is not consistent in documenting the types for these short-circuit filter parameters. Worth a separate ticket?
Probably :) With 5.4 RC1 approaching, let's close this one as fixed.
#101
follow-up:
↓ 103
@
11 days ago
@SergeyBiryukov Just saw the changes here and I'm getting static analysis warnings for code like:
<?php wp_scripts()->add_data( $handle, 'foo_script_attributes', [ 'async' => true, ] );
This change to WP_Dependencies::add_data() in r47170 appears to not be correct:
- * @param mixed $value The data value. + * @param string $value The data value.
It has a mismatch with wp_script_add_data() which still indicates the type of $value as being mixed.
#103
in reply to:
↑ 101
;
follow-up:
↓ 106
@
3 days ago
Replying to westonruter:
This change to
WP_Dependencies::add_data()in r47170 appears to not be correct:
- * @param mixed $value The data value. + * @param string $value The data value.It has a mismatch with
wp_script_add_data()which still indicates the type of$valueas beingmixed.
Thanks for catching that! I guess I was confused by the fact that while the parameter indeed has a mixed type, it's described as a string in several places:
- "Extra item data (string)" in
WP_Dependencies::get_data(). - "String containing the data to be added" in
wp_script_add_data(). - "String containing the CSS data to be added" in
wp_style_add_data().
Let's revert that change for now and clean up the inconsistencies later.
#105
@
3 days ago
- Owner set to SergeyBiryukov
- Resolution set to fixed
- Status changed from reopened to closed
In 47503:
#106
in reply to:
↑ 103
@
3 days ago
Replying to SergeyBiryukov:
Let's revert that change for now and clean up the inconsistencies later.
Left a comment on #49572 as a follow-up: comment:4:ticket:49572.
I didn't know about this tracking ticket for all the small docs issues, so I created a lot of small ones (sorry...)