Tag: software engineering

My standard Laravel development tools

Now that I’ve been actively developing applications with the Laravel framework for a few years, I thought I’d write down the tools and services I tend to use on a regular basis in that work.

I’ve spent a fair amount of time researching and experimenting with these tools and their alternatives in order to make a choice, so maybe it will help someone else who hasn’t gone through that yet. I’m always glad when others share details about their development environments so that the rest of us who are just getting going can build on that foundation.

Hardware and Development Environment

Launching a New Project

composer global update laravel/installer
laravel new example-app --git --branch="main"
cd example-app
valet link
valet secure example-app

Then I create a database, add the DB info in .env, run artisan migrate, and I’m ready to develop. Sometimes I have to make sure PhpStorm has the right coding standards and PHP Code Sniffer config in place.

Sometimes I add a .psysh.php file to my project repo with these contents:

<?php
DB::listen(function ($query) {
    dump("[{$query->time}ms] {$query->sql}");
    if ($query->bindings) {
        dump($query->bindings);
    }
});

When using artisan tinker, this prints out any SQL queries that were run by a given command within the tinker session, for faster debugging.

For WordPress projects, I use a customized version of this “valetpress” bash script to initialize new projects.

Continue reading My standard Laravel development tools

Cloning a WP Engine site to a local VVV development environment

When doing custom WordPress theme and plugin development for a site that’s already launched, I find it is essential to get my local development environment set up as close as possible to the live environment where the site is hosted. This minimizes headaches and unexpected problems that come when making any updated code live.

Here are the steps I use to clone the database, theme, plugin and media/uploads from a site hosted on WP Engine into a locally-hosted development environment powered by VVV. This method allows me to develop and test new functionality against recent site content before I deploy it to a staging environment for final testing.

The usual warning applies: you should make sure you know what each of these steps is actually doing and adjust them to fit your specific setup. Some of these actions could result in data loss, so please use them at your own risk.

