Tag: filters

The User Action : Filtering Locations With Category on the Testing : Location Categories article is not limiting output to only the specified category.

Tech Overview

The front end sends a request back to WordPress via AJAX to request a list of locations. Part of that request encodes all of the form field entries, including the category drop down selection, into a query-encoded (key/value pairs with an & delimiter) string that is send in the formData property to the backend.

The category ID is not being parsed and filtered properly.

Looking At The Data Request

Via browser developer tools and the network I/O inspector, XHR filter…

HTTP Method: POST
URL: /wp-admin/admin-ajax.php
Request Payload…

You can see the formdata property in the POST body along with the encoded form data including the cat=5 entry. This is where the requests tells the back end to limit results to those that have WordPress category ID #5 attached to the location.

Diving Into The Code

On the back end the AJAX is routed through the Store Locator Plus® base plugin via the standard WordPress hooks and filters. These are setup in the SLP_AJAX class via this add_ajax_hooks method:

    /**
     * Add our AJAX hooks.
     *
     * @uses \SLP_AJAX::slp_delete_location for the AJAX 'slp_delete_location' action
     */
    public function add_ajax_hooks() {

    	// -- priv (WP logged in) and no priv (guest) AJAX calls
        add_action( 'wp_ajax_csl_ajax_search', array( $this, 'csl_ajax_search' ) );
        add_action( 'wp_ajax_nopriv_csl_ajax_search', array( $this, 'csl_ajax_search' ) );

        add_action( 'wp_ajax_csl_ajax_onload', array( $this, 'csl_ajax_onload' ) );
        add_action( 'wp_ajax_nopriv_csl_ajax_onload', array( $this, 'csl_ajax_onload' ) );

	    // -- priv only AJAX calls (WP logged in)
	    add_action( 'wp_ajax_slp_delete_location', array( $this, 'slp_delete_location' ) );
        add_action( 'wp_ajax_slp_change_option', array( $this, 'slp_change_option' ) );
    }

Where the csl_ajax_search eventually finds its way to the find_locations method.

Debugging the find_locations method it looks like the formdata variable coming in via the superglobal $_REQUEST variable is not being set properly.

Digging Into The Malformed Variables

Looking at the call stack the form data is mishandled causing the & in the query string to be encoded as &amp, this causes wp_parse_args() to set the property name incorrect as you can see in the debugging screenshot below.

Turns out the wp_kses_post() is too aggressive with the data munging and converts & to & which then throws wp_parse_args() for a loop.

Instead we need to use esc_url_raw() to leave most URL entities intact.