New to the community? Start here

WP-CLI advanced commands

there are a handful of WP-CLI commands that i regularly use on my other hosting accounts/servers that are not allowed on WPMU hosting. as an example:
wp transient delete --all --network && wp site list --field=url | xargs -n1 -I % wp --url=% transient delete --all; wp cache flush --all --network && wp site list --field=url | xargs -n1 -I % wp --url=% cache flush --all

is there a way that we can go about using that command?

also… on some of my larger MU installs, i had created files called wp-cron.sh. they functioned as a single point to run MU crons. here’s an example of the file, if it were located on WPMU hosting:

#!/bin/bash
clear
echo "$(tput setaf 4)##############   $(tput sgr 0)";
echo "$(tput setaf 3)$(tput bold)   HILINEMERCH.com $(tput sgr 0)";
echo "$(tput setaf 4)##############   $(tput sgr 0)";
echo "";

PATH_TO_WORDPRESS="~/site/public_html/"
echo "";
echo "$(tput setaf 3)$(tput bold)>> CRON - Run on Each Sub-Site $(tput sgr 0)";
echo "";
for URL in = $(wp site list --fields=url --format=csv --path="$PATH_TO_WORDPRESS")
do
	if [[ $URL == "http"* ]]; then
		wp cron event run --all --due-now --url="$URL" --path="$PATH_TO_WORDPRESS"
	fi
done

echo "$(tput setaf 4)     ###########     $(tput sgr 0)";
echo "";
echo "$(tput setaf 3)$(tput bold)>> ACTION-SCHEDULER - Run on Each Sub-Site   $(tput sgr 0)";
echo "";

for URL in = $(wp site list --fields=url --format=csv --path="$PATH_TO_WORDPRESS")
do
	if [[ $URL == "http"* ]]; then
		wp action-scheduler run --url="$URL" --path="$PATH_TO_WORDPRESS" --force
	fi
done

echo "$(tput setaf 4)     ###########     $(tput sgr 0)";
echo "";
echo "$(tput setaf 3)$(tput bold)>> WOO UPDATE - Run on Each Sub-Site $(tput sgr 0)";
echo "";

for URL in = $(wp site list --fields=url --format=csv --path="$PATH_TO_WORDPRESS")
do
	if [[ $URL == "http"* ]]; then
		wp wc update run --url="$URL" --path="$PATH_TO_WORDPRESS" --force
	fi
done

…so… is there any way to run commands like these on WPMU hosting?

Tue, 5 Nov 2019 13:42:24
  • Dimitris Kalliris
    • Support Team Lead

    Hello there splaquet

    As far as I can see in the first example, it’s not the WP CLI commands that can’t run but the SSH “xargs” command and shell pipes that are forbidden.

    In the second example, there’s again a SSH command that’s not in the allowed ones, “tput”.

    Reference:
    Allowed SSH Commands
    https://wpmudev.com/docs/hosting/sftp-ssh/#allowed-ssh-commands

    Hope that clarifies things better.
    Warm regards,
    Dimitris

  • splaquet
    • WordPress Warrior

    a little background… i was receiving a “WooCommerce must be installed in order to use X plugin”. WHAT?! That statement was whacky on a few levels, but mostly because we’ve been actively selling products on this MU install for quite some time. thing was… i wasn’t seeing this message on all subsites. or at least, i only noticed it on one.

    and although WooCommerce had already been updated to v3.8 on the network (and I assumed that WPMU hosting wouldn’t have any issues with sub-site crons/actions), this is the message that i received when i used the following WP-CLI command:

    wpmudev.host:~$ wp plugin update --all --url=notrealdomain.com
