Favorite WP-CLI Packages: Login Command


#1

Originally published at: https://roots.io/favorite-wp-cli-packages-login-command/

This is the first post in a series on WP-CLI Packages. Most work days for me involve working on WordPress sites, which in-turn means that I’m regularly interacting with WP installs via WP-CLI. :desktop_computer: wp is the 4th most used command in my history, and wp login is one of my most frequently used commands.…


#2

This is great! I’d be interested to know where BotMan is sitting in your example? Is there some sort of middleware or server in between Slack and where the site lives to handle the login logic / run the wp-cli login command?


#3

In that example it’s sitting within a Laravel intranet/dashboard app that has cloned repos for all of our active projects. This is how I was testing it:

<?php
#!/usr/bin/php
require 'vendor/autoload.php';

use Mpociot\BotMan\BotManFactory;
use React\EventLoop\Factory;

$loop = Factory::create();
$botman = BotManFactory::createForRTM([
    'slack_token' => env('SLACK_TOKEN')
], $loop);

$botman->hears('~login', function($bot) {
    $bot->reply("Use the following format:\n • ~login example.com\n • ~login example.com:staging\n");
});

$botman->hears('~login {login}', function($bot, $domain) {
    if (strpos($domain, ':staging') !== false) {
        $domain = preg_match("/.*\|(.*)>$/", $domain, $matches);
        $domain = $matches[1];
        $domain = str_replace(':staging', '', $domain);
        $environment = 'staging';
    } else {
        $domain = preg_match("/.*\|(.*)>$/", $domain, $matches);
        $domain = $matches[1];
        $environment = 'production';
    }

    if (file_exists('./storage/repos/'.$domain.'/site/composer.json')) {
        $output = shell_exec('cd storage/repos/'.$domain.'/site && wp @'.$environment.' login create adminusername --url-only');
        $bot->reply("🔒 *Launch ".$environment." wp-admin* \n • ".$output);
    } else {
        $bot->reply("⚠️ Site not found. Type `~login` for help.");
    }
});

$loop->run();

#4

Amazing! Thanks for the snippet! :heart_eyes:


#5

Evan does some awesome stuff.

Another one of my favorites is: wp valet.

Simply valet park your development/project directory (e.g. cd ~/Development/web && valet park) and from there on out, enjoy 1 liner Bedrock installs.

wp valet new example --project=bedrock

and example.test (or whatever tld you have configured on Valet) will be ready to roll, including .env and your database.


#6

I didn’t know until I inquired about setting a default project here, but apparently ~/.wp-cli/config.yml is a thing.

To set the project to bedrock by default when using wp valet new, you can add the following to config.yml (create it if it doesn’t exist):

valet new:
  project: bedrock

#7

Having an issue implementing this in (latest) trellis for remote servers. I overwrote wp_cli_packages in group_vars/all/main.yml and it works on development but not production.

Development Server
wp @dev package list - Shows the login package
wp @dev login create username - works

Remote server:
wp @prod package list - Package not shown
wp @prod login create username - get error: “login is not a registered wp command”

I noticed the wp-cli role uses brackets for wp_cli_packages, and the tutorial used indented dashes, however the syntax made no difference on a remote provision.

In the trellis terminal output during a provision it lists the package seemingly correctly under the Install WP-CLI packages task.

edit: for now I just ran wp package install aaemnnosttv/wp-cli-login-command on the remote server, but am still curious why it doesn’t work after a provision.


#9

That’s …weird. If you need further help troubleshooting this, please make a new thread so we can keep this one on topic :slight_smile: