Category: Development

  • WP-CLI With Local 6

    Despite working for a different hosting company with another local development option, I was using Local for local WordPress development for years before joining Pantheon, and I recently was trying to get it working again since upgrading to the latest version. With Local 3, I learned this neat trick from Sal Ferrarello for using WP-CLI outside of the container, but the setup changed a bit when I moved to 6.0.

    Socket Path

    Local no longer has you SSH into the container to use WP-CLI, but the “open site shell” option in the drop-down menu instead sets up all the various environmental variables needed to use WP-CLI, but it’s annoying to have to go through the Local GUI every time.

    We’ll follow the same instructions in Sal’s configuration to setup wp-cli.local.yml and wp-cli.local.php, but instead of looking for the remote host and remote port in Local’s database tab, we need the path to the mysqld.sock file.

    Screenshot of Local App GUI with an arrow pointing to the Socket path.

    With that path, we can update our DB_HOST constant in in wp-cli.local.php like so:

    <?php
    define('DB_HOST', 'localhost:/Users/philiptyler/Library/Application Support/Local/run/Nn6ehKT-l/mysql/mysqld.sock');

    You can confirm WP-CLI works without SSH by running a sample command in your project directory:

    $ wp option get siteurl

    and you should get your site’s URL back successfully.

  • Multiple Aliases in SSH Config

    IĀ used to use Text Expander to shortcut ssh hostnames, but as I setup a new laptop this last year, got into doing it all more “properly” with my ssh config file and wanted a fresh start.

    If you’re unfamiliar with the practice, you can store an alias at ~/.ssh/config, with an entry like this:

    host <alias>
        hostname <IP or FQDN>
        user <user>
        port <port>
        IdentityFile <path/to/private/key/file.rsa>

    I’d gotten into the bad habit of using “old” names for a couple of our StagingPilot instances, relying on the muscle memory of an old name, even as we had migrated workers and services to new servers with revised names, and just redirected those old names with Text Expander. I was excited to discover I could add multiple aliases for a host in my config file, meaning I could use either interchangeably.

    host spapp spserver
        hostname app.stagingpilot.com
        user ptyler
        IdentityFile ~/private/key/file

    Now it no longer matters if I remember ssh spapp or ssh spserver, both resolve immediately.

  • Fixing Cloudway’s WP-Salt + WP-CLI Conflict

    I discovered Cloudways hosting after seeing a client host a number of sites there, and enjoy the flexibility of their managed system as well as an extensive API to interact with and speed up both our StagingPilot integration as well as hosting a handful of my own sites.

    One interesting quirk I’ve discovered is, they “offload” wp-config’s keys and salt constants to a separate file, wp-salt.php. This is fine, except that the require()statement in wp-config.php causes WP-CLI to throw a fatal error when run in any directory other than public_html/. Adding the directory magic constant __DIR__ to the file path (assuming you’re running PHP 5.3.0+ which… you truly have no excuse not to be) allows wp-config to read that salt file when called from anywhere, giving you free reign to work with WP-CLI wherever you need.

    The following sed command will do the trick in one line.

    sed -i "s|require('wp-salt.php')|require(__DIR__.'/wp-salt.php')|g" wp-config.php