Navigation Link, Navigation Submenu: Fix undefined key warning #69951
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 If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @Maikuolan! In case you missed it, we'd love to have you join us in our Slack community. If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information. |
There was a problem hiding this comment.
Thanks for the PR!
AFAIK, there is no way to empty url attribute from the UI, but we can remove the attribute from the block via the code editor, which causes the issue reported.
This PR makes sense to me, but do you mind updating the Navigation Link block as well?
Done. :-) |
|
Thanks for the update! Sorry, I found the more ideal logic. The current PR executes For better performance, I'd suggest the following logic: if ( is_post_type_archive() && ! empty( $attributes['url'] ) ) {
$queried_archive_link = get_post_type_archive_link( get_queried_object()->name );
if ( $attributes['url'] === $queried_archive_link ) {
$is_active = true;
}
} |
|
Good catch. :-) Editing now. |
|
Done. :-) |
…ress#69951) * Fix undefined key warning. * Fix undefined key warning. * Use better logic. Co-authored-by: Maikuolan <maikuolan@git.wordpress.org> Co-authored-by: t-hamano <wildworks@git.wordpress.org>
What?
This pull request attempts to fix an undefined key warning.
Why?
At a few WordPress websites I manage, I've been regularly seeing these kinds of errors generated for a while now:
Seeing as the solution seems simple enough and hasn't yet been implemented, I decided to try submitting a pull request here to address it (which, if accepted, I assume will eventually find its way upstream and into some future WordPress update at some point in the future).
Although I'm not entirely sure of the exact state and circumstances of the implementation at the time when the error occurs (i.e., the elements available to
$attributes, as populated at the points where the function is called/invoked), a simpleisset()check feels the most simple, direct, and logical solution for the problem. At most other points in the affected function where an element of$attributesis used, its use is similarly preceded by anisset()check; the exception which this pull request addresses is one of the very few exceptions. This pull request brings that exception into line with the various other points of use which are preceded byisset().How?
Uses
isset()to check the existence of the key before attempting to compare it.