Aaron Eaton

Development

Not for long

by Leave a Comment

So many of us (developers) suffer from an extreme form of hubris.

My programming language of choice is the “right” one.

My chosen framework is infinitely better than the one you use.

My build process runs circles around yours.

My IDE makes yours look like a child’s toy.

How many times have you looked at a project of yours from a year ago and thought, “Hey! I was a genius back then!”? More than likely you think your code was crap and you made some really terrible decisions. Those decisions, though, were the “right” ones at the time. They got the job done and you shipped something.

In web development being “right”, if even attainable, is only a temporary state.

Fix your git hooks when using Tower

by Leave a Comment

One of our newest OptinMonster developers has already made a big splash by introducing even more automation to our development flow. For the past two years (TWO!) this has been our usual conversation after pushing some changes:

The changes you pushed aren’t working.

(┛◉Д◉)┛彡┻━┻

Do I need to run anything after pulling this down?

Yeah. composer install in the core plugin and theme. npm install in the theme. gulp scripts in the theme.

Ah! There we go!

It was time to put an end to it. The new dev created a few git hooks, installed with a script, that run all of the necessary build steps after a pull from our GitHub repository. Only problem is the hooks don’t work if you’re using Tower or any other GUI for git. Luckily the fix is simple. Add this to the very top of all of your git hook scripts:

export PATH=$PATH:/usr/local/bin:/usr/local/sbin

This give Tower the correct paths to find whatever scripts you use in your git hooks. In our case it was node.

Disable comments on all WordPress pages at once

by Leave a Comment

Comments on pages by default. Not sure why that is a thing but we’re talking about 13 year old software here. It’s easy enough to turn off comments manually. Page by page. Why do work by hand when you could automate it?

Turns out it’s simple enough to turn off comments on every single page on your site with a couple of lines of code. You can add this to your theme’s functions.php file, your core functionality plugin or wherever else you deem fit.

Stay tuned for more in my series titled “How to fix things that shouldn’t be this way”.

Using WP_Mock with PhpSpec

by Leave a Comment

Over the last few weeks I’ve begun a push to increase our test coverage in OptinMonster with PhpSpec. Doing so will allow the team to release features with greater confidence and reduce bugs throughout the codebase. As tests were being written I quickly ran into issues mocking WordPress functions. Yep! OptinMonster is written on top of WordPress!

After trying out a couple of different testing frameworks we’ve settled on PhpSpec as our framework of choice. You and I could argue over the merits of our decision but it comes down to this: Compared to the dominant PHPUnit, PhpSpec seems to be more conducive to onboarding new or junior developers and the tests read more like plain English. Which of the tests below read easier for you?

What’s WordPress got to do with this?

With frameworks architected in an object-oriented manner from the very beginning (i.e. Laravel, Symfony) mocking dependencies is a trivial matter. Those frameworks avoid placing functions in the global scope and when they do those functions are usually wrappers for encapsulated functionality. WordPress is a different story. Now, this isn’t an article about the pros & cons of WordPress. There’s been more than enough written on that subject. So, the point is mocking most of WordPress’ functionality which presents an interesting challenge. Thankfully the ever-hiring team at 10up has created a mocking framework specifically for WordPress called WP_Mock. This creates an API that makes WordPress-related mocks quick and painless.

Wait. What are mocks?

In unit testing mocks are basically copies of dependencies within your code. The purpose is to isolate the behavior of the class/methods you are testing from those dependencies. The hope is those dependencies already have good unit tests behind them so you can easily fake their behavior.

Great. Let’s get to the point.

With all of the explanations out of the way I can finally show you how to get WP_Mock working with PhpSpec. The WP_Mock documentation shows how to easily get up and running with PHPUnit and luckily the ideas translate over to PhpSpec really well. Instead of using setUp() and tearDown() PhpSpec provides similar methods called let() and letGo(). Those methods should be written as so:

https://gist.github.com/aaroneaton/9701eef8c3b18d3f9c9bd9191f47f012#file-phpspec-setup-php

With that in place we are free to use WP_Mock as we would in PHPUnit. Here’s a simple test for our Todo class. We need to make sure that when we call our save() method on the Todo that the proper WordPress function is called with specific arguments so that it can be saved to the database. Since we are mocking wp_insert_post() the database won’t actually be changed which greatly simplifies testing and helps us focus only on the code we are writing.

That’s it! If you have any questions about unit testing your own WordPress plugins let me know in the comments!

Improving the support ticket submission experience

by Leave a Comment

