Opened 10 months ago
Closed 10 months ago
#64251 closed defect (bug) (fixed)
Documentation for `add_meta_boxes` hook is incorrect
| Reported by: | opr18 | Owned by: | westonruter |
|---|---|---|---|
| Priority: | normal | Milestone: | 7.0 |
| Component: | Administration | Version: | |
| Severity: | normal | Keywords: | has-patch |
| Cc: | Focuses: | docs |
Description
Related ticket: https://core.trac.wordpress.org/ticket/43229 that seems was solved a while ago, but has since changed back.
[The documentation for this hook](https://core.trac.wordpress.org/browser/tags/6.8.3/src/wp-admin/includes/meta-boxes.php#L1714) states that $post will be a WP_Post however in these locations it is not
- https://core.trac.wordpress.org/browser/tags/6.8.3/src/wp-admin/edit-link-form.php#L37
- https://core.trac.wordpress.org/browser/tags/6.8.3/src/wp-admin/edit-form-comment.php#L257
- https://core.trac.wordpress.org/browser/tags/6.8.3/src/wp-admin/includes/meta-boxes.php#L1683
I think some possible resolutions here would be:
- Update the docs to loosen the type of the second param being passed to the hook
- Fix instances where the second param to the hook is not a
WP_Post
Change History (8)
#2
@
10 months ago
- Summary Documentation for `add_meta_boxes hook` is incorrect → Documentation for `add_meta_boxes` hook is incorrect
#3
@
10 months ago
- Component Options, Meta APIs → Administration
- Focuses docs added
- Milestone Awaiting Review → 7.0
Update the docs to loosen the type of the second param being passed to the hook
This makes sense to me.
This ticket was mentioned in PR #10527 on WordPress/wordpress-develop by @opr18.
10 months ago
#4
- Keywords has-patch added
This patch updates the documentation for the add_meta_boxes_{$post_type} and add_meta_boxes hooks to correctly reflect that $post will not always be a WP_Post object.
Trac ticket: https://core.trac.wordpress.org/ticket/64251
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
The hook is too old and too widely used to be refactored without breaking plugins, so explicitly documenting:
we can add the one line so User might not confuse.
@param WP_Post | WP_Comment | stdClass $post
do_action( 'edit_form_after_title', $post, $title ) this hooks used in several admin screens it is fired with non-WP_Post types, for example:
Link editor -> passes a stdClass (legacy Link Manager structure)
Comment editor-> passes a WP_Comment
Some meta-box contexts -> might pass null or an incomplete object depending on screen
so @opr18 is right the docs expect $post to always be a WP_Post, which isn’t true. This creates fragile code, silent failures, type-hinting conflicts, confusion for people reading core docs.