Skip to content
This repository has been archived by the owner on May 1, 2024. It is now read-only.

Use core WP's query var allow-list #131

Merged
merged 2 commits into from
Apr 10, 2020

Conversation

jameswburke
Copy link
Contributor

@jameswburke jameswburke commented Apr 9, 2020

Filter the component request parameters using core's allow-list.

Copy link
Contributor

@pattiereaves pattiereaves left a 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 )
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh that is clever

Copy link
Contributor

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.

Copy link
Contributor

@joemcgill joemcgill left a 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 )
Copy link
Contributor

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
Copy link
Contributor

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?

Copy link
Contributor Author

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.

@jameswburke jameswburke merged commit c203009 into master Apr 10, 2020
@jameswburke jameswburke deleted the bug/IRV-307/fix-query-var-logic branch April 10, 2020 19:07
@jameswburke
Copy link
Contributor Author

We'll continue this discussion in #132

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants