Custom post template page

I moved your topic to the Hacks forum, it’s the best place for custom coding questions.

Consider changing your form’s method to “post”. Then you can conditionally only run the query/results part of your template when the request method is “POST”. If it’s “GET” just output the form. Also, the URL is cleaner because it doesn’t have data tacked on to the end.

if ('GET' == $_SERVER['REQUEST_METHOD']) \\do the form
    else \\do the query

The form’s action attribute needs to be the page’s permalink.
action="<?php the_permalink(); ?>"

Assuming you use the POST method, you can get the selected values from $_POST[‘Types’] and $_POST[‘Year’]. If you want to stay with GET, then use $_GET instead.

You need quotes around field names in $_POST: $_POST['Types']
At this point they are associative array keys, so use the same syntax. Note that the contained value from WP dropdown fields is the taxonomy term ID. In general, the ID is easiest to use in code anyway, but it means little to us humans.

$_POST['Types'] is a PHP variable like any other, so you can use it, save it or output it like any other variable. To show the selected dropdown item as the one last selected, in the POST version (the second, “else” version) replace $type_IDs[0] with $_POST['Types']

You can output it (or display it, same thing) like any other variable:
echo "Types term ID: $_POST['Types']</br>\n";

You can use it in a WP_Query argument array like any other variable:

$query_args = array(
   'post_type' => 'mycustompost',
   'tax_query' => array(
      array(
         'taxonomy' => 'types',
         'field'    => 'term_id',
         'terms'    => $_POST['Types'],
      ),
   ),
);

If you want to reverse the logic of ‘GET’ == $_SERVER[‘REQUEST_METHOD’], you can use either of the following (then you don’t need {} else ):
'GET' != $_SERVER['REQUEST_METHOD']
'POST' == $_SERVER['REQUEST_METHOD']

The purpose of a nonce field is to ensure the POST request is coming from your form and not some hacker’s hijacked computer. This is essential when you are saving input to the DB or when the data needs to come from a trusted user. If the data is only used to form a query, it’s not absolutely required, but might still be desirable to help prevent someone from scraping data from your site or similar abuses. Of course you need to verify the nonce value before doing anything for this measure to be effective.

If you are getting the option index in $_POST[‘Types’], that would explain what’s not working. I was assuming it contained the taxonomy term ID. The “terms” query argument needs to be the term ID. If you are getting an index, it needs to be translated to a term ID. Ideally, the dropdown options should have the ID assigned as the value, which is then sent as the selected value. At least that is how it works on my site with wp_dropdown_categories().

Are you sure they are index numbers? The following is one option from my site’s category dropdown, called with all defaults, no arguments:
<option class="level-0" value="69">Important</option>

The category term ID is 69, the value sent with the form submit. For comparison, an easy way to determine the term ID of your categories is go to the taxonomy term edit page and hover your cursor over the “View” action link. Examine the URL for this link, it will have an URL parameter “tag_ID=” followed by the ID for that term.

Oh so close!
It took me a while to spot this one. Tax queries need to be an array of arrays. This allows for very complex tax queries. When there is only one tax query argument this requirement does not make a lot of sense, so it’s easy to forget to include the extra array. The outer array is always required no matter what.

'tax_query' => array( array(
	'taxonomy' => 'Types',
	'field'    => 'term_id',
	'terms'    => $_POST['Types'],
),),

There is one other small issue. On the initial page load, the GET request, we get a PHP warning that $query_args is not defined on the new WP_Query line. The generic, unrestricted query is never assigned for GET requests, only for POST requests when a Type selection is not made. There’s all sorts of ways to correct this. One possibility is to combine the POST check and not -1 check into one conditional so the else condition would apply to GET requests.
if('POST' == $_SERVER['REQUEST_METHOD'] && $_POST['Types'] != -1 ) //do a tax query

Yes, that’s a good plan. You just need to accommodate the situation when there is no $_POST data at all, as with the initial GET request before any tax filters are submitted. If you define WP_DEBUG as true in wp-config.php, you’ll see when PHP is complaining about such things. Put it back to false after you’re done testing, debug errors exposed on a production site are not good.

Understood. All I’m saying is the code you last posted throws a PHP warning with a GET request, so there is a technical gap in your logic flow. If you don’t mind PHP warnings in your code, then that’s fine, everything works as it should with warnings in this case.

I imagine you’ve moved on from that code version by now, so maybe all is fine now either way. If you’re happy I’m happy 🙂

OK, good, as long as the code we’re working on isn’t throwing warnings.

The redefined constant doesn’t really hurt anything other than your error logs could fill up with the same warning over and over. I’d suggest you get rid of one definition or the other, but it’s not required for everything to work.