Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

So, I'm using a custom post type archive and generating a JavaScript-based filtering interface for sorting through results.

Here's an example: http://www.inverity.org/sermons/

Now, what I'd like to do is pass in variables to my script to allow for filtering based on URL parameters.

This works: http://www.inverity.org/sermons/?presenters=4

The problem is, this doesn't: http://www.inverity.org/sermons/?speakers=4

"speakers" is the name of the custom taxonomy I'm using and is the value that I want to filter by.

Any ideas why this is happening? Is there anything I can do to get around it and prevent the 404ing?

share|improve this question
2  
this is difficult to answer with the information provided. what does the code look like that does the filtering? I suggest inspecting the global $wp_query to see the query being generated. –  Milo Mar 18 '13 at 18:33
    
Thanks for the feedback, Milo. I will take a look and report back after investigating further. –  Jonathan Wold Mar 19 '13 at 20:35
1  
In what way does inverity.org/sermons/?presenters=4 work? Whatever the number at the end, the results are the same. –  vancoder Mar 19 '13 at 22:41
    
@vancoder It works in the sense that the parameter hits the page, is passed in, and could be used in the filtering process (it's not being used, so the results don't change). What I want is for the "speakers" parameter to work without giving me a 404. –  Jonathan Wold Mar 21 '13 at 4:53
    
I think we'd need to see some code. –  vancoder Mar 21 '13 at 19:20
show 1 more comment

2 Answers 2

up vote 3 down vote accepted
+50

I had the same problem on my large project that I currently work on. It's case when you have collision between taxonomy and post-type slugs. Problem is that you can filter by taxonomy with adding ?taxonomy_name=term_slug and also you can see the custom post by adding ?post_type=custom_post_slug. So, that's the same syntax, and WP doesn't know do you want "term archive" or "single custom post".

The only, and the right way (in my opinion) to solve this is to change either taxonomy-slug or post_type-slug (probably, it's easier to fix and handle side-effects of renaming the taxonomy, I guess).

2nd solution

Also, I found one EXACT solution, you can find the details here. In the other words, you can set for your register_taxonomy() argument $args['query_var'] = false with which you disable query parameter speakers to act as taxonomy slug. Therefore, if you want to filter by taxonomy terms directly in URL / $_GET var, you will have to do some other magic. But, at least, you will remove collision between post_type and taxonomy names.

Optionally, you will have to flush_rewrite_rules after that in whatever way you want:

  1. Add flush_rewrite_rules(); in functions.php, go to the site, refresh it several times, remove that line and save functions.php again.
  2. Go to Wordpress admin -> Options -> Permalink and click save.

I usually do both of it. Just in case.

3rd solution

Hook custom function to pre_get_posts(). With this method, you have to be careful in which case you will edit the query args. Put this in the functions.php.

function preQueryAction( $query ) {

    // classic approach to avoid messing queries in Admin and custom queries.
    if(is_admin() or !$query->is_main_query()) return; 

    // selectively filter only if you are on CPT arhive
    if(is_post_type_archive()){
        $query->set( 'speakers', false );
    }

    return;

}


add_action( 'pre_get_posts', 'preQueryAction', 1 );
share|improve this answer
    
Thank you for the feedback! I had forgotten about disabling query_vars. I'm going to give that a test and report back. –  Jonathan Wold Mar 26 '13 at 0:11
    
Disabling query_var did the trick - Thank you! –  Jonathan Wold Mar 26 '13 at 0:16
    
Great! Glad to hear that problem is solved :) –  ceruleus Mar 26 '13 at 0:31
add comment

I'm taking some shots in the dark, here.

The first place I would look is your register_taxonomy call. You should make sure not to set the query_var option to false.

register_taxonomy(
  'speakers',
  array('post'),
  array(
    'rewrite'                    => array( 'slug' => 'media-channel' ),
    'public'                     => true,
    'query_var'                  => 'speakers',
  )
)

With that in place you can be certain you can test the query using get_posts. This test would look like:

$test_results = get_posts( array(
                      'post_type' => 'post', 
                      'numberposts' => -1,
                      'speakers' => 4,
                  ) );

Did you get results? On looking at your example I have a strong suspicion that your taxonomy may be associated with attachments. If that's the case I have had to do add "post_status" => "inherit".

$test_results = get_posts( array(
                      'post_status' => 'inherit',
                      'post_type' => 'attachment', 
                      'numberposts' => -1,
                      'speakers' => 4,
                  ) );

How does this look to you? If you're getting results here then maybe there's something going on with the query parameters or rewrite rules.

The codex register_taxonomy references the need to flush the rewrite rules if you use the 'rewrite' parameter.

 global $wp_rewrite;
 $wp_rewrite->flush_rules();

Now that you're fairly certain that you're getting results from this query you can inspect the query that WordPress is building internally. This can be done with the excellent plug-in "Debug This" or using:

global $wp_query;
print_r($wp_query->query_vars);

This will show the query that WordPress constructed using "?speakers=4".

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.