![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
#52995 closed defect (bug) (fixed)
Undefined `$post_ID` variable in `edit-form-blocks.php`
| Reported by: | ravipatel | Owned by: | SergeyBiryukov |
|---|---|---|---|
| Priority: | normal | Milestone: | 5.8 |
| Component: | Editor | Version: | 5.0 |
| Severity: | normal | Keywords: | has-patch |
| Cc: | Focuses: |
Description (last modified by )
wp_get_post_autosave is called with the $post_ID variabl, but it is not defined. Should use $post->ID instead.
Attachments (2)
Change History (11)
#1
@
5 years ago
- Component General → Editor
- Description modified (diff)
- Focuses coding-standards removed
- Summary Coding standard : Undefined varible → Undefined `$post_ID` variable in `edit-form-blocks.php`
- Version → 5.0
Looks like this traces back to [43815].
#2
@
5 years ago
Hi there!
I investigate more on this issue and found that $post_ID is not defined on the current file but it defines in their parent files.
edit-form-blocks.php has two parent files.
File post-new.php define $post_ID like below.
$post = get_default_post_to_edit( $post_type, true ); $post_ID = $post->ID;
File post.php define $post_ID like below.
if ( isset( $_GET['post'] ) && isset( $_POST['post_ID'] ) && (int) $_GET['post'] !== (int) $_POST['post_ID'] ) {
wp_die( __( 'A post ID mismatch has been detected.' ), __( 'Sorry, you are not allowed to edit this item.' ), 400 );
} elseif ( isset( $_GET['post'] ) ) {
$post_id = (int) $_GET['post'];
} elseif ( isset( $_POST['post_ID'] ) ) {
$post_id = (int) $_POST['post_ID'];
} else {
$post_id = 0;
}
$post_ID = $post_id;
FYI both the variables give the same post ID value in my test.
echo $post_ID; echo $post->ID;
#3
@
5 years ago
- Milestone Awaiting Review → 5.8
Hi there, thanks for the ticket!
As noted above, this is not an issue, as the variable is defined in the parent file before edit-form-blocks.php is included. That said, I think it makes sense to switch to $post->ID here avoid any future confusion.
Note: This also applies to a similar fragment and a few other instances in edit-form-advanced.php.
#5
follow-up:
↓ 6
@
5 years ago
I believe this caused an unintended change, $post->ID can be a string in some cases, and it's used in strict comparison with an int here: https://github.com/WordPress/wordpress-develop/blob/c00ba50d598abb1cd8aaba057da9555a452ffcee/src/wp-admin/edit-form-advanced.php#L81.
This prevents the notice from showing when editing the posts page (https://github.com/WordPress/wordpress-develop/blob/c00ba50d598abb1cd8aaba057da9555a452ffcee/src/wp-admin/includes/template.php#L2668).
#6
in reply to: ↑ 5
@
5 years ago
- Resolution fixed
- Status closed → reopened
Replying to grantmkin:
I believe this caused an unintended change,
$post->IDcan be a string in some cases
Thanks for flagging that! I was able to reproduce the issue and am looking into it.
#7
@
5 years ago
- Keywords commit added
It looks like the issue comes from this line in wp-admin/post.php:
$post = get_post( $post_id, OBJECT, 'edit' );
The ID, post_parent, and menu_order properties of the WP_Post class are documented as integers, so I thought it would be a safe assumption to always treat them as such. However, that is not the case when get_post() is called with an edit, attribute, or js context, because all values are run through esc_attr() or esc_js() in that case, and these properties are unexpectedly converted to strings.
I believe we should fix that and make the type of these properties consistent in all contexts, that should also help avoid similar issues elsewhere in the future. See 52995.diff.
undefine variable