Tag: WordPress

The Reality of Gutenberg & WordPress

Gutenberg is happening. It is coming and it is coming soon. I am not thrilled.

WordPress the CMS

Automattic have been trying to tell us for years that WordPress is more than a blogging platform, that is a true and full Content Management System. "Look!", they say. "You have custom post types, and the metabox API allows for you to create complex content types. It's a CMS!". Alas, it is all built on top of a blog with very blog specific design patterns. The underbelly of WP is ugly and hacky, even if it works "just fine" most of the time. Gutenberg is as direct of a statement of intent as I could expect; WordPress is a blogging/marketing platform, and not a CMS.

WordPress the Casual Site Builder

Gutenberg is a response to the threat of Squarespace and Wix and Medium. This update is for WordPress.com, to combat the threat of those other systems, to ensure dominance in the web publishing space, to increase market share by appealing to more casual users, small business owners, etc. Automattic can probably then generate leads for their WP VIPs. But I think this will come at the expense of developers like me, working at a digital agency, who drank the koolaid about WordPress being a CMS and it being a tool that can be used for Higher-Ed, Government, Healthcare, and not just for a blog or a simple marketing site. I am ready to move on to real CMS's for those projects. As for the marketing and bloggy sites, Squarespace has a much more robust block and content building experience. Why even bother with WordPress at this point? Gutenberg is not anywhere close to those systems, yet. It will probably get there, but will it matter, and will it be worth it?

Gutenberg the Editor

The new editorial process is nice, but super limiting. I hope that more blocks are in development otherwise this feels dead on arrival. I am having some fun with it on my site, checking things out, playing with the shiny new toy, but after a few posts, it's already starting to feel restrictive. Theme builders give me so many more options for how to present content. Sure, they are nasty and terrible, but they offer so much more out of the box. I kinda hope that WordPress does not depend on extending block functionality via 3rd party plugin. They have come this far, surely they can offer some more variety?

For example, how about letting me insert a block above the title. Typically you start the page with a large hero, then the primary h1 follows. You can do this now by excluding the post title, but Gutenberg does not let you change the post slug (why?). And if you dont have an SEO plugin installed your <title> will be empty.

How about letting me define a wrapper element around a few blocks to give me more HTML to hang a frontend design off of? Like, making a group of blocks.

How about a related posts that is not just a list of post links, but something that will allow an editor to create a curated list, or a dynamically generated list, that includes thumbnails, excerpt, tags, whatever.

If it ain't broke…

Creating custom blocks has a much higher barrier to entry than say, creating custom field sets with ACF Pro, or using Metabox.io to create modular content blocks. We typically have some unique design constraints and features of our content patterns that do not allow for perfect modular re-use across websites. In other words, we make boutique websites for our clients. ACF and Metabox.io make this extremely easy. Gutenberg blocks are going to take a lot more time to build and test (now we have to test integration on the backend?!)

Ok. I am starting to rant. Ill end this by saying I don't think Gutenberg needs to be THE editor for WordPress, just AN editor for WordPress. Leave it as an optional plugin.

WP Transients must be used responsibly

We ran into an interesting issue with WooCommerce at work. First, here is the subject of the support request we got from our hosting provider:

The site is generating ~150MB/sec of transaction logs, filling 500GB of diskspace

Holy. Shit. A WordPress site should not be generating that much data. 150MB per second? Wow.

How? Why?

The simple explanation is that there is a bottleneck in WooCommerce with the filtered layer nav query objects using single transient record.

// We have a query - let's see if cached results of this query already exist.
$query_hash    = md5( $query );
$cached_counts = (array) get_transient( 'wc_layered_nav_counts' );

