getflywheel/local-cli

Feature Request: Run commands against the Local environment from the host

Opened this issue · 8 comments

In an effort to automate as much of running client updates each month as I can, I currently have a script that will crawl through a configured list of directories and, in each one, essentially run wp plugin update --all (or other arbitrary shell commands). That can run for an hour or whatever and then I pop into each site, give it a once over, commit my changes and push. Great.

I've considered moving to Local for development, but would need some kind of feature out of local-cli that let's me execute commands against a site. Something like wp-cli itself provides for running commands over an SSH connection.

Would love to see a similar feature come to local-cli. Something like...

local-cli exec SITEID "wp --info"

You don't actually need this CLI to change at all in order to do that sort of thing. Use the existing local-cli start-site to start your site. Then, if you've installed the wp command globally on your system and configured the WP-CLI (see below sections) just use those commands directly once you're in folders of your Local site.

Installing the WP-CLI

I recommend using Homebrew to install the WP-CLI globally on your system. Use brew install wp-cli once Homebrew is installed. You may also need to install PHP using brew install php, I honestly don't remember as I have PHP installed that way anyway.

Configuring Local CLI Access to Sites

In the root folder of your Local site (the folder that contains the app, conf, and logs folders) place two files:

wp-cli.local.yml:

path: app/public
require:
  - wp-cli.local.php

wp-cli.local.php:

<?php
define('DB_HOST', 'localhost:SOCKET_PATH');

error_reporting(0);
@ini_set('display_errors', 0);
define( 'WP_DEBUG', false );

Replace SOCKET_PATH with the path found in Local, under the Socket item in the Database tab of your site.

Usage

Simply cd to any folder within your Local site. Ensure it is running using local-cli start-site. Then use any wp command, for example wp plugin list. The WP-CLI will work like normal.

@alexclst The Windows version of Local doesn't show the socket. Somewhere else one could find that?

@ethanclevenger91 the Windows version may use Host and Port instead of Socket, at least based on what my MySQL config file shows where it splits between Windows and everything else. So perhaps you need to use those, where the DB_HOST would be something like host:port.

@alexclst that works, which is nice and all, but it isn't really the same thing. We're now talking to the right database from the host machine, but this still results in a world where my host might be running PHP 8.0, while my Local site might be on PHP 7.4.

Ideally, we'd be running commands against the environment hosting the site, which I presume is a Docker container.

If this weren't baked into Local CLI, it'd be nice to have instructions for configuring a WP-CLI alias in wp-cli.local.yml:

@local:
  ssh: however-we-ssh-into-local:/path/to/site/app/public

@ethanclevenger91 I am pretty sure that Local is no longer Docker-based at all, ever since VirtualBox was dropped as a dependency back in v5 or so years ago. In fact, I can observe the site packages (nginx, mysqld, etc.) right within Activity Monitor on macOS, which shows that they are run right on the bare macOS operating system, no VM in between. The equivalent app on Windows can probably show the same.

PHP versions are indeed a problem. Luckily I rarely get bitten by it, but still. I've tried to set up a multi-version PHP environment on my Mac a few times, similar to what tools such as pyenv and rvm do, but to no avail, at least on my Apple Silicon Mac they all fail to build. But an external management isn't ideal anyhow. What would be ideal is some way to "inject" the PHP binary's path from exactly what Local uses into the environment only when you are cd'd within a Local site. But I have no idea how to accomplish that, at least not without enormous overhead in my shell environment.

Ah, right.

Yeah that's essentially what's happening when Local boots a CLI window. There's a script that runs that loads that site's PHP version onto the path.

So in that sense, the WP-CLI alias solution doesn't make any sense. A local-cli command that could determine the current site's ID (or be explicitly passed it) and do the same stuff that script does, and then revert back, would be an ideal solution here I think, which is the original request anyway.

Having this would be awesome. I'm thinking of uses like popping up the local wp cli in the shell of your IDE with a single hotkey (VSCode, Vim, etc).

While waiting for an official solution, I created a custom bash script that allows me to start, stop and open site shells.
The script will load in all sites (local-cli list sites), and charmbracelet/gum will let you filter that list. After that the site ID is extracted.

Requirements

  • charmbracelet/gum
  • You might need to change the path on line 9 according to your OS/install

Script

#!/bin/sh
COMMAND=$1

SITE=$(local-cli list-sites | gum filter)
SITEID="$(echo ${SITE} | awk -F '' '{print $2}' | awk '{$1=$1};1')"

case $COMMAND in
  shell)
	~/Library/Application\ Support/Local/ssh-entry/${SITEID}.sh; exit
    ;;

  start)
	local-cli start-site ${SITEID}
    ;;

  stop)
	local-cli stop-site ${SITEID}
    ;;

  *)
esac