-
Notifications
You must be signed in to change notification settings - Fork 6
Conversation
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.
🦄
// global $wp object's $public_query_vars array. | ||
$this->params = array_intersect_key( | ||
$request->get_params(), | ||
array_flip( $wp->public_query_vars ) |
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.
oh that is clever
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.
Here's the full list of where WP adds public query vars:
https://github.com/WordPress/wordpress-develop/blob/master/src/wp-includes/class-wp.php#L9-L17
Are we sure we want/need to support all of these explicitly? Many of them should be handled by the route parsing on the WP side, I would think.
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.
This is definitely an improvement, but I'm wondering if we need to be more specific about which parameters are supported in the API by default?
// global $wp object's $public_query_vars array. | ||
$this->params = array_intersect_key( | ||
$request->get_params(), | ||
array_flip( $wp->public_query_vars ) |
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.
Here's the full list of where WP adds public query vars:
https://github.com/WordPress/wordpress-develop/blob/master/src/wp-includes/class-wp.php#L9-L17
Are we sure we want/need to support all of these explicitly? Many of them should be handled by the route parsing on the WP side, I would think.
@@ -366,7 +375,7 @@ public function build_query() { | |||
$wp_query = apply_filters( 'wp_irving_components_wp_query', $wp_query, $this->path, $this->custom_params, $this->params ); | |||
|
|||
// Map to main query and set up globals. | |||
// phpcs:ignore WordPress.WP.GlobalVariablesOverride.Prohibited | |||
// phpcs:ignore WordPress.WP.GlobalVariablesOverride.Prohibited, WordPress.WP.GlobalVariablesOverride.OverrideProhibited |
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.
Did the sniff rule change, or do we really need to be ignoring both here?
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'm not sure I know enough about each of those vars to make an educated decision on whether or not they should be present. I do believe we should be mimicking WordPress core as much as possible though.
One of those phpcs rules hits me locally, one hits me on Travis, so I included both for the sake of it right now.
We'll continue this discussion in #132 |
Filter the component request parameters using core's allow-list.