The first time I saw WP-CLI in use I wept. It’s an amazing tool! I’d go so far as to say that > 50% of hello-dolly uninstalls are done via WP-CLI and probably a good chunk of those are scripted.
But, WP-CLI is a bad thing on live sites.
Maybe my thought process is irrational, but hear me out…or don’t…it’s the internet and I don’t do any analytics on this site *shrug*.
WP-CLI gives complete unfettered access to the WP install. “But, wait!” you say… WP-CLI is accessed via SSH and one of those S’s stands for secure!
Hmm…maybe I don’t think WP-CLI is the problem. Maybe, SSH is…but that makes for a boring post title.
Look, best practices would have us run our sites on a machine we deploy to after testing theme, plugin, core, or whatever updates on a staging site. Very often we run updates on live sites…and rarely is that problematic.
Jumping in with both feet onto a trafficked production site and using WP-CLI, especially non-core commands, seems like a recipe for “Crap…how old is the last backup?”
If you’re still reading I am ready to confess. I constantly use WP-CLI on prod sites. And it has only ever bit me on the ass due to my own carelessness. The point I’m trying to make is that when we deploy code it goes through many steps. When we run CLI commands we just type and hit enter, no filter, no double-check. Then, our hearts sink because unlike gmail there is no “unsend” button.
I started this post like 3 years ago and then forgot I had a website or whatever. It was half complete. I could have just deleted it but I like the reminder to be careful around CLI on prod.
At WebDevStudios we use Harvest for tracking time.
The Harvest Time Tracker for Chrome is awesome. Most of the time, I’m starting a new task from within Basecamp, or occasionally github so the chrome plugin is perfect. I typically only go the harvest site to stop my tracker for lunch or at the end of a work day.
However, I often wonder about my hours for the week and if I can take a long lunch and catch an episode of X-Files. But, I’m not neurotic enough to actually log into harvest and check.
So, I wrote a simple script that grabs my hours worked from the Harvest API and saves them to a file. I added this script to my cron to run every 15 minutes and then I include that file in my prompt:
prompt_segment white black $(tail /Users/garykovar/.tools/harveststatus)
(I’m using the agnoster theme in zsh).
Here’s what my prompt looks like:
The w is hours for the week and d is for the day…not real time obv…
And here’s the gist of it:
Oh yeah…if you don’t edit your crontab and always have to google for syntax, here’s what I did:
*/15 * * * * /Users/garykovar/.tools/harvest
In a parked directory…create a folder for phpmyadmin and install phpMyAdmin. Rename the config sample file and wow…now you can navigate to http://phpmyadmin.dev and access phpMyAdmin locally.
Super easy, much useful, wow!
Here are 2 ways I use WP-CLI and Laravel Valet
I do not consider myself a command line ninja. In fact, I prefer to write my scripts as php files and kick them off with #!/usr/bin/php (still need to make them executable with chmod +x filename.php).
I am deeply in love with WP-CLI and Laravel Valet. Both are command line tools. That means they can be intimidating with a HUGE list of commands that are mostly forgettable. But, I’ve found these 2 in particular have daily payoff for a small memory investment.
One of my favorites. I have a simple .php file executed by cron that looks at a directory and creates an array of directories inside. Then I exec(“wp db export /backuplocation/$dirname.sql”); which creates a simple backup file of the database. In the same script, on the next line I run an exec(‘tar -cf /backuplocation/$dirname.tar *’); One could put that .tar file anywhere…maybe even scp it somewhere?
Super double bonus for running this on a machine with dropbox/google drive/icloud and slapping your backup files in your folder-syncy-folder.
Oh! I forgot the best part. After /backuplocation I have the day of the week. So /backuplocation/$day/$dirname.sql would give me 7 rotating backups. Obviously if you want to retain more you can run 30 days rotation or whatnot.
Installing Laravel Valet isn’t super easy, but it’s totally worth it. (plus if you aren’t on the homebrew bandwagon it’s time…)
I have a folder called ~/websites/ and in it are a bunch of odd-ball WP projects I’m working on. Because I ran ‘valet park’ on that dir every directory I add in there resolves to $dirname.dev.
I have a php script in there that I run with:
It does the following:
- Creates a new folder in ~/websites with that name.
- Runs wp core download
- Runs wp core config with the mysql settings I need (because I ‘brew install mariadb’)
- Runs wp core install
- Runs wp plugin install $newsite –activate
The wp plugin part fails most of the time but on occasion I’m spinning up a site to mess around with a plugin. For those times I create a site with the plugin slug name and 25 seconds later I have a WP install with that plugin ready to go. I could do the same for themes if I were to mess with them with some regularity.