Make WordPress Core

Opened 13 years ago

Closed 11 years ago

#16025 closed defect (bug) (worksforme)

Page and custom taxonomy query var 404s

Reported by: duck_'s profile duck_ Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Query Keywords: close
Focuses: Cc:

Description

Reported in IRC. Visit a page and append "customtax=foo", where customtax is some registered taxonomy.

3.0.3 => displays the page
3.1 => 404, since obviously no pages matched in the custom taxonomy

Here is associated code reporter used to register the custom taxonomy: http://pastebin.com/eqQbXVvh and they were visiting http://example/products/?surface=stone where products is a regular page (I assume from this they may be hoping to display only products with stone taxonomy, maybe with custom handling in a template to get it to work... again this is a guess.)

Seems like this is probably expected to me, but it is a change.

Change History (6)

#1 @nacin
13 years ago

  • Keywords close added

Per IRC, this seems to be expected behavior.

#2 @acsnaterse
13 years ago

As discussed per IRC this could/should be expected behavior, but I tend to disagree for the following reason..

I understand that this URL says: give me page X which has customtax 'foo'. Well, there wasn't page with that customtax 'foo', so the 404 should be expected. The problem was that I should use CPT archives. However that seems not to be a working solution,

http://example/product/ gives me perfectly the 'product' (which is the CPT) archive page.

The reason why I used the customtax GET param was because of some filtering. I just want to retrieve the customtax GET param and add it in the query_posts args array, so I only get the products that has this 'foo' customtax.

But when I use http://example/product/?customtax=foo, it immediately redirects to http://example/customtax/foo which is unwanted for me since I want to use the GET params, but also it gives a 404, which is unexpected anyway I guess.

Then the second case: when I want to filter on more customtaxo's it will also break (as in: it gives a 404). For example: http://example/product/?customtax=foo&customtax2=foo2 gives a 404 too.

So my first question is: is this all expected behavior? Or should it work I expected (without 404 obviously)? And if this is expected behavior, what should be the proper way to create such a filter mechanism (with GET params) ?

Second question: if this is expected behavior, should it return a 404, or just return no posts? My feeling says (since it's kind of filtering), it would return 0 posts.

PS: again, this all worked in 3.0.3

#3 @markjaquith
13 years ago

  • Milestone changed from 3.1 to Future Release

This seems unorthodox. In any case, probably too complicated to fix during RC.

#4 @anmari
13 years ago

Hi I think my problem is similar to the above, and I don't think the fix should be that hard (says I not knowing where to look in the wp template determination code myself!)

Any page or post query that has additional query parameters that are taxonimies or categories now causes a 404.

ie: http://localhost/wpbeta/?page_id=38827 works
but this
http://localhost/wpbeta/?page_id=38827&places=america causes a 404

Before it used to display the page and then one could pickup the query parameters and use them in a shortcode plugin.

I think wp 3.1 behaviour could be fixed by simply giving the page_id or post id query parameter the highest priority when determining the template - ignore the rest. Does that not make sense?

My events calendar plugin uses a page with a shortcode and then accepts additional query parameters which could be taxonomies amongst others. I had a taxonomy widget which filtered wp_list_categories and swopped out the home page url to redirect it to the calendar page url.

It all worked sweetly before.

The thought has occurred to me that maybe I need to totally change the way it works (sigh). Essentially I am using the page with shortcode as the template for the post types. But this is not an ideal solution as it is desirable to perhaps also have a 'normal' archive for these things. The shortcode listing applies ics RFC 5545 rules and allows recurring events, so is not really the same as an archive template.

Sooo I come back to thinking that is a 'bug' to produce a 404 and that it makes more sense that if the query url has a page or post id in it, wp should serve that page or post up, never mind what else is in the url string?

#5 @anmari
13 years ago

More info;
I decided not to be selfish and lazy and dig into the 3.1 code.
If one were to decide one had a page on a page_id and not add in the taxonomies and categories, the change would have to be somewhere in query.php between lines 2100 and 2113.

If pages could have taxonomies and catgeories (can they?) then it would make sense to leave code as is and users would have to make sure that they added the necessary taxos and cats to the page. (I got shortcode in a post working as before by doing that for a post).

Anyway I come up with a fix that seems adequate for my purposes using action that is called at top that section.

add_action ('pre_get_posts', 'a_page_is_a_page_we_need_no_more');

function a_page_is_a_page_we_need_no_more($q) {  
// removes category and taxonomy query vars from page queries 
// the logic being that if we are querying a page and we already know the page id, then additional queries and categories and taxonomies are not relevant and can be ignored.  
// the queries vars, category and taxonomy are still there to be used by the event shortcode logic within the page.  THis way we at least get a page not a 404.

	$possible_parameters = array (
		'author'
		, 'author_name'
		, 'cat'
		, 'category_name'
		, 'tag'
		, 'tag_id'
		, 'category__in'
		, 'category__not_in'
		, 'category__and'
		, 'post__in'
		, 'post__not_in'
		, 'tag__in'
		, 'tag__not_in'
		, 'tag__and'
		, 'tag_slug__in'
		, 'tag_slug__and'
		, 'meta_key'
		, 'meta_value'
		, 'preview'
		, 's'
		, 'sentence'
		, 'fields'
		, 'second'
		, 'minute'
		, 'hour'
		, 'day'
		, 'monthnum' //?monthnum=3 
		, 'year' //?year=2005  posted in,
		, 'w'
		
	);

	if (isset($q->query_vars) and (
		(!empty( $q->query_vars['page_id'])) or
		(!empty( $q->query_vars['page'])) or
		(!empty( $q->query_vars['pagename'])))	
		) {  	
		// then we already know our page, lets unset the rest from this query variable.  They will still be accessible to the shortcode.
		// first unset all the event taxonomies we use - (should we just do all taxonomies anyway to avoid 404 ? ?)
		$opt  = get_option( 'amr-event-taxonomies' );
		if (!empty ($opt)) {
			if ( is_array( $opt['taxonomies'] ) ) {
				foreach( $opt['taxonomies'] as $key => $taxonomy ) {
					if (!empty ($taxonomy['posttype'])) // ie we are using it somewhere for our events 
					unset($q->query_vars[$taxonomy['name']]);
					}		
			
			}
		}
		foreach ($possible_parameters as $value ) {  
			unset($q->query_vars[$value]);
		}
	}
	return($q);
}


Last edited 13 years ago by anmari (previous) (diff)

#6 @wonderboymusic
11 years ago

  • Milestone Future Release deleted
  • Resolution set to worksforme
  • Status changed from new to closed

Tax Query no longer runs for is_singular() since [17504] - so there's no 404 here

Note: See TracTickets for help on using tickets.