There is a long-running discussion at LexBlog about the benefits and perils of third-party solutions. This discussion has been going on for so long that if you look closely enough, you can find evidence of it in this A List Apart post from 2014 by our own Scott Fennell. This post, is also the subject of Scott’s WordCamp Portland Maine talk this year, so the battle clearly rages on (shameless plug for Scott/WordCamp Portland Maine here – he’s in some rarefied air with this speaker list!).

As with most things, I find my opinions on this subject to be complex. On the one hand, I’ve personally seen what happens when a site manager grows accustomed to a WordPress plugin only to see the support for it slowly fade as the developer (or company) behind it slows their involvement in supporting and managing the codebase. On the other hand, I’ve npm install‘d my way to freedom from more issues than I’d like to admit.

Today was a day where I was saved by a third-party solution. WP Crontrol, a plugin from John Blackbourn, is a handy tool that provides a user interface for CRUDing WP-cron events. Typically, the problems that plague the WP-cron elude us as WP Engine provides a true cron that we use on all of our environments to ensure that scheduled actions take place when our publishers (and us) expect them to. However, this isn’t a perfect solution as long-running crons can cause a bottleneck to appear at the top of the cron stack with those cron jobs stopping others from firing.  This is a pretty frustrating issue for someone that just wants their scheduled post to go live without worrying, and difficult to troubleshoot as cron events are held off in the database without a great way to manage them.

Enter WP Crontrol. After installing this plugin, I was able to easily see a list of cron events that clearly should have fired by now. After deleting the oldest cron, the rest cleared up in short order. 

Now, Mr. Blackbourn is a well-known quantity in the WordPress realm. We use his plugin Query Monitor regularly, he’s a core contributor, and works at Human Made, a highly-regarded WordPress agency. This is a far cry from the sorts of solutions that Scott or other members of the LexBlog product would typically have concerns about.

But where do you draw the line? As I eluded to above, npm is something I’ve grown accustomed to using, and many of those modules have dependency chains that stink to high heaven. LexBlog taps into a number of third-party plugins that are now a core part of our product offering. WordPress itself is a third-party solution that we have built our business upon. There is no escaping the power of these tools, and I wouldn’t want to even if I could. 

The trick, as Scott so eloquently puts it at the end of his post on A List Apart, is knowing when to leap into someone’s helping hands, and knowing when to take a stand:

It’s not that third parties are bad per se. It’s just that the modern web team strikes me as a strange place: not only do we stand on the shoulders of giants, we do so without getting to know them first—and we hoist our organizations and clients up there, too.

So look before you leap. It’s never as easy as just installing and forgetting. 

I’ve been writing WordPress themes and plugins for about a decade and recently I’ve been putting more effort into curating a personal “boilerplate” folder for new themes and plugins. In reading through it, I can see what concepts and components have become habitual for me, regardless of the subject matter of the project.

  • Some `Constant` Companions

    I declare the following constants:

    The purpose of this block is to introduce some basic data about our project, into the global scope, in a concise convenient way, that cannot be altered.

  • Include Font Awesome

    It’s pretty much a given that any project will involve icons, and I prefer FontAwesome:

    https://gist.github.com/scofennell/463d6fef2eb10a296cd758d96ce82ad6

  • The State of States

    A huge part of my boilerplate is just providing a wide platform for presenting and handling form inputs. It seems a little odd, but I’ve not come up with a better strategy than to just include this in every project:

    God help me if a state ever secedes!

  • Very Classy

    I set up (php) classes to add (css) classes to both the body tag, and each post:

    This fits in well with my high regard for SMACSS.

  • Staying Up To Date with Updates

    I dislike the normal hook system for performing action on theme and plugin activation, so I instead have some code that executes everytime the version number increases (which it does upon first install):

    Because this adds an extra query, I only have this running for projects that register things in the database such as roles, or other various high-value routines like rewrites.

  • Agoification

    Human time diffs can be annoying, especially if you care about time zones. I don’t regret having this available in every project:

