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.

The Perfect Website


Change Default Mail Application in OS X without opening Mail.app

Why this is not a setting in System Preferences I will never understand. But this is how OS X is. In order to set the default mail application you have to use Mail.app. My issue here is that anytime there is a mailto link from any application, clicking on said link opens Mail.app instead of Outlook. I have been looking for a way to alter this behavior this from the command-line and as far as I can tell there is no way to do this with a vanilla OS X install. Not unless you want to manually edit plist files.

I have found a thread on the Jamf support forums that lead me to Duti, a command-line tool for setting default applications on OS X. I was not able to build it on my Mac (OS X 10.10.5 with Xcode 7) but was able to install it via brew.

To set the defaults you need to know what the bundle identifier of the target application is. If you do not know what the bundle identifier is you can find it for your application using the mlds  utility.

This will return something like

Now you can run the following to make Outlook the default handler for mailto links:

I do not know if this is a permanent fix or if this needs to be executed on each login. If it is the later then you could easily add it to your bash_rc.

Anyways, super annoying that this is even a thing. The real solution here is to move the setting out of Mail.app and into System Preferences.

Regular Expression of the day

Match generic US phone numbers. Ignore 1-9 repeating (ie: 4444444444, 1111111111, (except 7, we want 7777777777 for testing)). Allow for spaces, no spaces, dashes, or period delimiters.

Of course we _should_ use a standard phone number regex, but this project calls for something unique.

RegEx is weird, but fun.

Technical Documentation for a Web Development Project


Working on a large web development project requires that you have clear direction and good technical documentation. The designer needs to understand the functional requirements and the data model in order to deliver a successful design. The themer need to understand the UI/UX spec in order to deliver accurate and functional markup. The developers need to understand the functional requirements and data model in order to build out the CMS backend. Creating these documents, as a team, will help guide the project to success.

The documents described below narrow the scope of the project, each one focusing deeper and deeper on each aspect of the project. The process of defining the scope in the lifecycle of a project follows this informational flow; SOW -> Technical Requirements -> Functional Requirements -> Data Model -> Sitemap -> UI/UX Specifications -> QA Plan. Each document is a closer view of the scope of the project. The SOW is very high level while the UI/UX spec is in the weeds. I am primarily a web developer and web architect so I will focus on the architects/developers needs around these documents.

Technical Requirements

The technical requirements document is short and sweet. It is the “non functional” requirements of the project. This document outlines the technologies and services upon which the system will be built. Common sections in this doc include:

  • Technologies
    • Include the CMS and version, requirements around the underlying programming languages and versions, operating system requirements, search technologies, etc.
  • Services
    • A list of 3rd party services we are integrating with, or utilizing in some fashion. Usually this list implies we are interacting with an API, or in need of some sort of XML feed, or something similar.
  • Web Hosting Partner
    • Information around the web host. Include information around backups, support, and redundancies here.
  • Browser Support
    • Which browsers the site must support. Include mobile devices as well.
  • Performance
    • Include specific requirements around performance metrics. For example, “time to first byte must be between 200-400ms”.
    • If you are using New Relic to monitor performance include the key metrics here.
    • Include and expand on specific caching requirements, asset minification, caching, CDNs, etc.!

Functional Requirements

The functional requirements document is the meat of the actual website. The functional requirements document describes the actual functions of the site. I tend to organize this document into the following:

  • Features
    • Describe the unique functionality of the site here. Describe how 3rd party integration’s will work. Describe requirements around backend functionality. Include SEO requirements, schema markup, social sharing and integration. Does the site have an events calendar? Describe in detail the functions of the calendar.
    • In project management terms, each feature here would correspond with a “component” in Jira (for example), that would be estimated, prioritized, and groomed until it was ready to be developed. Conversely, any component would have a corresponding set of requirements.
  • Usability
    • Requirements around usability. For example, ADA requirements. Does the site have to meet any web accessibility standards? Should content be made available in multiple formats? Should the entire site be navigable via keyboard?
  • Use Cases & Work Flows
    • Use this area to define expected workflows, such as content moderation, user sign up process, or complex form interactions.
  • Legal
    • Cookie Notifications.
    • Compliance review and process by a governing body.
    • PII or HIPAA requirements.

Data Modeling

The data model is often overlooked and just sorta dealt with. A designer will often times dictate the data model through their design. This will put impossible and/or expensive constraints on the developer. The data model informs design.

The data model document is a diagram that clearly illustrates how the data in the system is organized, how it is categorized, how it is searched, and how the data relates to each other. You should include all of the fields for each content type that will be required. This might be one of the most important documents. It will have a large impact on all teams.


This is a client facing document that shows a sites overall organization, design goals, and information architecture strategy.

UI/UX Specifications

The UI/UX Specification document is a detailed document that explains how a component should operate from a UI/UX perspective. For example describing the behavior of a header. You would tell the developer that on page load the header will be transparent, when a user starts to scroll the header will animate to become opaque. The animation should happen in 200ms. As a user scrolls the header will be fixed to the top of the page. It is extremely helpful to include diagrams, flowcharts, and screenshots to illustrate the described behaviors.

Remember that you are not telling the developer how to do something, you are telling them what it must do.


To summarize, each document informs the next, and each document helps clarify and define scope which should make estimation and timeline planning more accurate for the project manager, reduces the amount of assumptions a developer has to make, and defines some guardrails for creative. The project manager ultimately “owns” these documents, but it is absolutely a collaborative effort in creating them. In my perfect world it reduces guesswork and limits the amount of “oh shit” moments at the end of the project.