#44052 closed defect (bug) (fixed)
Missing parameter type for `login_header()`
Reported by: | desrosj | Owned by: | SergeyBiryukov |
---|---|---|---|
Milestone: | 4.9.8 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Login and Registration | Keywords: | good-first-bug has-patch |
Focuses: | docs | Cc: |
Description
The login_header()
function's third parameter is optional and accepts a WP_Error
instance. The default value, though is a string, which is missing from the inline documentation.
To prevent someone from passing a string (which would not be added to a new WP_Error
), if ( empty( $wp_error ) ) {}
could be changed to if ( ! is_wp_error( $wp_error ) ) {}
.
Attachments (9)
Change History (26)
#4
@
7 years ago
- Keywords needs-patch added; has-patch removed
- Milestone changed from 4.9.8 to 4.9.7
I think it makes more sense to leave the third parameter as a WP_Error
only, but set its default value to null
, which is the expected default value for optional object parameters. Since we create a new WP_Error
if none is passed, we could adjust the documentation as follows: "Optional. The error to pass. Default is a new empty error."
#6
@
7 years ago
@sebastien@…
Thanks for the updated patch! A few remarks:
- The documentation for the parameter should continue to only state
WP_Error
as type. Also its description should be changed to use "Optional. The error to pass. Default is a new empty error." - Please remove line 41, as it introduces a parse error.
- Please avoid unnecessary blank lines like in lines 46 and 47.
- It seems your patch is not based on current trunk. Please ensure you create the diff file against the entirety and latest version of trunk.
#8
@
6 years ago
Hello, I'm coming from WCEU!
All seems good to me. Code looks good, docs updated, tests written.
I don't think that there's anything I can do on this ticket. :)
#10
@
6 years ago
- Keywords needs-refresh added; 2nd-opinion removed
None of the patches so far seem like a complete solution. The two main items here we should change to fix the original described problem:
- The default for
$wp_error
should be changed tonull
to properly reflect the functions documentation. The@param
tag description should also be changed to "Optional. The error to pass. Default is a new empty error." - The
if ( empty( $wp_error ) )
conditional should be changed to check! is_wp_error( $wp_error )
to ensure any passed value other than an instance ofWP_Error
is turned into one.
#11
@
6 years ago
- Milestone changed from 4.9.7 to 4.9.8
4.9.7 has been released, moving to next milestone.
#12
@
6 years ago
I have added refreshed patch 44052.6.diff
Thanks for the patch, @sebastien@….
The functions inline documentation also needs to be updated to indicate the
$wp_error
parameter could also be a string.