During the design phase of the new OptinMonster SaaS we realized that there was one killer feature that could set us apart from our competition. It wasn’t more beautiful themes, a super-duper form builder or a brand new type of optin form. Don’t get me wrong. All of those features are important to us and are in the works, but…

Our killer feature is outstanding customer support.

Without it we lose customers. We lose the opportunity to turn the inevitable frustrated customer into a raving fan.

Yesterday Syed Balkhi wrote about how we at OptinMonster handle our customer support from submission to resolution. Today I’d like to take a deeper dive into the support ticket submission experience.

We have focused on creating lines of defense for our support team. While we love talking to our customers, every question answered before a ticket is submitted is a big win for us. Why?

  1. OptinMonster is a small team. We don’t have dozens of staff to throw at customer support.
  2. The less time it takes a customer to get a resolution, the happier they are. Depending on the complexity of the issue, submitting a support ticket with us (or anyone, really) will almost guarantee a 12 hour time-to-resolution.

For those reasons, every customer is funneled through the documentation page before submitting a support ticket. Customers are provided with two different avenues to find what they are looking for, browse or search.

Browsing

OptinMonster documentation categories

All of our documentation is split into 6 categories. We found that 6 was enough to find what you’re looking for but not so many as to overwhelm the customer with choices. Documents can be found in just two clicks.

Real-time search

Searching the OptinMonster documentation

The jewel of the documentation page is our real-time search. By entering just a few characters in to the search box you can find a list of related articles updating automatically below. All of the search functionality happens on the client-side.

How do we do it? We use a fuzzy-matching script called Fuse to search an array containing every help document.

When a customer hits the documentation page, WordPress collects every post of the optinmonster-docs type, strips it down to just the title and permalink, and sends it to the browser via wp_localize_script(). Now that we have all of this info in the browser as a Javascript array we can pass it along to Fuse:

Any time the user types into the search box the section below is updated with the related docs. We must also rate-limit the input by using the Underscore.js method _.throttle. This is done to keep those fast typers from overwhelming their browser.

If you noticed above, we also make use of Underscore tempting to update the docs list. Here’s that template:

Make it super simple to submit a ticket

In the event we do not have documentation for the feature or issue the customer was searching for, we make it extremely easy for them to submit a ticket. When ‘Submit a Ticket’ is clicked they are directed to our ticket submission form which has been pre-populated with all of their customer information. All the customer needs to do is select their affected site, describe the problem and hit ‘Submit’.

We also take this opportunity to learn more about what our customers look for before submitting the ticket. The ‘Submit a Ticket’ button on the documentation page has a little magic added to it. When clicked, we take whatever they customer typed into the search field and add it as a query argument in the submission URL.

Data is collected on this query argument during form submission so we can learn exactly where our support line-of-defense failed and correct it for the future. Once we get a few data points containing the same terms we know a support document needs to be written on the subject.

We’ve come a long way

Compared to our old support and documentation workflow I think we’ve made great strides. Customers are now able to find an answer to their question easier than ever before and we are better equipped to adapt to their changing needs.

Comparison of old and new documentation sites

I can see us needing to optimize the search functionality in the future. Fuse.js can handle a great number of documents but we must remain vigilant when it comes to front-end speed and experience. There’s also the question of how much data wp_localize_script() can handle.

Are you a digital product manager? What improvements can you make to your own support workflow?

And to customers, what are your biggest frustrations when it comes to finding solutions to your problems?

Let me know in the comments.

Finally. An easy way to style dropdowns (select elements)

by Leave a Comment

Do you know what I hate the most about CSS? Styling form elements.

Yes, most browsers provide some sensible defaults, but clients never seem to want those in their designs. Good luck getting the form to look the same across all browsers. Some even say it’s downright impossible.

Do you know what I loathe about CSS? Styling dropdowns (select elements).

It may be simple to style the select box itself, but what about the options? As far as I know, no browser provides a way to do so.

On a recent client project the designer requested custom styling for both the select box and its options. After throwing a fit for 30 seconds I went to work on finding someone who had been kind enough to do this for me. Eventually I came across Select.js from the wonderful team at HubSpot.

How does it work? Well. I haven’t really looked into the code too much so for now I’ll just say “Magic.” All you have to do to use it is include the proper javascript & CSS files, add 3 lines of JS to your project and you’re good to go! Check out the documentation for all of the details. It’s even easily themeable!

If you’re looking for something geared towards more complex dropdowns, take a look at Chosen from the Harvest team.