if ( ! isset( $cached_counts[ $query_hash ] ) ) {
    $results                      = $wpdb->get_results( $query, ARRAY_A );
    $counts                       = array_map( 'absint', wp_list_pluck( $results, 'term_count', 'term_count_id' ) );
    $cached_counts[ $query_hash ] = $counts;
    set_transient( 'wc_layered_nav_counts', $cached_counts, DAY_IN_SECONDS );

What is happening here is that a sql query based on the currently selected filters is hashed and shoved into an array that is saved to a single transient record. This means that every single interaction with the filters requires a read and possible write to a single transient record. A site with any sort of traffic and let’s say 9 filter widgets (with around 50 total options) will potentially generate a huge amount of unique queries. It is no wonder why we are pushing 150MB/s.

Our quick, temporary, patch was to simply remove the transient.

// We have a query - let's see if cached results of this query already exist.
$query_hash    = md5( $query );
$cached_counts = array();
$results                      = $wpdb->get_results( $query, ARRAY_A );
$counts                       = array_map( 'absint', wp_list_pluck( $results, 'term_count', 'term_count_id' ) );
$cached_counts[ $query_hash ] = $counts;

You can see the massive improvement in performance after removing the transients. We applied the patch around 9:47 am.

Object caching would probably help. I was surprised at how much of an improvement we saw by simply removing the transient.

I think a good solution here would be to use unique transients for each hashed query, and not a single transient for EVERY hashed query. It would work find on small WP installs and would scale.

I will try it out and see what we get and if the results are good I will submit a PR to the woocommerce devs.


I said we should use transients responsibly. In this case, I would be creating potentially 15k additional (tiny) transient records. Is that more responsible than 1 massive 1mb transient?

WooCommerce devs has asked that I run some performance tests. Going to do so and report back!

update 2:

Not having any transients at all is better at scale in our case since the SQL query that is executed is not that heavy and we have some decent page caching via varnish. Also our MySQL server is well tuned. Every single request to a page with the layered nav will make N requests for the transient data. If data has to be written, that is N updates per request. This single record becomes a bottleneck as the field is locked while it is being written to. Redis or Memcache would be a a better solution. WP Transients are just bad on their own.

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:

SELECT wp_posts.*, CASE weightterms.slug WHEN 'tier1' THEN 1 WHEN 'tier2' THEN 2 ELSE 9999 END AS weight FROM wp_posts ...

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

LEFT JOIN wp_postmeta as weightmeta ON (weightmeta.post_id = wp_posts.ID AND weightmeta.meta_key = "sk_tier")
LEFT JOIN wp_terms as weightterms ON (weightmeta.meta_value = weightterms.term_id)

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):

    CASE weightterms.slug WHEN 'tier1' THEN 1 WHEN 'tier2' THEN 2 ELSE 9999 END AS weight
LEFT JOIN wp_postmeta as weightmeta ON (weightmeta.post_id = wp_posts.ID AND weightmeta.meta_key = "sk_tier")
LEFT JOIN wp_terms as weightterms ON (weightmeta.meta_value = weightterms.term_id)
WHERE wp_posts.post_type = 'sponsors'
    weight ASC,

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:

