Counting Gutenberg Blocks

This week I was tasked with performing a quick audit on an existing client site for WordPress 5.0 compatibility. The site had already made use of Gutenberg so we were curious just how many blocks were in use.

For those of you who don’t know, Gutenberg blocks are stored in the post_content field and look something like this:


Now, since every block begins with the same pattern, <!-- wp:, we now have something we can target in a SQL query. The trick is to count the number of times that pattern occurs in each post_content field.

After a lot of research and consulting my amazing colleagues over at WebDevStudios I finally landed on a query that will get a count of every Gutenberg block published on your site. Here it is:

Plain Text

Just copypasta that query into your favorite MySQL client (or the cli if you’re hardcore) and you should see the magic number.

Screenshot of Sequel Pro showing the result of the SQL query above

Using remote XDebug with Visual Studio Code

I was happy in Jetbrains land. Everything was familiar. Everything fit into my workflow perfectly. For 4 years every bit of development was completed in PhpStorm. Then things started to go sour. Constant re-indexing would bring my computer to a crawl. RAM usage far exceeded that of Slack (yeah). And that’s just the start of it.

A few colleagues of mine began extolling the virtues of Visual Studio Code in the first half of this year. Given my jaded history with Microsoft I was, at first, put off by the idea of using a Microsoft IDE. Their preachings were ignored for a while.

But they kept preaching. And FOMO kicked in.

In September I decided to give VSC a chance. The inagaural project was a fully drag & drop campaign builder for OptinMonster. The project is 100% JS so it seemed like a perfect fit. It was, but I still found myself sneaking back to PhpStorm for all of my backend development. There was just too much missing in VSC for me to go all in.

Over time I was able to close all of those gaps except one: remote debugging. I, like most PHP developers these days, run my development environments on virtual machines. This means our language interpreters XDebug run within the confines of the VM. Visual Studio Code does not support this configuration out of the box so I’ve written up everything I learned.


You will need PHP 7+ with XDebug running on a virtual machine.

Install the necessary extension

Since VSC isn’t really set up for PHP from the get-go you’ll need to install the PHP Debug extension. This creates an adapter between XDebug and the built-in VSC debug functionality.

Make XDebug talk to the outside world

In your VM, open up php.ini and you’ll hopefully find a section for XDebug. Make sure the following settings exist:


Don’t forget to restart PHP after making this change!

Create the debug config

Debug configurations in VSC are, like every other config, a JSON file. You’ll need to create a configuration for PHP. Open up the Debug panel in VSC, click the gear icon (should have a red dot) and select PHP as your environment.

Setting up XDebug in VSCode

You should see a new file open up called launch.json.

Set up path mappings

The default PHP debug config will allow you to listen for remote XDebug sessions but you’ll likely need to tell VSC where to find your files on the server. Skipping this step really just renders the debug features worthless. Your config should look something like this:

Plain Text

You should set up all of the necessary path mappings. Their format should be "/path/on/server": "${workspaceRoot}/local/path".

Start debugging

Now start a debugging session (F5) and create a breakpoint in your code. If everything has been set up correctly the next time you load your app you’ll see all of the debug info in the VSC sidebar.

So with XDebug working beautifully in Visual Studio Code I’ve removed my last hurdle to switching.

Have any great tips or extensions to share for VSC? Hit me up on Twitter!

Simple Local Servers

When testing many facets of the OptinMonster embed code I find myself needing a clean & quick HTML page on almost a daily basis. For most tasks throwing some code into JSFiddle will do, but testing some of our more advanced targeting rules becomes onerous, if not impossible.

In comes a great little NPM package serve from the team over at Zeit that gives you a bare-bones web server from the terminal.

So without further ado, my process:

Install the package


Create the necessary files

I first create a new temporary directory and add an index.html file.


Add the HTML

I then place some boilerplate HTML in index.html along with the OptinMonster embed code.


Start the server

Back in the terminal and in the temporary directory, start the server with server ..

Terminal window displaying the command "serve ."

Once you see “Serving!” your page is ready to go!

View the page

You can now see the test page at http://localhost:5000.

That’s it.

Accessing React refs in React-DnD

My team and I at OptinMonster are in the process of building a true drag & drop solution for the campaign builder. This represents the biggest improvement to the platform in over a year.

We landed on using the excellent React DnD to power the user interactions. It provides some high-level components to make use of the HTML5 Drag & Drop API which significantly speeds up our development.

One problem I’ve run into is accessing a child of the drop target element to calculate some hover interactions. The React DnD docs suggest using findDOMNode(component) but performing the DOM tree searches during the hover callback (which fires seemingly every 10ms) can bring the browser to a standstill with any significant number of nodes.

So instead I found React refs are accessible from within the React DnD callbacks with component.decoratedComponentInstance. This is a significantly faster method of pulling data out of the DOM and provides access only to the DOM elements you really need. Here’s how to make use of the refs:


Have any questions about React, drag & drop, or OptinMonster? Let me know on Twitter!

Leave it better than you found it

The Boy Scouts and many outdoorsmen/women have a code of leaving the campsite better than you found it. That means picking up trash even if you didn’t leave it. When you finish your stay the campsite should be pristine.

That guideline can easily be translated to software development. I highly doubt you’ve opened up a class file and, besides the big issue went in to fix, you thought there was nothing you could do to improve it.

Does the formatting conform to your team’s standards?

Do all of the variable and method names make sense?

Could any part of the code be made less ambiguous?

Next time you hop into some code for a “quick-fix”, take a look around and see what you can do to leave the file better than you found it.

Make Hay

There’s an old saying, “Make hay while the sun shines”. It means you should get your work done while the conditions are favorable. No distractions. Don’t even think of dilly-dallying!

You never know when the power will go out. Or you’ll get the flu. Or your kid will get sick. Or all of the above.

So make your hay, develop that app, write your comment or so your work while the sun is still shining.

Not for long

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.