-
Notifications
You must be signed in to change notification settings - Fork 3.2k
Theme_JSON_Resolver: add defensive coding against null result #10648
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Theme_JSON_Resolver: add defensive coding against null result #10648
Conversation
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Core Committers: Use this line as a base for the props when committing in SVN: To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Test using WordPress PlaygroundThe changes in this pull request can previewed and tested using a WordPress Playground instance. WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser. Some things to be aware of
For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation. |
westonruter
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's better to be explicit that it's a WP_Post.
Good point, agreed. |
Co-authored-by: Weston Ruter <westonruter@gmail.com>
Co-authored-by: Weston Ruter <westonruter@gmail.com>
Trac ticket: https://core.trac.wordpress.org/ticket/64434
Backports WordPress/gutenberg#74124
What?
This PR adds defensive checks to prevent some errors we've seen in hosts.
In certain scenarios, get_post function returns null after the wp_insert_post function is called. Although the post is saved, it's assumed that it can be immediately accessed, which is not always true.
Why?
See WordPress/gutenberg#70161
How?
Check if it's an object before passing it to
get_object_vars.How to reproduce
Unfortunately, there's no steps to reproduce it consistently. We've just seen reports by hosts that this happens occassionally in certain transition states for the site (creation, migration, etc.).