Page 82 of 427

Running Multiple Versions of PHP with Homebrew

May 2, 2018 / Tom

One of the challenges with building solutions on WordPress is working with the various environments each host provides.

That is, some are still running very old versions of PHP; others are running newer versions, but even then there are variations among them.

Case in point: I’ve been running PHP 7.2 on my local machine for development for some time; however, I’m currently on a project where a few of the dependencies on the continuous integration tool offers support only for PHP 7.1.

And because I like my development environment to mirror the staging and production environments, I think it’s important to make sure there’s parity.

If you’re using a package manager, it’s pretty easy to get going with multiple of versions of PHP with Homebrew, but you may run into a couple of snags as it relates to running it alongside Valet.

A Quick Guide to Shells in macOS

May 1, 2018 / Tom

If you’ve read any instructions on the web for how to install something, you’ve likely read a statement about adding something to your $PATH. More specifically, it probably included an export statement, a directory, and then a file into which to pipe the command, right?

In fact, you may see a directive like this:

Make sure the ~/.composer/vendor/bin directory is in your system’s “PATH”.

Which means that you should do something like the following:

export PATH="$PATH:$HOME/.composer/vendor/bin"

But if you’re new to working in the terminal, let alone environmental variables, how are you supposed to know how to translate the statement into the above command?

When Valet Stops Working Properly, What Do We Do?

April 30, 2018 / Tom

I’m a fan of using both Homebrew and Valet when it comes to setting up and configuring a basic WordPress development environment. Though using package managers and simple software for such like this should make things easier, it doesn’t absolve us from the occasional problems.

Case in point: There are times in which we may have to update our TLD to play nicely with Chrome and other browsers, or even upgrade the entire installation.

Unfortunately, it’s not always as easy as it should be. Technically, we should be able to uninstall Valet and update it via Composer. But I’ve personally run into some problems that relegated having to:

manually uninstall Valet,
use Homebrew to uninstall PHP and clean up what was left completely,
reinstall Homebrew packages,
install Valet,
verify the browser uses the same version of PHP as the installation of Valet.

It sounds like a lot of work for something that should more or less “just work” and it is quite a few steps, but they are pretty quick to set up.

The WordPress Developer’s Guide to MySQL Data Reconstruction

April 26, 2018 / Tom

At some point in every developer’s career, there is going to be a time where you do something that tanks production.

Maybe you’ll push code that ends up busting a cache that serves data to millions of people,
Perhaps you’ll update an application and end up blowing away information that’s not backed up,
Or maybe you’ll push a change that “works on your machine” but completely hoses the source control repository.

And there are plenty of other examples. I’m sure you can quickly name five more yourself.

I’ve committed (pun intended, sort of) my fair share of all of the above but one of the things that I see from people working in our space.

That is, those who work with database-backed web applications – is the lack of understanding of database organization at the file system level and how it is possible to reconstruct data even when you don’t have a standard backup off of which to work.

In this post, I’m going to take a deep dive into MySQL database organization at the file system level, how you can restore information from that versus a backup file should you find yourself in that situation, and provide references (or bookmarks) should you need them.

A Primer On Reflection in PHP (And How It Plays Into Unit Testing)

April 25, 2018 / Tom

For the past few weeks, I’ve been writing about unit testing for the members of the site (and something that I plan to continue doing in the next post). It’s something that I think; if you write server-side code, you should be doing.

Of course, it’s easier for me to say it than do it so although I try to make sure I do a good job of it, there’s always room for me to improve. I say that more as a personal gut check than anything else, so I digress.

One of the concepts that often come up during testing is the idea of testing the values of private attributes. For example, let’s say that you have a setter, but you don’t necessarily have a getter for that particular value.

It’s easy to say “Well, then you need to write a getter,” but that’s not always the case. I mean what if you’re storing some information within the class that doesn’t need to be exposed to third-party classes?

How then are we supposed to write tests against that kind of data when we want to access it but don’t have the ability to do so and don’t want to compromise the integrity of our work?

That’s where reflection comes into play.

Tom McFarlin

Running Multiple Versions of PHP with Homebrew

A Quick Guide to Shells in macOS

When Valet Stops Working Properly, What Do We Do?

The WordPress Developer’s Guide to MySQL Data Reconstruction

A Primer On Reflection in PHP (And How It Plays Into Unit Testing)