WooCommerce Admin Installation on E-Comm Sites

[timmyc]

With the vision to roll out the new navigation experience to e-Comm plan users, we will need to decide upon a mechanism to deliver the woocommerce-admin plugin to the install base. Currently the Atomic environment supports a few different options for inclusion of plugins like woocommerce-admin:

wpcomsh

this is how wc-calypso-bridge itself is installed on ecom plan sites. wpcomsh is a mu-plugin and it and its dependencies that are pulled in via composer are always loaded, and not visible in the plugin listing inside wp-admin.

managed, required

The next level of integration that can be seen for a plugin is one that is "managed" and users are not able to deactivate the plugin, Jetpack is an example of this:

managed, not required

A step down from that level is a plugin that is managed/included with the subscription, but it can be deactivated by the user in wp-admin:

bundled, but no visual indication

The last approach that can be seen on the ecommerce plan is how the extensions from the woo marketplace are included. They are installed, but do not have a banner denoting they provide a feature included with the plan. Users can deactivate and uninstall if they choose. @pmcpinto we might want to look into changing this since much of the value we deliver in the commerce plan is based upon the price of these extensions:

Or should we consider packagist here?

One last approach that I think we should also consider for woocommerce-admin inclusion is exploring the route of packaging a version of it inside wc-calypso-bridge itself via composer. This would allow for us to pin to specific versions/builds of woocommerce-admin that have ecomm-plan specific features included, and would also prevent it from being disabled by customers.

[timmyc]

@rrennick do you have any thoughts on the approaches here for shipping custom wc-admin builds?

[rrennick]

This would allow for us to pin to specific versions/builds of woocommerce-admin that have ecomm-plan specific features included, and would also prevent it from being disabled by customers.

Seems like the best route. We would need to ensure that our version was loaded prior to the package in WC.

Regardless of inclusion method, we might want to modify the info displayed in the SSR.

[rrennick]

Or should we consider packagist here?

I experimented with this and was able to get WCA loaded via Composer. Since the customer can still install WCA via the plugin installer, I tried that and got fatal errors. The code that arbitrates between WCA in core and standalone isn't designed to work with 3 instances. So, I'd rule out both wpcomsh and packagist.

[timmyc]

@rrennick and I spoke about the problem he outlined above, and Ron is going to explore a option to make the feature flag system in WCA filterable instead. Currently the feature flags are used during the build process, and after the build is done it isn't possible to toggle features on/off. So exploring that route might give us a good way for us to activate WCA features on the ecom plan when not active in core.

The other benefit of this, is it also sets up feature flagged items to be configurable by users via settings much easier.

[rrennick]

WC Admin PR: https://github.com/woocommerce/woocommerce-admin/pull/4418

I'd like to do a PR here that sets this repo up to implement the filters so that when it's time to turn features on/off it will be a small/quick code change.

[pmcpinto]

@timmyc what should be the next step in this issue?

[timmyc]

We don't really have a next step here - our solution instead is to ship features to wc-admin and use the feature flag system to toggle things on/off via wc-calypso-bridge like: https://github.com/Automattic/wc-calypso-bridge/pull/590

[pmcpinto]

Gotcha. So we can close this issue, right?

[timmyc]

yep!