Okay, here we go:

  1. Make sure any custom theme and plugin code you’ll be working with is under source control, probably using these instructions from WP Engine, and up to date locally. Make sure that those directories are not accidentally included in the .gitignore file for your repo. (I handle this by default ignoring everything in, say, the plugins directory with /wp-content/plugins/* and then adding exclusion rules for each directory I’m working on, e.g. !/wp-content/plugins/my-custom-plugin*.)
  2. Initiate a backup checkpoint on the environment you want to clone. If you’re okay using the slightly out of date one that WP Engine automatically makes every morning, that’s fine.
  3. Initiate a download of the backup checkpoint, choosing the “partial” option and checking “Entire database,” “Plugins” and “Themes.” Leave “Media uploads” and “Everything else” unchecked.
  4. Use the WP Engine SSH gateway to rsync the media folder from the WP Engine environment to your local environment. Here’s an example command for a “mystaging” environment…you will want to try your version with the dry run -n flag first to make sure it is going to do what you want! 
    rsync -n -rlD -vz --size-only --delete mystaging:sites/mystaging/wp-content/uploads/ /Users/chris/vvv/www/mysite/public_html/wp-content/uploads/

    This should delete any local media files not in the WP Engine environment, and copy everything else down that isn’t already there. It could take a while if it’s the first time you’re running it, but subsequent runs should only grab new uploads to the site.

  5. Unzip the downloaded backup checkpoint on your local system.
  6. Move the mysql.sql file into a directory that will be accessible from your VVV Vagrant shell: mv ~/Downloads/wp-content/mysql.sql /Users/chris/vvv/www/mysite/
  7. Update your local plugins directory from the downloaded backup. Again, please use the -n flag with your version of this command first to preview the results: 
    rsync -rlD -vz --size-only --delete --exclude=query-monitor ~/Downloads/wp-content/plugins/ /Users/chris/vvv/www/mysite/public_html/wp-content/plugins/

    Note that this command also excludes removing the query-monitor plugin, which I have installed locally but not in the WP Engine environment. That way it can stay ready to activate without reinstalling.

  8. Repeat the above step for the themes directory if need be.
  9. Resolve any discrepancies, things git notes as changes that need to be committed, missing files, etc. There shouldn’t be any but it’s worth checking.
  10. SSH into your VVV box: vagrant ssh
  11. Make sure your WP dev site and the WP Engine site are running the same version of WordPress core.
  12. Go to the directory where the site lives, e.g. cd /srv/www/mysite/public_html/.
  13. Clear out the existing database (again, assuming you don’t have any locally staged changed that you would care about): wp db reset.
  14. Import the database from the WP Engine environment: wp db import ../mysql.sql
  15. Update any content or configuration references to the site’s hostname, noting that you may want to run this with the --dry-run flag first: wp search-replace '//mystaging.com' '//mysite.test' --precise --recurse-objects --all-tables --skip-columns=guid.
  16. If you need to put any of your plugins in local development mode, now’s the time, e.g. wp config set JETPACK_DEV_DEBUG true --raw. And, if you  were using a local development plugin like Query Monitor, reactivate it: wp plugin install query-monitor --activate

That’s it! In only 16 steps you should have a fully up to date copy of your site’s data available for local development and testing. Obviously much of the above could be scripted (with appropriate safeguards) to save time and reduce human error in the process.

I hope you find this helpful. If you have improvements to suggest or your own fun methods of cloning environments, please share in the comments.

WP Engine is a great web host for WordPress developers

I’ve been aware of WP Engine’s WordPress hosting offerings for quite a while now, but I only recently had a chance to dive deeply into the features and benefits they offer to WordPress developers, and I was really impressed.

(Disclaimer: I am not affiliated with WP Engine and am not being compensated by them in any way for this review. But this post contains some referral links where I may receive a small percentage of any sales that result from readers clicking through, and where readers may receive a discount on their purchase.)

Some of the things about WP Engine that stood out to me as really helpful and awesome for WordPress developers:

  1. Super-fast, comprehensive site backup snapshots and cloning. The ability to quickly make a copy of an entire production site (with a large DB and tons of media) to a staging version of that site, or just to a backup snapshot, is a huge benefit. Being able to do it at a click of a button without messing around with export/import tools, find-replace operations or similar command line intervention is just awesome, and enables all sorts of other development best practices when it comes to testing changes and having a safety net for production updates. It’s SO fast, usually completing within a minute or two, so you can make backups/clones all day long without delay. It’s better than any other site backup or environment cloning tool I’ve used in the WordPress hosting space.
  2. Deep integration with git repo management. Although the instructions and interface for setting it up needs a little expanding and polishing, the WP Engine makes it really easy to set up a git repo for a given hosting environment, where changes pushed to its main branch are quickly deployed to the associated environment. They’ve thought through the complexities of exclusions and co-existing with WordPress-initiated core/plugin/theme updates. Add in the GitHub Action to deploy to a WP Engine environment and you’ve got a really sweet development and deployment pipeline setup, all using industry best practices.
  3. Fast and powerful SSH command line access, optimized for security and WP CLI operations. WP Engine seems to understand that command line operations are an essential tool in a WordPress developer or site manager’s toolkit, and they make it really straightforward to use.
  4. Robust system status monitoring and reporting. Whereas some hosts update their system status page well after an impacting event, WP Engine seems to have theirs wired up to show a closer-to-realtime status, and that makes all the difference in not wasting time when troubleshooting or reacting to problems. I also really appreciate that they offer email, Slack and webhook-based notifications for status events, offering endless possibilities with integrating platform events into your development tools and workflows.
  5. Thoughtful tools for keeping WordPress current and secure. WP Engine clearly understands the importance of keeping WordPress core up to date and making sure no insecure plugins or themes are in place any longer than is absolutely necessary. While I think responsibility for these things generally falls to a developer and not the host, I appreciate that they’ve invested in infrastructure here, and I’m sure it benefits them and their support operations in the long run too.
  6. Great support, great communication. Whenever I’ve used the WP Engine support chat they’ve been fast, knowledgeable and straight to the point without being curt. If a question or issue needs input from another internal team, they seem to be able to do that quickly and without any resistance. Their documentation is generally well-written and organized.

In the project I was working on where I finally got to see these features directly in action, I had evaluated a variety of hosts including SiteGround, Pressable, WordPress.com Business, and WP Engine. I picked WP Engine for the above reasons and others, including their focus on WordPress-specific performance optimization.

To be clear, I’m not saying WP Engine is the best WordPress host for every use case, or even most use cases out there. Whether you’re a non-technical WordPress site owner looking for something simple and low-cost, or an enterprise-level site needing something that scales for Superbowl-level traffic with commensurate high-touch support, there are lots of great options out there that might be a better fit. (Having been a part of Automattic/WordPress.com/WordPress.com VIP and seeing the incredible investment in scalable infrastructure there, I know the details really matter at those different ends of the spectrum; I still frequently recommend their offerings too.)

But for a WordPress developer or small development team deploying custom theme and plugin code to a high-traffic site and wanting great WordPress-specific tools, systems and people to support them in that, WP Engine really stands out as worth a look.