Opened 9 years ago
Last modified 8 years ago
#43324 new enhancement
query_vars is not necessarely representative of the final query_vars used to build the SQL query
| Reported by: | msaggiorato | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | Awaiting Review |
| Component: | Query | Version: | |
| Severity: | normal | Keywords: | |
| Cc: | Focuses: |
Description
I've recently stumbled upon a case here where the post_type query_var changes over the process of the query building process, and the change is not reflected in the query_vars variable of the query.
On the section highlighted here (sorry for pasting a GitHub link, i just wanted to use the section highlighting feature), you can see that if there's no post_type set in the query, but you're querying taxonomies (eg a tax archive query), the post_type is set (using a separate variable), and then used on the following section to build up the where statement.
In my opinion all of the query_vars modified during the process should be reflected in the query_vars variable, so you can after see the actual value being used for querying (on the posts_request filter for example).
You can see here a section where the $q['author']}}, {{{$q['author__in'] and $q['author__not_in']. These is an example of changes that are not reflected in the query_vars (since there's no call to fill_query_vars after all this extra parsing, sanitizing, and defaulting process is made).
Let me know your thoughts.
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)