There are quite a few other things common to all of my new projects, but this is a good cross-section. I wish I was better about really capturing every lesson from every new project, but in reality I’m happy if I remember to curate just one. Over time it’s become a valuable library and it also inspires me to push the quality of my code on each project, in the hope that something does emerge as boilerplate worthy.

Some years ago when I first interviewed with LexBlog, the CTO reiterated several times that he really wanted me to be fluent in plugins, in addition to themes. I knew my way around plugins generally, but I liked the vibe I got from the interview and I wanted the job to work out well, so I stopped at Barnes and Noble on the way home:

A career.

This book changed my working life profoundly. It’s no exaggeration to say that the reason I have a career, a home, a family, is this book. What’s funny too, is that it still holds up incredibly well. Very few concepts in these pages have fallen by the wayside or require significant updating in order to use today. I don’t think you can say that about many technology books.

I’ve probably recommended this book to dozens of people. My own copy is dog-eared and duct-taped. Recently when I moved my family from Alaska to Maine and was cutting down on my material possessions, this book made the cut. It traversed the western hemisphere!

I’ve been a big proponent of Zendesk after using their product(s) for several years at LexBlog. Like all businesses, LexBlog has gone through a variety of systems and processes cycles, and how we manage inbound requests is no exception. As I mentioned in my last post, a huge push over the last several years has been the shift from the cycle of inbox to development/design requests back to inbox to a more distributed approach through the use of Zendesk’s ticketing system. Not only was the old approach to communication causing headaches for all project members (have you ever played the telephone game?), it created silos where only a single account/project manager could manage the projects they were responsible for. If for some reason, that person was sick for a week, their projects may go untended or be utterly confusing for someone to step in and address.

Something that we’ve worked hard to do in recent years is choose software that we can easily work with outside of the box. It’s rare that we find something that fits what we need without customization, and having the ability to extend the core product is vital.

In that regard, I can’t say enough good things about working with Zendesk. The content in our contextual support bubble is dynamically populated if opened on a page where there is support documentation that may be helpful – this is powered by the Web Widget API. The support center in each site’s administrative area is powered by the Core API. And much of my work over the last several weeks has been with Zendesk’s Help Center templates, which are a mixture of HTML, CSS, JS, and Handlebars.

I also had the chance to extend LexBlog’s visual regression testing application to be more of a dashboard application for managing all things related to LexBlog’s systems by working with the Help Center API to provide Ted Cox, our technical writer, with the tools needed to better manage the content inside our support center through a variety of API calls and new React components (as a brief aside, if you have a React application and ever need to take the results of an API call and jam them into a CSV, I love this package).

Overall, a lot of good things to say about Zendesk, and probably even more as we’re starting to wrap up our work on redesigning LexBlog’s support center!

Accessibility, also known as “a11y”, refers to how well a website functions for people with disabilities. Common examples of disabilities in this space include visual conditions like color-blindness, vestibular conditions like animation nausea, and motor disabilities such as cerebral palsy, which happens to be the focus of this article.

The Feature

I am tasked with creating a “jump menu” for navigating tag archives.  Something like this:

Animated GIF - Find & Share on GIPHY

There is no submit button.  By merely selecting a menu item, the page navigates to that particular tag archive.  The premise of this UI is that, by not having to click a “submit” button, we save the user time and decision-making, hopefully improving the experience.

The Problem

This all works well enough, assuming you’re using a mouse.  But what happens if you’re using a keyboard?  Continue Reading How We do Accessibility: A Case Study

JavaScript wrangling has been among the most controversial topics in front-end development for a long time now. It’s right up there with tabs vs spaces and french press vs pour over. Here’s how we do at LexBlog in all current and foreseeable projects.

The Global Object

We kick off a plugin/theme JS file with a global that is namespaced for that project, containing handy functions used throughout.  Example:

