Giving Gutenberg a Kick

This post is written with WordPress’ new fancy-pants editor, Gutenberg. WordPress version 5.0 is coming out very soon, likely in the next couple of weeks. Gutenberg has already been merged into core, so it will be interesting to see how things go post-5.0. I wanted to see how it ‘felt’ to write a post with Gutenberg, so here goes!

Weird stuff

The first thing I find weird about the writing experience with Gutenberg is that removing a block is counter-intuitive. Hitting backspace and having to delete reams of text is a bit funny. I would have thought that there would be a garbage can or something to remove a block.

(upon further investigation it appears there is a garbage can hidden under the more info dots ¯_(ツ)_/¯)

It’s also a bit weird personally _not_ writing in markdown mode, but that’s not really an issue with GB in particular.

I’m also not really sold on the concept of blocks, but I’m old and crusty at this point. I’m also a programmer, so I like text blobs!

I also think it’s weird that you can’t select text like you would in an editor. No way to select text from a bunch of blocks at once.

Good stuff

I think once people get used to the new editor it’ll be amazing for freelancers and agencies. It’s a tonne more feature-ful than the old editor. Especially for your average content editor. No need for crazy HTML in the post content to get a custom layout. No need for a bloated page builder either.

I think it’s also great the WP is pushing forward with a modern JS approach. That’s where things are going and having GB around in core will force WP devs to pick up things like ESNext and React. So I think that will drag us all forward. ?


I also wrote this post in dev and used WP Migrate DB Pro to deploy it live. Worked well!

Nginx, Let’s Encrypt and taking my own server down ?

Simon Fitall

If you pay attention to Google and it’s indexing rules, you’ve probably heard that you need an SSL certificate on your site. I’ve known this for a while and my personal site at wasn’t a high priority situation.

Welp, I was bored one night and decided it was about time to get one of those fancy-pants free Let’s Encrypt cert’s installed on my old Linode server.

There are tons of resources on the internet that outline how to get an SSL certificate installed on your site, so I’m not going to go over that portion. What I will go over is how blindly following them can take down your server…

You see, most tutorials want you to use Certbot to install your certificate and configure Nginx.

certbot --nginx -d

Seems harmless enough, no? That little --nginx flag, if you didn’t read the fine print, will modify your virtual host config. Yeah. There’s an option when setting up the certificate to redirect all HTTP traffic to HTTPS, and obviously I said ‘sure’.

And queue the redirect loop. Site monitor email deluge, Twitter ‘the site is DOWN’ DM’s…

Everything is going swimmingly!

