Adapting to Generic PHP Development with Visual Studio Code and Docker

Up until recently, I was developing in Magento full time. Unfortunately, along with 40 million others, COVID-19 exacted a toll on the company I worked for, and my position vaporized. As a result, I find myself adapting. This is a good thing. There’s much to be learned when you find yourself having to adapt.

One of the things I worked hard at while doing Magento development was building my development environment. I wound up with a VSCode and Docker based solution that suited me well. So I’m adapting it to be a bit more generic. It will still be Ubuntu 18.04, with NGINX, php-fpm, etc. I may publish that for general use, but I think I want to build a couple of little utility scripts for personalization, project switching, etc. We’ll see how it goes. Stay tuned.

Opinionated Docker + VSCode for Magento Commerce Development

Developing for Magento while using Windows can be a bit of a pain. Most people, including many Magento support staffers, will tell you that it’s easiest/best to install a full-blown Linux VM and do all your Magento development there. Personally, I find it’s a waste of resources and degrades your Windows experience unnecessarily since it locks up the resources it’s using.

I think Docker is a better way to go. More than that, the folks at Microsoft have been developing some remarkable features into VS Code lately, including the ability to have some pretty deep integration with Docker containers – in that you can actually attach an instance of VS code onto a container and have a fully realized development experience, from Windows, inside your container.

So I present Magento Commerce Dev, an opinionated Docker and VS Code solution to the age-old developing for Magento on Windows problem. I’ve been using these exact scripts for the better part of 6 months now, daily, and I really enjoy the development experience.

At it’s core, it builds a Linux-based docker container that has all the services you need: NGINX, PHP-FPM, Elasticsearch, Redis, RabbitMQ, MySQL, etc. It stands up an environment configured very much like one of the Magento Cloud environments, so chances are good if it runs locally, it’ll run remotely. It includes persistent volumes for your home directory and /var/log, so that even if you have to rebuild the entire environment, nothing important is lost. It keeps /var/log as a persistent environment in case you have to inspect the log files because something stupid is happening.

Then you attach VS Code to it, and you now have an IDE running on Windows with a Command Line running inside the docker container, and a pretty seamless integration. Please check it out and give me feedback!

Ryzen + Docker Toolbox = Head Scratching

I got this fun little note while setting up Docker Toolbox on my new PC (which came with a lovely AMD Ryzen 7 2700 series CPU and oodles of power in all the right places):

Error with pre-create check: "This computer doesn't have VT-X/AMD-v enabled. Enabling it in the BIOS is mandatory"

This is just using the Docker Quickstart Terminal, which does a lot of the heavy lifting for you. So I smack myself in the forehead and say “Well *of course* it’s not enabled, I forgot to enable it in the BIOS.” Off I go to reboot and enable virtualization. While I’m there, I note to myself that it just says “virtualization,” not AMD-v, which I find odd. Go try again, and I get the same error. This kicks off hours of google-fu and an unhelpful phone call with HP Support. Nothing makes sense – it’s most definitely enabled, and Windows sees it, but two third party utilities do not.

