Opened 8 years ago
Last modified 8 years ago
#40387 reopened defect (bug)
WP_Query bug with product post type with search parameter on
Reported by: | subrataemfluence | Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | 4.7.3 |
Component: | Query | Keywords: | |
Focuses: | Cc: |
Description
I am not sure if it is a WordPress core bug, but seems like it! I have 5 different custom post types along with 'product' post type from Woocommerce.
The following query gives (only) product result:
$args = array( 'post_type' => array('product'), 'posts_per_page' => 5, 'post_status' => array('publish', 'future') );
Actual query output:
SELECT SQL_CALC_FOUND_ROWS wp_posts.ID FROM wp_posts WHERE 1=1 AND wp_posts.post_type = 'product' AND ((wp_posts.post_status = 'publish' OR wp_posts.post_status = 'future')) ORDER BY wp_posts.post_date DESC LIMIT 0, 5
But the following query:
$args = array( 'post_type' => array('product'), 's' => 'mobile', 'posts_per_page' => 5, 'post_status' => array('publish', 'future') );
outputs this (even post_type is specified the query is generated to search all other post types and surprisingly not product):
SELECT SQL_CALC_FOUND_ROWS wp_posts.ID FROM wp_posts WHERE 1=1 AND (((wp_posts.post_title LIKE '%htc%') OR (wp_posts.post_excerpt LIKE '%htc%') OR (wp_posts.post_content LIKE '%htc%'))) AND wp_posts.post_type IN ('post', 'travelog', 'hotel-info', 'trips', 'package_tour') AND ((wp_posts.post_status = 'publish' OR wp_posts.post_status = 'future')) ORDER BY wp_posts.post_title LIKE '%htc%' DESC, wp_posts.post_date DESC LIMIT 0, 5
and brings up results from all other post types and simply ignoring product.
Change History (8)
#1
@
8 years ago
- Milestone Awaiting Review deleted
- Resolution set to invalid
- Status changed from new to closed
#2
@
8 years ago
- Resolution invalid deleted
- Status changed from closed to reopened
Hi @boonebgorges, thank you for looking into my issue. As per your advise I disabled (deactivated) all my plugins. Then created a template page where I put the following code first:
$args = array( 'post_type' => array('product'), 'posts_per_page' => 5, 'post_status' => array('publish', 'future') ); $q = new WP_Query($args); echo $q->request;
Here is the output:
SELECT SQL_CALC_FOUND_ROWS wp_posts.ID FROM wp_posts WHERE 1=1 AND wp_posts.post_type = 'product' AND ((wp_posts.post_status = 'publish' OR wp_posts.post_status = 'future')) ORDER BY wp_posts.post_date DESC LIMIT 0, 5
which is exactly what I want!
Now I added the search query part in $args
i.e
$args = array( 'post_type' => array('product'), 'posts_per_page' => 5, 's' => 'htc', 'post_status' => array('publish', 'future') ); $q = new WP_Query($args); echo $q->request;
and the output is:
SELECT SQL_CALC_FOUND_ROWS wp_posts.ID FROM wp_posts WHERE 1=1 AND (((wp_posts.post_title LIKE '%htc%') OR (wp_posts.post_excerpt LIKE '%htc%') OR (wp_posts.post_content LIKE '%htc%'))) AND wp_posts.post_type IN ('post', 'travelog', 'hotel-info', 'trips', 'package_tour') AND ((wp_posts.post_status = 'publish' OR wp_posts.post_status = 'future')) ORDER BY wp_posts.post_title LIKE '%htc%' DESC, wp_posts.post_date DESC LIMIT 0, 5
which shows the problem is still there. There is no product
post type included in query, rather all other post types are available which I never asked WordPress to include through my above query.
I have ALL plugins deactivated, ready made as well as those I built for this site.
#3
@
8 years ago
It's possible the exclude_from_search parameter is set to true on the product post type.
#4
@
8 years ago
It's possible the exclude_from_search parameter is set to true on the product post type.
A good thought - but (a) WooCommerce doesn't set exclude_from_search
to true
, and (b) even when exclude_from_search=true
, WP_Query
by itself doesn't change post types based on exclude_from_search
. (Primary exclude_from_search
filtering happens in WP::parse_request()
.)
@subrataemfluence I've installed WooCommerce, created some items, and tested the precise code that you've provided, but I was not able to reproduce. The request
SQL string, in both cases, contains wp_posts.post_type = 'product'
.
I don't have any clear ideas about what might be happening. @subrataemfluence Are you able to dig deeper into WP_Query
to see where post_type
is getting reset?
#5
@
8 years ago
@boonebgorges yes, I am trying the same thing. For this purpose to start with I have just created a new local website with no plugin (so far) in order to test WP_Query
. I shall do it after installing WooCommerce and adding a couple of products.
If WP_Query works OK here, I will try digging more into WP_Query
and find where it is getting reset in my actual website even with all plugins deactivated.
#6
@
8 years ago
@subrataemfluence Thanks for continuing to look.
To be clear, you must be running at least *one* modification, in addition to WooCommerce: your WP_Query
call. How are you doing it? Is it in a theme template? Or in a hook callback? For purposes of testing, I did mine like this:
add_filter( 'the_content', function( $content ) { $query = new WP_Query... } );
#7
@
8 years ago
@boonebgorges Sorry, I am not very well-versed with WordPress yet (stepped into in only a few weeks ago) and wasn't aware of the above filer method you mentioned. All I am doing right now is writing my WP_Query
in a template page and getting the request as well as the result printed on screen.
It would greatly help if you please tell me what the above filter hook actually does and what difference it has from my template based WP_Query approach.
Meanwhile my test with a brand new site with only Woocommerce and one additional custom post type (hand written plugin based). The result is coming along fine with the same combinations which was causing problems in my actual site.
I am still trying to find out why and where the query is getting overwritten or conflicted in my main site.
There's nothing specific in
WP_Query
that'd cause the post_type parameter to be changed based on the presence of a search term. I've done some testing and I can't reproduce the behavior. It's likely that what you're seeing is due to a plugin that modifies WP's core search functionality. Please do some debugging by disabling plugins along these lines, and feel free to reopen this ticket if you find evidence directly indicating that this is a core bug.