I managed to solve this issue by removing the following block in the /etc/nginx/sites-available/ virtual host declaration:

    if ($host = {
       return 301 https://$host$request_uri;
    } # managed by Certbot

And adding a simpler redirect block, just to be reallllly clear, at the top of the file:

        listen 80;
        return 301 https://$server_name$request_uri;

So what’s the lesson here kids? The lesson is that if you’re using a tool that will ‘automagically’ do something for you, and it sounds too good to be true, it probably is.

If you’re wondering what the final virtual host block looks like:

        listen 80;
        return 301 https://$server_name$request_uri;
server {

        listen 80 default_server;
        #listen [::]:80 default_server ipv6only=on;

        root /usr/share/nginx/sites/;
        index index.php index.html;

        location / {
                try_files $uri $uri/ /index.php?$args;

        location ~ \.php$ {
                try_files $uri =404;
                fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
                fastcgi_index index.php;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                include fastcgi_params;

    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot


Using async await with jQuery’s $.ajax

Photo by Denys Nevozhai on Unsplash

If you’re like me, you’re probably stuck using jQuery more often than not. It’s everywhere, and to be honest it’s a solid, mature library. It’s also often already loaded on the page, especially if you’re working with WordPress.

Outside of DOM manipulations (which you can now do mostly with native JS), jQuery’s $.ajax() method is really handy and works well.

But did you know that this function provides Promise interface out of the box? I recently remembered this and I thought to myself:

Hmm I wonder if I can use async/await with jQuery’s $.ajax().

Turns out, you can!

The setup

Async/await is really new still, it’s only in the ES2017 spec, so you’ll need to use a transpiler like Babel to get it working in older browsers. Most of us are using Babel anyway with our bundlers (Webpack, Browserify), so this isn’t a huge deal.

Assuming you already have Babel installed and configured, the first thing you’ll need to do is get Babel to use the ‘env’ preset. In your .babelrc file, add these lines:

"presets": ["babel-preset-env"],

You’ll also have to install this Babel preset and polyfill from npm: npm i -D babel-preset-env babel-polyfill.

Once that’s done you’ll also need to install this magic plugin for Babel: npm i -D babel-plugin-transform-async-to-generator. This is the key package that lets you use async/await in your code. I should mention that this simply gets Babel to compile the async/await syntax to ES2015 generators, so if you’re not targeting most modern browsers keep that in mind.

The next, and FINAL thing you need to do is use the babel-polyfill module in your code. You can use a Webpack loader if you like, or just include the package in your source files:

import 'babel-polyfill';


Ok, now we’re ready to go. Start up Webpack and let’s start using async/await!

Don’t call me, maybe

Back in the day you had to use $.ajax() like this:

//Function wrapper that confuses alot of devs because async code works differently
function doAjax() {
        url: ajaxurl,
        type: 'POST',
        data: {
            stuff: "here"
        success: function (data) {
            //wacky nested anonymous callbacks go here
            var something_but_not_really = data;
        error: function (jqXHR, textStatus, errorThrown) {
            // Empty most of the time...

    return something_but_not_really

I know when I was a junior dev I had no idea why something_but_not_really was undefined. I had to learn about callbacks a billion times ?.

But now…

async function doAjax(args) {

    const result = await $.ajax({
        url: ajaxurl,
        type: 'POST',
        data: args

    return result;

And result actually returns the AJAX result. Cool right?

The big benefit of async/await is that it makes asynchronous code appear synchronous. As in, do this thing, wait for it to finish and then give me the result.


Notice anything missing in our new function? Yep, error handling is non-existent. Fortunately, since async/await is essentially synchronous, you can use try...catch()!!!

async function doAjax(args) {
    let result;

    try {
        result = await $.ajax({
            url: ajaxurl,
            type: 'POST',
            data: args

        return result;
    } catch (error) {

And there you have it. Some error catching built in. Now, there’s other ways to handle errors with async/await, but they’re a little more complex.

The other thing to keep in mind now, since we’re returning the result of an awaited function, result will equal a Promise instance. You have 2 options with what you can do with the result.

The first option is to make sure that you use await when calling doAjax() later on.

// Elsewhere in code, inside an async function
const stuff = await doAjax();

The other option is to use the Promise interface and roll that way:

doAjax().then( (data) => doStuff(data) )

Promises aren’t all that bad, and can look cleaner or be easier to work with, depending. I’ve found that using ES2015 classes it’s sometimes easier to use the Promise interface, so YMMV.

But that’s it – go get your $.ajax() using async/await today!

JavaScript’s cryptic ‘this’ – what, when and why

*Photo by Tarun Ram on Unsplash

Before MDN started to organize their JavaScript documentation, finding answers to your JavaScript questions often landed you on Stack Overflow.

Welp, these days MDN has mostly done away with that practice, that is, except if you’re looking for answers around the usage of JavaScript’s this keyword.

The documentation is great, it really is, but it’s not exactly full of helpful, real-world examples. So I thought I’d put together a few tips and tricks about the ever so magical this keyword.

Old-skool JS

“Back in my day we had to alert out our objects!”

Ok, so yeah, if you run console.log(this) in your dev console you’ll generally see that by default, this = Window{}. Super helpful…?

It gets more interesting when you check the value of this inside a function:

function mahFunc(){

// Window{}

You should still see the Window object. Ok so, nothing new here.

But what if you add 'use strict'?

function mahFunc(){
    'use strict'
// undefined


Ok now, but what if you call mahFunc() on the Window global (since it’s a global function)?

function mahFunc(){
    'use strict'

// Window


Strict mode is a funny beast, but it generally makes errors more obvious and cleans up your JavaScript. Something not mentioned in the MDN docs is that bundlers/loaders/concatenators like Webpack/Browserify, may have strict mode enabled by default. You might end up with some wacky loader that enables it with out you knowing. So keep an eye out if you ever see your this call returning something funny.

Call me plz

Ok so this in a global context is weird, but who doesn’t use objects and ES2015 classes these days? If you’d like to use a different value for this, (as-in not undefined or Window) inside your function, you can pass a context with .call() and .apply(). I always remember these with ‘’.

function mahFunc(){

const config = {

        //do step one

        //do step 2

//{stepOne: ƒ, stepTwo: ƒ}

And there you go. this references the object passed in argument to .call(). Cool right?

This way you’re able to specify a context for a function. It’s super handy and what a lot of frameworks and bundlers use internally – check out your Webpack bundles!

I won’t go over all the possible cases/uses of this, there’s quite a few and the MDN doc is really good.

It’s important to remember this ?.

Open Source, PHP and Visual Studio Code

Lately, VS Code has been getting a lot of hype in the dev community. It’s been around since for a few years and TBH is a really sweet editor. Lots of great extensions and community support. It’s also quite fast (for an Electron app ?) and the peeps and Microsoft seem to be keeping it up to date and iterating quickly.

However, anything you really need to work with PHP is missing by default. I believe this is by design to encourage a vibrant extensions community. Luckily, like most languages, there’s a vibrant open source PHP extension community. There’s a few great extensions for PHP: PHP IntelliSense, PHP Debug (both by the same developer) as well as PHP Intelliphense (#wat?). There’s even a really great intro by Jeffrey Way on Laracasts outlining everything you need to do to get VS Code set up for PHP dev.

Some of the PHP packages work fine and have over a million installs (!!!). Sometimes, however, they don’t work. Like, at all. Just today, the PHP Debug extension completely broke. Luckily the developer was paying attention and rolled out a fix within hours. Pretty awesome support for an open-source product!

However, if you paid for the editor, say something like PHPStorm, you could go and raise an issue on their support channel. You could complain about the product not working, rightly so, as you’ve paid for the right! As a ‘customer’ you have a certain amount of clout with a vendor like Jetbrains. This is NOT the case with open source, and I feel that we developers forget this.

This is where I take issue. I’m all for open source software. I’ve built my career on it. The issue is that the developer for this plugin had to fix the issue himself. There’s an expectation there that he HAS to fix the issue, and do it RIGHT NOW. And if it’s not done immediately people freak out, complain on Twitter, write a blog post about, have a cow ?, man.

Open source is just that, open. If you find an issue with a plugin, editor, extension or WHATEVER, see if you can fix it! That’s the whole point. Let’s not throw our hands up and complain, let’s get our hands dirty and fix the damn thing.

That’s what open source is all about. Let’s remember that.


PHPStorm, MAMP and Xdebug – How to keep (some of) your hair

I’m mostly logging this here for my own benefit, but if the Google gods brought your here, sweet!

Just came across another fun quirk with running Xdebug, MAMP and PHPStorm together. ????

I’ve talked about this combination causing me issues in the past, but this is a whole new situation that killed a couple hours for me.

So, it appears that for PHPStorm to pick up Xdebug correctly, the xdebug.remote_host variable needs to be set correctly. It normally is, if you copy-pasta some of the tutorials on the internet.

Unfortunately, for some reason, this Monday morning, setting this value to localhost no longer worked. Why? Welp, localhost is pointing to an invalid folder location, according to MAMP. Apparently this was enough for PHPStorm to freak out and just not run Xdebug. Period.


So how’d I figure out this was the reason for Xdebug throwing up?

The PHPStorm docs of course! Wayyyyy at the bottom of this page it’s plainly stated:

Remote host is configured as ‘localhost’ despite server host is probably not local

The URL to validation script contains something different from localhost, but the xdebug.remote_host value is not set and so is using the default value of localhost, or is set to localhost or


JavaScript build tooling and the CLI

Something that’s come up recently in the front-end world is the topic of a learning curve and JavaScript tooling such and Webpack and Babel. While I agree that new tooling can sometimes be a pain to learn, since when did being a web developer/programmer/rockstar not require learning new things? I mean, learning the CLI is one thing, but it’s not suuuuper difficult and is definitely a skill that will serve you well in your career. On top of that, front-end build tooling has been around for a while, first with Grunt and then Gulp. Does Webpack make things that much more difficult?

The argument I’m making is partially around React and how Webpack (or similar) is required. To me, this doesn’t seem like a problem, as many languages require compilation during a build step. I see the build step and associated tooling a good thing, as it allows for more streamlined and complex programming concepts to be brought into front-end development.

If you’re worried about learning something like the Webpack build process, Create React App has got all the setup jank covered. In Vue, there’s vue-cli which similarly gets you set up. In both cases all it takes to get up and running is npm install then npm start. That’s not too bad!

I guess what I’m saying, if all this ‘new’ stuff bothers you as a developer, it might be time to 1.) upgrade your skills, or 2.) do something else. Things aren’t slowing down any time soon in the front-end landscape, better get on the wagon or jump off!

Hey Linode!

After getting my VPS shut down for a second time by Digital Ocean (which apparently was issuing DOS network packets – no further explanation from DO), I decided to give Linode another whirl.

And here we are.

Running Ubuntu 16.04 LTS and it’s a smooth as butta.

Software for now:

  • nginx 1.10
  • PHP 7.0.8
  • MySQL 5.7.15

Will also probably get Node v6 running up there soon too.

MAMP, Xdebug, PHPStorm and symlink madness

Ask any PHP developer and they’ll tell you Xdebug is the best thing since sliced bread. While true, it’s also one of the biggest pain in the asses to setup. I’ve probably set it up, in various incarnations, close to 10 times.

There’s always something that get’s me caught up and messed up. This time I decided to document how I was able to get it working this time, so hopefully I don’t have suffer through this again.

I followed Michael Novotny’s post on this, and it almost works. There’s just one missing piece, for me, and that was how to handle symlinks in your plugins.

This overview assumes a few things. You’re on a recent version of OSX, you have MAMP Pro 3 installed, and you’re using PHPStorm.

Step 0: Use the same version of PHP for your CLI and your webserver.

Time and again I’ve seen people have issues with their CLI PHP version and Web server PHP version not matching up. This can cause all sorts of weirdness, especially with Xdebug, so make sure you’re using your MAMP version of PHP on your CLI.

This can be as simple as adding the MAMP PHP version to your $PATH.

In your ~/.bash_profile file you can add something like this.

echo $PATH | grep -q -s "/Applications/MAMP/bin/php/php5.6.10/bin"
if [ $? -eq 1 ] ; then
export MAMP_PATH=/Applications/MAMP/bin/php/php5.6.10/bin

Step 1:Make sure Xdebug is installed.

This one’s a gimme, but still a point worth making to cover all the bases. Make sure you’ve got Xdebug running and remote_enable=1 is set in your php.ini. There’s plenty of resources on the inter-web’s for this.

You can check if Xdebug is available, by running php --version in your CLI. You can further check what kind of Xdebug settings your have enabled by running php -i | grep xdebug

Step 2: Setting up PHPStorm

Make sure PHPStorm is using the same PHP Interpreter you’re using for everything else. You can set this in Preferences > Languages & Frameworks > PHP and selecting the MAMP PHP version you’re using.


After that, essentially follow Michael’s guide for setting up PHPStorm with the debug configurations, once PHP is all set up.

Step 3: Symlinks

If you’re using plugins in your local PHP install that are symlinked (and many plugin developers do this), make sure you map those folders for Xdebug and PHPStorm! This is where I got caught many times. I even needed to map the base of my WP install, since I had checked the ‘Use path mappings’ setting.


For me, that’s all it took to get things running. Without the explicit path mappings for the symlinks, Xdebug half worked – which was super confusing…

I should note that if you’re running multiple sites on your MAMP install, and 2 of these sites are talking to each other in any way (via AJAX or the WP Rest API etc.), make sure ONLY ONE is running Xdebug. Not sure what the reason is, but the workaround is easy enough. Just use another version of PHP within MAMP, one that doesn’t use Xdebug.

Hope this helps someone else.

WordPress Jetpack contact forms – AJAX

EDIT, May 9, 2016

I noticed that the form wouldn’t submit when not logged in, so I’ve updated the gist to include a check to see if a user is logged in. 

Jetpack is awesome for a lot of things. Unfortunately, one of the things that it isn’t so great for is submitting it’s contact form via AJAX. I’ve looked into this before and decided I might as well hack something together that ‘kind of works’ ™.

Here’s the full working code, I’ll go into a bit below:

Basically, all you do is fake-send the form via ajax, parse the returned page’s HTML and look for an H3 tag with the submission message.