While making the tea light centerpiece I, of course, made some mistakes. Luckily, wood can be a forgiving medium. Here’s a little video on how to fix those mistakes.
I made this tea light centerpiece for my wife on Mother’s Day 2019. This is the first project where I remembered to video the process, so enjoy!
Mistakes were made.
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
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:
Just copypasta that query into your favorite MySQL client (or the cli if you’re hardcore) and you should see the magic number.
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.
You should see a new file open up called
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:
You should set up all of the necessary path mappings. Their format should be
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!
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.
So without further ado, my process:
Install the package
Create the necessary files
I first create a new temporary directory and add an
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
Once you see “Serving!” your page is ready to go!
View the page
You can now see the test page at http://localhost:5000.
Even when you come back empty-handed the time has not been wasted. Hunting provides us with so much more than meat.
In the stillness of hunting you have time to stop, to listen, and be present with yourself and the great outdoors.
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!
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.
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.
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.