add_filter( 'query_vars', array( $this, 'theme_query_vars_filter' ), 10, 2 );
function theme_query_vars_filter( $qvars ) {
    $qvars[] = 'is_pseudorandom_query';
    return $qvars;

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().

add_filter( 'pre_get_posts', 'theme_pre_get_posts', 10, 2 );
function theme_pre_get_posts( $wp_query ) {
    if ( !is_admin() && isset( $wp_query->query['post_type'] ) && $wp_query->query['post_type'] == 'sponsors' ) {
        $wp_query->set( 'is_pseudorandom_query', true );

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:

$my_custom_query = new \WP_Query( [ "is_pseudorandom_query" => true ] );

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().

add_filter( 'posts_fields', 'theme_sponsor_posts_fields', 10, 2 );
add_filter( 'posts_join', 'theme_sponsor_posts_join', 10, 2 );
add_filter( 'posts_orderby', 'theme_sponsor_posts_orderby', 10, 2 );

The functions:

function theme_sponsor_posts_fields( $select, $wp_query ) {
    if ( $wp_query->get( 'is_pseudorandom_query' ) == true ) {
        $select .= ", CASE weightterms.slug WHEN 'tier1' THEN 1 WHEN 'tier2' THEN 2 ELSE 9999 END AS weight";
    return $select;

function theme_sponsor_posts_join( $join, $wp_query ) {
    if ( $wp_query->get( 'is_pseudorandom_query' ) == true ) {
        $join .= ' LEFT JOIN wp_postmeta as weightmeta ON (weightmeta.post_id = wp_posts.ID AND weightmeta.meta_key = "sk_tier")';
        $join .= ' LEFT JOIN wp_terms as weightterms ON (weightmeta.meta_value = weightterms.term_id)';
    return $join;

function theme_sponsor_posts_orderby( $orderby, $wp_query ) {
    if ( $wp_query->get( 'is_pseudorandom_query' ) == true ) {
        $orderby = 'weight ASC, RAND(' . date('ymd') . ') ASC';
    return $orderby;

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.

TLS Peer Verification w/PHP 5.6 and WordPress SMTP Email plugin

We ran into an issue after upgrading from PHP 5.5 to 5.6. We were no longer able to send email via the awesome WordPress SMTP Email plugin. Turns out that PHP 5.6 introduced some enhancements to its OpenSSL implementation. Stream wrappers now verify peer certificates and hostnames by default. This was causing the form submissions on our site to fail. Clearly there are some issues with our Postfix config and certs. While we sort out those issues, we were able to “solve” our immediate problem, and disabled peer verification in the plugin without editing core files. Thankfully the plugin developer included a filter that would allow us to modify the options array that is passed to PHPMailer.

add_filter('wp_mail_smtp_custom_options', 'my_wp_mail_smtp_custom_options');

function my_wp_mail_smtp_custom_options($phpmailer) {
    $phpmailer->SMTPOptions = array(
        'ssl' => array(
            'verify_peer' => false,
            'verify_peer_name' => false
    return $phpmailer;


Thanks random WordPress forum user for the solution!

A WordPress ajax handler for custom themes

A WordPress ajax handler for custom themes

Something I have been noodling on is a better way to handle ajax requests in my custom themes. Seems to me that a relatively complex theme ends up with a lot of add_action calls for custom ajax handlers, and this could be simplified/reduced. Every time a new endpoint is required we have to add two new add_action calls to our theme. Maybe a better approach is to write a single ajax endpoint that will route requests to the proper classes/methods?

The goal would be that all ajax requests are run through our custom ajax handler and routed to the appropriate controller & method for execution. This method allows us to encapsulate functionality into separate classes/modules instead of cluttering functions.php with ajax functions. Potentially this makes the code more reusable.

With some sane configuration I think that this could be a good way to build a flexible ajax interface into your theme. To protect against malicious calls classes are namespaced (\Ecs\Modules\), and the methods are prefixed (ajax*). This should stop most attempts to execute arbitrary theme code. There are issues though. There would be a fatal error if the class does not exist which could expose information about the environment. We have to make sure that the $_REQUEST params are well sanitized. This would need to be scrutinized and tested for security issues. We don’t want someone to be able to craft a request to execute code we don’t explicitly want executed.

Here is an example structure in a hypothetical Theme class.

class Theme

    public function __construct()
        ... snip ...

        add_action('wp_ajax_ecs_ajax', array(&$this, 'executeAjax'));
        add_action('wp_ajax_nopriv_ecs_ajax', array(&$this, 'executeAjax'));

    ... snip ...

     * Simple interface for executing ajax requests
     * Usage: /wp-admin/admin-ajax.php?action=ecs_ajax&c=CLASS&m=METHOD&_wpnonce=NONCE
     * Params for ajax request:
     * c         = class to instantiate
     * m         = method to run
     * _wpnonce  = WordPress Nonce
     * display   = json,html
     * Naming Conventions
     * Method names will be prefixed with "ajax_" and then run through the Inflector to camelize it
     *     - eg: "doThing" would become "ajaxDoThing", so you need a method in your class called "ajaxDoThing"
     * Classes can be whatever you want. They are expected to be namespaces to \Ecs\Modules
     * Output can be rendered as JSON, or HTML
     * Generate a nonce: wp_create_nonce('execute_ajax_nonce');
    public function executeAjax()
        try {
            // We expect a valid wp nonce
            if (!isset($_REQUEST['_wpnonce']) || !wp_verify_nonce($_REQUEST['_wpnonce'], 'execute_ajax_nonce')) {
                throw new \Exception('Invalid ajax request');

            // Make sure we have a class and a method to execute
            if (!isset($_REQUEST['c']) && !isset($_REQUEST['m'])) {
                throw new \Exception('Invalid params in ajax request');

            // Make sure that the requested class exists and instantiate it
            $c = filter_var($_REQUEST['c'], FILTER_SANITIZE_STRING);
            $class = "\Ecs\\Modules\\$c";

            if (!class_exists($class)) {
                throw new \Exception('Class does not exist');

            $Obj = new $class();

            // Add our prefix and camelize the requested method
            // eg: "method" becomes "ajaxMethod"
            // eg: "do_thing" becomes "ajaxDoThing", or "doThing" becomes "ajaxDoThing"
            $Inflector = new \Ecs\Core\Inflector();
            $m = $Inflector->camelize('ajax_' . filter_var($_REQUEST['m'], FILTER_SANITIZE_STRING));

            // Make sure that the requested method exists in our object
            if (!method_exists($Obj, $m)) {
                throw new \Exception('Ajax method does not exist');

            // Execute
            $result = $Obj->$m();

            // Render the response

        } catch (\Exception $e) {
            \Ecs\Helpers\json_response(array('error' => $e->getMessage()));

        // Make sure this thing dies so it never echoes back that damn zero.


Reno Linux Users Group (RLUG) responsive website redesign

I recently launched a new website for the Reno Linux Users Group (RLUG). It’s a custom theme on top of WordPress.

It’s a custom responsive website that integrates with the Meetup.com API to sync the monthly RLUG meetings to the site. The custom theme is based around my sort-of-framework for WordPress theme development. The front-end¬†is built using Grunt, Sass, and jQuery. I am using composer and a custom framework for the backend.