PHP Notice:  Undefined index: hiline.cloud in phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(1198) : eval()'d code on line 59
Notice: Undefined variable: environment in ~/site/public_html/wp-content/object-cache.php on line 26
Enabling Maintenance mode...
Downloading update from https://downloads.wordpress.org/plugin/woocommerce.3.8.0.zip...
The authenticity of woocommerce.3.8.0.zip could not be verified as no signature was found.
Unpacking the update...
Installing the latest version...
Removing the old version of the plugin...
Plugin updated successfully.
Disabling Maintenance mode...
+-------------+-------------+-------------+---------+
| name                  | old_version  | new_version |  status   |
+-------------+-------------+-------------+---------+
| woocommerce |        3.7.1       |        3.8.0       | Updated |
+-------------+-------------+-------------+---------+
Success: Updated 1 of 1 plugins.
wpmudev.host:~$

    so… that’s why i was wondering how i could execute wp-cli across all of my subsites, without having to reuse the command for each one of the subsites.

  • Nastia
    • Ex Staff

    Hello splaquet

    I trust you’re doing well!

    The WP CLI command to update plugins is the one that you executed on your end:

    wp plugin update --all

    On the WordPress multisite, the plugins can be updated on the network level, as plugins are global.

    If you’re referring to an internal update, as Woocommerce plugin often request, there is no WP CLI command to do this and it can be done only by clicking in the Upgrade Network link that shows up on the dashboard.

    Regarding the message were shown on a subsite “WooCommerce must be installed in order to use X plugin”, would you please check if the Woocomerce was activated? Perhaps the plugin X showing this notice when the Woocomerce plugin is installed, but not active on a site.

    Let us know if you will have any questions.

    Kind regards,
    Nastia

  • splaquet
    • WordPress Warrior

    i’m fully aware of the “wp update plugin –all” command… as is why I used “wp plugin update –all –url=notrealdomain.com” on the network’s sub-site.

    but, as my copy/paste example shows (from my previous reply), “wp update plugin –all” simply is not covering all bases.

    ###

    i’m not looking into how or why WP-CLI commands are used… i’m trying to find a workaround as to how I can use a reference via SSH terminal that will pull all of the URLs from within the network, and apply them in a 1-shot WP-CLI line.

    i couldn’t tell you why the update/upgrade issue in my example wasn’t working correctly with the standard “upgrade –all”, but i can tell you that running the update with the “–url=subsiteurl.com” flag updated the issue that I had.

    i have several custom mapped domains throughout my network. i don’t see that as being a regular issue on my other MU installs, but it happened… and my fix for my other MU installs works, except I cannot run the same command on WPMU hosting.

  • Pawel Pela
    • Ex Staff

    Hello splaquet !

    Yup, I understand your issue here as I recently had to check if a backup was restored properly. Staff members have the same level of access as you do, so you can imagine that checking if files match and the database has everything in it took a bit of workarounds.

    So for example to get a for loop, I had to use perl. Yes, I know – perl. It worked though. Here’s an actual snippet I used to get a for loop:

    use strict; use warnings;
 use autodie;  # automatic error handling
 

 while (defined(my $file = glob '*.sql')) {
         system("wp db import $file");
 }

    Bash unfortunately won’t work in that setup – this goes a bit beyond the definition of a managed hosting that is our service. The main idea here is to give users some tools but otherwise handle maintenance of the hosting through the hosting team. If you need to run bash scripts to do your own maintenance jobs on the sites, then I doubt a managed hosting is the best option. A VPS requires administration, but it’s better suited for your advanced needs.

    Our hosting has cron running every 5 minutes and pinging the site to ensure the built-in WP cron also runs regularly. You may consider implementing the maintenance cronjobs you currently have as a bash script in PHP using built-in WordPress features.

    As for more access – we’re already discussing that internally as there were some questions about it from our members besides yours. It’s a managed hosting so some limitations are to be expected. That’s just a proposition at the moment and we must discuss it thuroughly. As you can imagine, there may be some problems that can arise from that, so we need to weigh all the pros and cons of that before making any decisions. Giving more access is very easy from tech standpoint, but it brings some business/legal issues too, especially regarding the scope of our support services and the responsibility we take for our hosting. As above – for more advanced needs please consider using an actual VPS with full root access instead.

    Here are the docs for our hosting that may clear up things a bit more as to what we allow/disallow: https://wpmudev.com/docs/hosting/

    Hope this helps!

    Kind regards,
    Pawel

  • splaquet
    • WordPress Warrior

    Pawel , thank you for putting in the time to get that worked out. i’m assuming that script would need to be run from a perlfile.pl command?

    another element that i only now noticed was wp action-scheduler run

    i upgraded WooCommerce Admin/Analytics earlier today. i noticed a few odd errors in the debug.log. on my other servers, i simply ran this command via ssh:
    wp action-scheduler run --force --allow-root && wp site list --field=url --allow-root | xargs -n1 -I % wp --url=% action-scheduler run --force --allow-root

    but on WPMU hosting, it wasn’t so easy. it was running the following script on each url=
    wp action-scheduler run --url=sitename.com

    as of now, i’m realizing that you do understand the bind that i’m in (so, thank you for hopping onto my thread)… but sadly, this is going to make a lot of additional work for manually running WP & WC cron jobs/actions/updates.

  • Pawel Pela
    • Ex Staff

    Hello splaquet !

    Yes, this script you need to put in a file with .pl extension and run it with perl filename.pl.

    As for running the action-scheduler you mentioned above, here’s a perl script I created and tested to do that:

    
system("wp action-scheduler run --force --allow-root");

# put list of sites into array
my @sites = <code>wp site list --field=url --allow-root</code>;
chomp @sites; #strip whitespace if any

foreach my $site (@sites) {
        system("wp --url=$site action-scheduler run --force --allow-root");
}

    This is the equivalent of the command you posted above with perl acting as substitution for xargs.

    I’ve tested it on a test site of mine and it worked as it should.

    Please try it and let us know if you need any further assistance on that.

    Kind regards,
    Pawel