Show which sites the plugins are active

[LC43]

Hi,

in a network listing the plugin and their status is not enough for this tasks:

• check which sites the plugins are activated only on specific sites and the site's status ( deleted/archived/spam/mature/public ) but not network-activated.

I already have working code, so, let me know if this makes sense. Made a PR in my fork to better see the changes: https://github.com/LC43/extension-command/pull/1/files

I've added a new flag for wp plugin status called --show-sites which prints a list like this:

UI contact-form-7                       4.7
         -- PA    83.site A
         -- PA    92.site B
         -- P     125.site C
         -- PD    214.site D
         -- P     228.site E

the output is colorised with:

static $colors = array(
	'public'   => '',   // none
	'archived' => '%y', // yellow
	'mature'   => '%b', // blue
	'spam'     => '%m', // magenta
	'deleted'  => '%r', // red
);

changes:

• added a 2nd parameter to status( $args, $assoc_args ) , which means the theme implementation function also has the new param.
• skip listing the sites if the plugin is network-activated.

I need help with:

• would this featured be better suited in status or in list?
• to get the site status and name, i've created private functions in CommandWithUpgrade.php. Should these functionalities be/use in wp site codebase?

Things still to do:

• add tests
• add legend. currently show_legend( $items ) is very tied to the $items, so either I change this function or create a new one?
• check its a network

i drafted the idea from the this old plugin: https://wordpress.org/plugins/plugin-activation-status/

[gitlost]

Looks useful @LC43 !

would this featured be better suited in status or in list

I think status is a more natural fit.

i've created private functions in CommandWithUpgrade.php. Should these functionalities be/use in wp site codebase?

For the moment I think keep them as it.

currently show_legend( $items ) is very tied to the $items, so either I change this function or create a new one?

I think adding an optional argument to the existing function with further statuses would probably be the way to go.

So do a PR (with tests please if possible) whenever you're ready!

(I noticed a few little things already (eg just make the extra $assoc_args arg to CommandWithUpgrade::status() optional so no need to add arg to theme one) but they can wait for the review...)

[danielbachhuber]

What happens when there's 50,000 sites to iterate?

Previously https://github.com/wp-cli/wp-cli/issues/1882#issuecomment-114840980

Generally, it's still preferable to use wp site list --field=url | xargs over adding some network-specific support a command. Adding network-specific support to commands is a deep rabbit hole ("how do I get all of the published posts on my network?")

[gitlost]

Ah very good - ignore me @LC43 !

[schlessera]

Yes, I agree with @danielbachhuber.

In terms of scalability, the number of subsites in a multisite network has to be assumed to be limitless. Going through all the sites to gather additional information is not an option in this context. It would potentially incur huge bandwidth costs on network and database, and as it collects all data to further process it, chances are very high it would run out of memory on larger networks.

I'm marking this as state:unlikely, as we won't include it as a bundled command.

@LC43 You can of course implement this as a third-party command for your own purposes. And in case you didn't know, you can override the bundled commands through third-party packages, so you can easily just extend the existing plugin status command in your own package and then install that over the bundled one.

[LC43]

Hi, and thanks everyone for the feedback.

@schlessera, i'll check that on third-party as this was really useful to our team, thanks.

I know this is already closed, but i'm going to try to explain why other commands don't this task:

e.g.: show which sites Contact Form 7 is installed ( not network activated ).

To @danielbachhuber questions:

Adding network-specific support to commands is a deep rabbit hole.

status_all() is already a network wide function, called when doing wp plugin status . I just expanded the information with --show-sites

What happens when there's 50,000 sites to iterate?

Well, let's assume the worst case : There's 100 plugins, and all are not network activated but active in each site individually.

so it will show 100 *50 000 = 5 000 000 lines.

the concatenated line will also show 5 000 000 lines and it doesn't solve the task at hand.

To find where the plugin is activated, using wp site list you'll have to manipulate the result with bash , filter out somehow the name of the sites, and concat it all together.

Differences:

sites per plugin vs plugins per site

It shows the which sites where each plugin is activated, in contrast to listing all plugins per site. I think this is a fundamental difference.

Skip network activated plugins

A better use case is that if if some plugins are network-activated, this will skip those. So the number of plugins shown is reduced.

Show the status of each site.

In our network we have only 250-ish blogs, which is a small number but large enough to make impossible for a human to go through all them one by one and check which plugins are active in individual sites.

some sites are archived, some are deleted.

legend: ( sorted items )

example: show where a plugin is installed:

wp plugin status --show-sites | grep "widget-context" -A 4
  I widget-context                       1.0.5
         -- PAD   171.Site A
         -- PAD   172.site D
         -- PD    213.Site B
         -- P     217.Site C

where -A xx can be an arbitrary number of sites.

anyway, thanks for listening. i'll update this when the 3rd party command is ready.

[gitlost]

You make a very good case @LC43 and I think this should be re-considered for inclusion.

just make the extra $assoc_args arg to CommandWithUpgrade::status() optional so no need to add arg to theme one

That by me was wrong as you probably noticed (get PHP warning about declaration should be compatible).

[LC43]

thanks for your support @gitlost :muscle: :dancer:

yes, i fixed it with only your suggestion to use default arg.

[schlessera]

I reopen this issue because I think the actual functionality would be hugely useful for managing large networks.

However, I'm still wary of the performance impact it could have on large networks.

I suggest building this in such a way that is has a safety threshold with a confirmation needed after a certain size.

This could use wp_is_large_network( 'sites' ) (which is filterable) or a direct count of the sites as the threshold.

The confirmation prompt could be something like:

This command will load data from each of your 53.243 sites. Are you sure?

It should include a force switch like --yes or --force for reliable scripting.

[jeremyfelt]

I've found https://github.com/iandunn/wp-cli-plugin-active-on-sites useful when needing to check a plugin's status across 1700 sites. I'm not sure if that solves all of the needs listed above, but it may be a good start. It looks for the status of one plugin rather than all of them, which has been more useful for my needs.

It does take a decent amount of time to loop through each site to check for an individual plugin's status. I would imagine that this task is better off as an external command.