Finally, I stumble across this tiny post in an issue report for Docker Machine. So I go and find the script that Docker Quickstart uses (C:\Program Files\Docker Toolbox\ and find the docker-machine create line. In my paritcular install, it’s on line #69, and looks like this:

"${DOCKER_MACHINE}" create -d virtualbox $PROXY_ENV "${VM}"

I modify it so that it looks like this instead (note the “–virtualbox-no-vtx-check” addition):

"${DOCKER_MACHINE}" create -d virtualbox --virtualbox-no-vtx-check $PROXY_ENV "${VM}"

And now everything’s happy and running. I hope this helps you as well when you stumble across it using your own google-fu. Or ddg-fu. Yahoo-fu? Whatever. Just get past this stupid error, and move on with your life!

Oh, Dang. It’s been how long?

My apologies to the two of you that happen across this blog on the occasion. It’s been a super-busy couple of years. In the time since my last post, I’ve expanded my knowledge into C#, built cool things I can’t show you in PHP (using all the cool toys like Composer) built other cool things I can’t show you in C targeting the AVR and ESP32 microcontroller platforms, and run websites in Magento, WordPress, and a few bespoke app stacks. I also developed an affinity for fountain pens an mechanical watches. The biggest new adventure, however, came personally, as my wife and I became restaurateurs. That, more than anything else, is what caused the blogging to suddenly stop – it takes a lot of time and attention that I would sporadically spend blogging and making the world a better place, one byte at a time.

Next up on the learning curve is Kubernetes, Helm, and Ansible. Oh, and how to make the perfect corned beef sandwich.

Learning C#

I decided recently to pick up the C# programming language. Actually, I’m quite enjoying it. After spending an aeon in non-strict languages, it’s lovely to be learning a new fully object-oriented and strongly typed language.  And, for a bonus, a lot of what I learned in VB.NET applies as far as the Microsoft way of handling thread safety and other similar concepts carries over into the C# realm.

Microsoft offers a reasonably decent C# programming course over at edX.  The course material is pretty good, but I have some issues with the “peer review” aspect of it. You have a wildly varying community of people with wildly varying skillsets critiquing your work, so it can at times be unfair. Otherwise, this has been a good experience, and I’ll have a new skill to enjoy when I’m done.  Next up: Xamarin.

Symfony Experiments

I’ve finally taken the time to learn Symfony. It really is a remarkable platform, and I’ve been meaning to pick it up for quite some time.  My first project is non-pretty, at least visually, but it works well.

I implemented Rock Paper Scissors Lizard Spock as my first exploration into Symfony. It lives at, and you can get the code on bitbucket.

RVL 1.5.x Released, and General Moaning

Go get it! In this release, I’ve deprecated the dependency on the Twig templating system. Don’t get me wrong – Twig is fantastic! However, I was only using the tiniest bit of its functionality, and it was really a heavy-handed approach to a simple problem. I refactored the code into a pure PHP alternative in maybe 10 minutes.

Having Twig exposed an issue with both WordPress and PHP (One I should have foreseen, actually). In WordPress, it can be a real challenge to have multiple copies of the same third-party library in the same install.  To wit, if two plugin authors both include the standard Twig package, the second authors plugin won’t activate because Twig is already instantiated. Sure you can check to see if Twig already is declared and simply use that instance, but there’s no guarantee that they’re using the same version.  If they’re using an older version and you try to use a feature included in the newer version, you’re out of luck.

Namespacing or class nesting could solve the problem.  However, PHP doesn’t implement those features well enough (or at all, in the case of class nesting) to solve the basic issue. It would be fantastic to be able to open a new PHP file, declare a namespace, and require Twig, then Twig would be sitting all pretty and ready to go under my own umbrella namespace. Class collisions would be near-impossible.

My opinion of PHP, in general, has changed since I wrote my little post about PHP being web legos. If wielded correctly, PHP can be a fantastic language to work with.  But occasionally you still get the feeling that OOP was sort of bolted on (and it was), and miss some of the things you get when a language is object oriented from day one.

Shortcodes Not Rendering with WordPress 4.4

After upgrading to WordPress 4.4 on a couple sites I manage, I noticed that some shortcodes weren’t rendering (“Rendering” is the fancy word I use to describe what happens when WordPress changes a shortcode into whatever text or code that shortcode is supposed to become).  With no changes to the text in pages or posts, the shortcodes were simply being displayed in their shortcode form instead of interpreted and rendered.

Here I present an example.  I have a private post on this site which I use to test my Responsive Video Light plugin. It’s simply two shortcodes – one for YouTube and one for Vimeo.

Broken Spaces

Curiously, when this post was viewed, the top shortcode would not render, but the bottom one would.  It’s not a syntax problem, they’re both correctly formed, or at least appear to be.  After much Google-foo, I finally stumbled across an article that instructs you to re-type any spaces in your shortcodes not working after upgrading to WordPress 4.4. I thought to myself “no, that can’t be it,” but decided to give it a shot anyway.  Lo and behold, it worked!

To figure out why this was so, I reverted to the earlier, non-working version of my test post, and copied and pasted its contents into a file that I could inspect with a hex editor.  My hunch was that the spaces were in fact different, but the difference couldn’t be seen by eye.  Take a look at the following screenshots. This first one highlights the space between “responsive_youtube” and the video URL in the shortcode, which is the one that doesn’t render. This space is not a simple single-byte ASCII space (0x20), but is actually a two-byte sequence, 0xC2 0xA0.  Google reveals that is a Unicode symbol for a non-breaking space!

Screen Shot 2015-12-29 at 8.39.58 AM

In this final screenshot, the highlighted part is the space between “responsive_vimeo” and the rest of its arguments.  This is a true ASCII space (0x20), and so this shortcode renders properly.

Screen Shot 2015-12-29 at 8.40.33 AM

I cannot imagine why upgrading WordPress would cause this.  My hunch is that some older version of TinyMCE (the visual editor) inserted the Unicode space instead of the ASCII space.  Wordpress comes along and adds some Unicode support in a parser somewhere in the newest version, and now that no longer sees a Unicode non-breaking space as identical to a simple ASCII Space.  Things break, nerds weep and shake their fists.  Oh well.  At least I know what’s causing it – I won’t dig any further into WordPress to find the root cause – I’ve spent enough time just figuring this much out.  Enjoy your newfound knowledge ;-)

Responsive Video Light 1.3.x Released

The slew of new features I’ve been wanting to implement have now been implemented.  A major upgrade was just unleashed upon the unsuspecting world, with new YouTube options and a completely reworked settings screen.  I really think you’ll love it, so go download the Responsive Video Light, now with 75% more awesome with no preservatives and half the calories.