Continue Reading How We Boilerplate our JavaScript

I often work with exactly one plugin active, other than the plugin I’m working on and its dependencies. That plugin is Query Monitor. QM adds a button to the admin bar that turns red when I make mistake, and reveals a treasure land of begun info when I click on it.

We go live to me making a mistake.

QM is completely free and has inspired a vibrant community of side-plugins, that hook in and provide even deeper debug info about specific topics. It’s updated frequently and is active on over 30,000 websites. The author, John Blackbourne, actively engages feedback on Twitter. We use it a lot here at LexBlog. It’s not a hard policy per se, but I strongly recommend to my teammates that they never work without it.

John Steinbeck once said to write for an audience of one:

In writing, your audience is one single reader. I have found that sometimes it helps to pick out one person—a real person you know, or an imagined person and write to that one.

Similarly, I think many of the best plugins come about when, as developers, we code for our own needs — our own audience of one. I’ve also heard this called “dogfooding” and I like it.

Query Monitor has taught me about my own mistakes and failings thousands of times. On this day of giving thanks, I give thanks to you, Query Monitor!

I try not to get overly technical in this space, but when I get a chance to implement one of my very favorite programming techniques, I have a hard time keeping it to myself.  I want to tell you about recursion.  Per wikipedia:

A common method of simplification is to divide a problem into subproblems of the same type […] where problems are solved by solving smaller and smaller instances.

Here’s the example.  Earlier this week I was dealing with a problem where I needed to turn the english words “true” and “false” into the boolean values true and false.  This would be easy enough to do if it were simply one instance of the words:

Continue Reading Recursion

There’s nothing wrong with making mistakes, in fact I highly recommend it. However, if I make a mistake and I have no plan for preventing it from happening again, that feels pretty lame. One mistake I have made before, is forgetting if I am on a live installation or a staging installation. When I say live and staging, I’m referring to WP-Engine’s excellent system.

I made this mistake recently while working on a site for a friend, and it was embarrassing. I decided that a good way to prevent it, would be to add an obvious visual cue to alert the user when they are on a staging site. I found some time this week to write a small plugin that does exactly that:

See the yellow “hazard” tape at the bottom? If you click it, it fades out so it’s not in the way. It’s my way of saying, “Hey! You are on staging.”

Instead of hosting this plugin in our normal repository, I decided to host it on WordPress.org. That way I can use it on my friend’s site, in addition to our LexBlog sites. And so can you:

LXB Staging Reminder

Recently our reporting software, NewRelic, alerted us that some of our code was running slower than usual:

The graph depicts a dramatic decrease in performance on October 11.

I was able to trace it back to a recent update where, in order to make our code more flexible, I began to register and accept default values for various database settings:

New code to allow us to easily register default values for settings that have not yet been set.

Surprisingly, this added up to a palpable slowdown.  We have tons of options in our Apple Fritter theme, hundreds actually, so running this routine potentially hundreds of times per page load was turning out to be a drag.  Here’s what we’re doing now instead:

(Click the image to enlarge) If the value has not yet been set, we’ll actually set it to the default, instead of merely using the default.

See the difference?  If the value has not yet been set, and a default is available, I’ll use the default to set the value.  Therefore, in the future, we never have to go through the routine of locating the default value.

Front-end database writes like that are generally a bad practice.  To write is more expensive than to read.  But in this case, the database write is merely a gambit:

A gambit (from ancient Italian gambetto, meaning “to trip”) is a chess opening in which a player, more often White, sacrifices material, usually a pawn, with the hope of achieving a resulting advantageous position.

I’m paying a one-time penalty to never have to read the default value again.  You can see the subsequent reporting in NewRelic:

The original decrease in performance, followed by an even worse one, followed by restored performance.

Notice the spike in load time, followed by the dip.  The spike occurred on the first few page loads after I allowed for front-end database writes to populate a value.  After that, things actually accelerated to faster than they were before!