Order Posts via “Weighted Pseudo Randomness”

A request we are getting more often is to show a list of posts, to elevate some of those posts above others, and to show the posts in a random order. Imagine a post type called “Sponsors”. Sponsors are tiered, like “Platinum”, “Gold”, “Silver”, etc. We want the Platinum sponsors to appear before Gold, Gold before Silver, and so on. We don’t want to favor one particular Platinum sponsor though, we want them to be randomized but ordered by the tier.

The number one rule we had for implementing this feature is that we could not break existing WordPress functionality. Meaning, pagination has to work, and any sort of post filtering that existed on the site must also continue to work. An additional requirement is that we could not have duplicate posts show up as we paginated results. Hence, pseudo random.

This is achieved by ordering the result set by a weight value (aka the tier) and then to randomize those results, using the MySQL RAND() method. MySQL’s RAND() method takes an optional $SEED parameter. If we pass the same $SEED value to our query for each request we can maintain the same random order as we paginate through posts. This ensures that we do not have duplicates. I am generating the seed value using “date(‘ymd’)”. The value will change daily, and create a new randomness to the posts each day. Weight is derived from the tier that the posts are assigned. In my case, we use ACF and an ACF field that allows a user to select a single value from a Tier taxonomy. Knowing this, I used the postmeta value of the term id that is selected to get the slug of the term itself. I then used a CASE statement in my query to assign a weight value based on the slug of the selected taxonomy term. Tier1 is assigned 1, tier2 is assigned 2, if there is no term, weight is 9999 (so that these posts always show up after a tiered post). The CASE statement looks like:

In order for this to work we need to JOIN the wp_terms table based on the metavalue of the selected tier taxonomy.

The query basically looks like this when it is compiled (this is a simplified example of how the resulting MySQL query is going to look):

The goal is to make WordPress write this query for us in the loop. We can do this using filters that modify the WP_Query. The first thing we need to do is to be able to identify the WP_Query so that we do not alter _other_ queries on the site. We only want to change the query that loads posts from our custom Sponsors post type. To do this we add a custom query_var to WordPress and then check for that query_var in our wp_query. Add the query var:

We now inject this param into our main query using “pre_get_posts”. We do not want our listing of sponsor posts in the admin area of WordPress to be ordered randomly, so we need to check that we are not is_admin().

This function checks the wp_query object passed to it. If the post type is our custom post type we set the “is_pseudorandom_query” query var to true. With this set we can now setup our wp_query filters. If you are using a custom WP_Query object you can pass “is_pseudorandom_query” as one of the $args:

Now to the WP_Query filters. The three filters we need are posts_fields to add our CASE statement, posts_join to add our custom LEFT JOINS, and posts_orderby to order by our new weight value and then by RAND().

The functions:

In each function we inspect the passed $wp_query object to see if “is_pseudorandom_query” is set. If it is, then we modify the query.

And there it is. We can now order posts by tier, and then randomize each tier.

I know just enough to like it but not enough to know I shouldn’t! – me, about Ruby

Setting up Git HTTP Backend for local collaboration

You want to share a topic branch with a colleague but do not want to push that branch upstream to Github/BitBucket/GitLab, etc. How do you do this? You could create a patch and email it. Or you could use Apache and allow your colleague to pull from your repo directly. This does take a bit more time to setup, but would be the most convenient for everyone involved. The basic idea is that you “host” the git repos on your local machine, and push your commits to it as you are developing. You then make your git repos available via Apache on your internal network to allow team members to pull from your local repo.

First create a place to store your repos. Let’s also create a test repo to work with to make sure everything is working.

Next let’s setup Apache (I am using OS X El Capitan with Apache 2.4).

Edit /private/etc/apache2/httpd.conf.

Ensure the following modules are being loaded.

Uncomment the following line:

Edit /private/etc/apache2/extra/httpd-vhosts.conf.

I removed the existing virtualhosts since I actually do all of my development with Vagrant and Linux. So I really have no need to have anything more than a single virtualhost on my Mac.

Edit the the bolded parts to suit your local setup.

Restart apache.

Your git repos will now be available at http://locahost/git/<REPONAME.git>.

You should now be able to clone your empty repo.

Let’s test it out.

You should be able to make changes and push to your remote.

There it is!

Now you can have a colleague pull changes directly from you. Simply provide them with your public address, for example, and they should now be able to clone your repo, add your remote, pull changes, etc.

If you want other people to be able to push to your repo you will have to explicitly allow this. In your testproject.git repo, set the http.receivepack value to true: