I’m a full-stack developer with a passion for coding clean, semantic, and functional websites and applications. I do a lot of PHP, I dabble in Rails, and I enjoy using HTML, CSS, and JavaScript to build slick, modern interfaces. By day, I’m working as a Lead Web Engineer at 10up.

Over the past few years, I’ve developed quite a fondness for WordPress, the platform on which this site is built (You can view the source of this site over on GitHub). You may have come across one of my WordPress plugins, WP Password Generator or WP Client Reference, both of which are available through the WordPress plugin repository.

Latest Blog Posts

I just launched the Engineering @ Growella blog

As you may be aware, I joined a Cincinnati-based startup, Growella, as their Director of Technology in mid-November. Since joining, I’ve been hard at work building our site (which is slated to launch within the next few weeks), building our hosting infrastructure, and generally being the point-person for all things technological at the company.

I’m already learning a lot in my new role, and I wanted an outlet to be able to share those things. I’m also very fortunate that the rest of the company embraces open source software, so I wanted a place (besides this blog) to share what Growella has been working on, the problems we’ve been solving, and any releases of new software.

With all of that in mind, I’m proud to announce that about an hour ago we launched the Engineering @ Growella blog.

Using symlinks for WordPress MU plugins

If you haven’t run into them before, WordPress Must-Use (MU) plugins can be a great way to say “no, seriously, my WordPress site needs this plugin in order to function”. Other times, MU plugins may be used to activate required functionality that site maintainers don’t want the site editorial team to have to worry about (for example, caching plugins like Batcache).

There are a lot of things that can be done with MU plugins, but there’s one major limitation right out of the gate: WordPress MU plugins cannot run in sub-directories.

Custom field IDs for Gravity Forms

If you haven’t had the chance to work with it before, Gravity Forms is pretty fantastic. I was first turned onto it a few years ago while I was at Buckeye Interactive, where it was a mainstay across most of our client sites. Besides presenting an easy-to-manage interface for building forms, the plugin also makes good use of the WordPress Plugin API (thus making my life way easier) and has a vibrant ecosystem of official and unofficial add-ons.

One area where Gravity Forms could stand to improve, however, is making it easier to identify fields. Let’s say, for example, we have a form where we’re collecting a name and an email address; outside of assuming that the regular text field is the name and the input[type="email"] is the email address, Gravity Forms doesn’t really have a straight-forward way to identify fields when you’re doing extra work with submissions (like sending them to a newsletter or a CRM system).

In my new role as Director of Technology at Growella, one of the first things I needed to figure out was how we could reliably map Gravity Forms submissions into third-party tools.

Get your geeky fill on my blog!