This post takes a look at the “behind the scenes” on how WP_Query processes a simple custom sort.
My goal was to have an blog of autobiographical posts presented in ascending order – from oldest to newest – the reverse of the standard WordPress presentation.
This task provided a good opportunity for me to brush up on object oriented programming, and bone up on PHP and some slightly more advanced WordPress programming.
There may be several ways to achieve this result – but my plan was:
Create a child theme
Create a function in the child theme’s function.php file causing WordPress to display the posts by date in ascending order.
Almost all the examples I could find of modifying the WordPress criteria for controlling post presentation have only a single criteria – often something like selecting specific “categories” – to include or exclude.
I needed two criteria – one for what to sort, and the second to specify the sort order.
I finally found an example of using two criteria – and was able to construct my function in the functions.php file to sort the posts by “date” and in “ASC” (ascending) order.
Screen 1 – my child theme’s function.php file:
This functions.php in my child theme accomplished exactly what I wanted.
In order to set more complex criteria in the future (and to satisfy my curiosity) I decided I needed to know why this works.
Searching the WordPress CODEX, I learned that “set( )” is a method of WP_Query class, and “pre_get_posts” acts on an instance of an object of the WP_Query class.
(And I learned that the WP_Query class has 4o to 50 methods!)
I presumed (correctly) that “$query” was an instance of the WP_Query class.
My function “my_sortem” – is where I set the two criteria for my sort.
As each sort criteria requires two values, (i.e. “orderby” and “date”) these criteria “pairs” are set using the “set( )” method, instead of the “->” operator to set a object property.
To learn all this I started by finding the places in the WordPress core where objects of the WP_Query class are instantiated. There are four places in three files.
Screen 2: Search result of all of WordPress for “new WP_Query”:
I later learned that it probably doesn’t really matter where WP_Query class objects are instantiated. What was important was to see that the WP_Query class uses a “constructor” – and it took me quite a while to understand why the first two instantiation statements appear cyclical.
The statement:
$query = new WP_Query($query);
appears to instantiate an object used by it’s constructor. As it happens – I believe it does just that.
My first peek at the code was the beginning of the WP_Query class – which declares a public variable of $query an object identifier – because of the use of $query is in the instantiation statement.
Screen 3 – The first few lines of the WP_Query class:
Buried way down on line 3520 is the “__construct( )” function that performs the constructor function when an instance of the WP_Query object is instantiated.
This constructor function takes the class argument “$query” used in the object instantiation and does the following:
Sets the default value of $query to nothing. (”)
Tests to see if the object $query is empty.
If $query is empty, the current object’s method, “query( )” is called with the $query argument.
Screen 4 – The constructor function of WP_Query:
The “query( )” method does the following to the “$query” object:
Calls the object’s “init( )” method.
Sets the object’s “query” property to the result of the “wp_parse_args( )” function.
Sets the object’s “query_vars” property to the value of the object’s “query” propety.
Returns the result of the object’s “get_posts( )” method. It appears this method is performed – but the calling statement does not receive a value as a result of this method. So the point was simply to call the object’s “get_posts( )” method.
The “query( )” method – Screen 5:
According to the comments in the “get_posts( )” method, it’s function is to retrieve an array of the posts based on the query variables – in my case, the “orderby” and “date” and the “order” and “ASC” pairs.
The query variables are the pairs set back by my “my_sortem” function’s use of the “set( )” method. This method loads them into an array:
The query variables are validated in other functions. Here the “parse_orderby( )” function lists the table columns allowed to be sorted – or “orderedby”.
The “order” is also validated – either “DESC” or “ASC” – in all upper case letters as required by SQL.
