Aaron Eaton

Development

Counting Gutenberg Blocks

by Leave a Comment

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:

<!-- wp:paragraph {"align":"center"} -->
<p>Now, this is a story all about how My life got flipped-turned upside down And I'd like to take a minute Just sit right there I'll tell you how I became the prince of a town called Bel Air
<!-- /wp:paragraph -->

Now, since every block begins with the same pattern, `<!– wp:`

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:

SELECT 
    SUM( LENGTH( REPLACE ( post_content, "<!-- wp:", "}") ) - LENGTH( REPLACE ( post_content, "<!-- wp:", "" ) ) ) AS block_count
FROM wp_posts
WHERE post_status = 'publish';

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

Simple Local Servers

by Leave a Comment

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

> npm i -g serve

Create the necessary files

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

> mkdir om-test && cd om-test
> touch index.html

Add the HTML

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

<html>
<head><title>OptinMonster Test</title></head>
<body>
    <h1>I'm OptinMonster Testing Rick!</h1>
    <!-- OptinMonster embed code goes here -->
</body>
</html>

Start the server

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

Screenshot of the local server running in the terminal

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.

Using remote XDebug with Visual Studio Code

by Leave a Comment

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.

Prerequisites

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:

[Xdebug]
xdebug.remote_enable = 1
xdebug.remote_autostart = 1
xdebug.remote_connect_back = 1

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.

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:

{
    "name": "Listen for XDebug",
    "type": "php",
    "request": "launch",
    "port": 9000,
    "pathMappings": {
        "/app/public": "${workspaceRoot}"
    }
},

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. Here it is in action:

Gif of debugging working in VS Code

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!

Accessing React refs in React-DnD

by Leave a Comment

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:

/**
* Set `this.targetEl` to your desired element.
*/
class MyComponent extends React.Component {
// ...
render() {
    return (
        <div className="parent">
            <div className="child" ref={el => this.targetEl = el}>Content Here</div>
        </div>
    )
}
// ...
}

/**
* And in your drop target spec `targetEl` will be available.
*/
const dropTarget = {
  hover: (props, monitor, component) => {
    // Get the target bounding rectangle
    const hoverBoundingRect = component.decoratedComponentInstance.targetEl.getBoundingClientRect();
    // ... 
  }
}

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

Shipping, Not User Testing

by Leave a Comment

Back in November Jason Fried (CEO of Basecamp) published a treasure trove of an article detailing how they, the team, structure their work. If you haven’t read it yet stop what you’re doing and take a few minutes to do so. I took a few moments after my third reading to dig through the comments. In response to a question about user testing Jason responded with this:

We don’t do formal usability testing. We build things we’re happy with and ship them. If things turn out to be truly terrible, we reconsider fixes, tweaks, and adjustments for the next cycle. We’ve found that shipping is the best way to get real answers — we don’t like setting up artificial environments. [Source]

If you have an automated deployment workflow (you have that, don’t you?) and your team has the talent to know what customers want, then what keeps you from just shipping?

Leave it better than you found it

by Leave a Comment

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.