Update PL settings screen with new UI to manage standalone plugins and built-in modules

[felixarntz]

Feature Description

Following #618 (comment), this is the first of a few issues to work towards removing the published standalone plugins from the Performance Lab plugin and, as part of it, refactoring the plugin's settings screen to focus on managing those plugins as well as enabling a smooth migration for existing users of the plugin.

All this will eventually need to be published in a single release 3.0.0, which should bump the major version number due to that significant change in user-facing behavior.

It is also worth highlighting that the implementation of these additional issues should only start once the previous milestone of publishing standalone plugins is completed (i.e. after #635 #636 #637 #638 #639 #640).

This issue, likely the most time consuming one, is focused on modifying the UI of the settings screen:

• Today it shows the list of modules, with checkboxes for which one to enable.
• Going forward, it should be broken in two sections, one for managing the standalone plugins that are performance related core feature projects, and another one for managing the remaining built-in modules (likely only Site Health).
  • This will likely also involve changing the UI controls available, as installing / activating / deactivating plugins will require a more explicit action than just toggling a checkbox.
  • It will also involve including additional capability checks, since not everyone that can access this screen can install or activate plugins.

Requirements

• TODO.

[10upsimon]

@felixarntz @joemcgill I've picked this up again. Based on my notes and cross referencing this comment in an associated Asana task, I mocked up some screens to re-visit the conversation so that I have some pointers to work on. Based on my understanding, we needed UI mocks for:

1) A notice to render in the admin, likely on plugin install/update. I assume a notice of this sorts (ignore the wording, just a mock) with a CTA to the performance settings page is what we are after:

2) On the performance settings screen, a notice similar to the above that still indicates usage of legacy modules and encouragement to update, but ALSO a list of standalone plugins. If a certain plugin is detected as having the legacy module equivalent used, mark is such, in my case not so subtly (this is just an over exaggerated example), and continue to list available modules below:

I originally had the above far more detailed and identical to the core plugins tile screen, like this:

I am however not so sure it makes sense surfacing that information at all? I am referring to plugin ratings, compatibility etc.

I am leaning more toward not having this UI install the actual plugin (as we explicitly stated not sinking unnecessary effort into this) and maybe just linking to the core plugin add screen with the exact plugin name filtered. HOWEVER, this is not too feasible as searching for "WebP Uploads" or "webp-uploads" for example surfaces a lot of plugins prior to the actual one want, so maybe programmatic installation will be needed after all?

Keen to hear your thoughts on this.

[felixarntz]

Thanks @10upsimon, those mocks look amazing! 🥳

I think the notice in 1) makes sense, we can discuss the details of the text and whether it should have some action button or link separately. Let's continue that discussion in #652, which is where this work should happen.

For 2), I agree with you that your first mock works better, as it's less visually overwhelming and provides all information necessary. I personally think this is in fact good to start the implementation on. I definitely prefer having the UI to install/activate the plugins in this screen rather than linking to Plugins > Add, due to the problem you've described, and also it makes generally for a worse UX due to more clicks and cognitive overhead to getting to the right place.

My only additional idea, or rather something I'm curious about is, how would the plugin card look like for a performance plugin that is already active? Maybe we would replace the button with a text that clarifies that it's active? We should also provide a "Deactivate" button, but IMO that shouldn't look similar to the "Activate" button in those cards, but rather something more subtle, looking more like a link, but red (e.g. like "Deactivate" looks like in the plugins screen). The "Active" text could be positioned in place of the "Activate" button, and the red "Deactivate" link could be somewhere below? Maybe under "More Details"? Curious what you think, maybe you can create a mock for this state as well?

---

In terms of implementation, for this issue, let's focus only on the new UI for the screen, without considering the migration aspect (e.g. the red notice within the "WebP Uploads" box in your mock, and the admin notice should not be implemented here, but later as part of #652).

Let's create a new feature/* branch from trunk that we can work against, as the PR for this work must not be merged into trunk (we must only merge all the work from those couple issues once they're ready to ship holistically).

[10upsimon]

@felixarntz I've taken into account your feedback, and simplified the UI a bit. My only slight concern is that I am wondering whether the green "Plugin Active" label looks too much like a button or some form of CTA. Image to follow:

I also took a stab at adding a slight green box shadow to the active plugin box in an attempt to highlight the fact that it was active, but this may be venturing a little too far outside of the parameters of best practice in terms of existing core UI. Image to follow nonetheless:

I've also removed the red notice text and banner on top of the screen, to revisit as part of #652 as you rightfully pointed out.

I've begun engineering discovery as well, to get an idea of how we could implement this using as much as possible from core, and in essence have begun implementation.

[felixarntz]

@10upsimon Thanks for the updated mock! I think the green looks a bit too much and isn't consistent with other WP core UI, I don't think it uses this green UI anywhere. Plus I agree it looks too much like a button you're supposed to click.

I just had the idea that WP core would probably already have something like this in the Plugins > Add New UI, and it's indeed the case: Maybe we should just go with the same approach, a disabled button that says "Active" (see below screenshot)? The red "Deactivate" link you have below looks good to me.

[10upsimon]

Great call @felixarntz this looks way better IMO. Happy to proceed as such for now?

[felixarntz]

@10upsimon That looks great!

[10upsimon]

@felixarntz please see the Pull Request for this issue, open at #864

cc @joemcgill @mukeshpanchal27 @westonruter @swissspidy @kt-12 I have added you all as reviewers, feel free to remove yourselves though. Thank you!

[felixarntz]

Fixed by #864 (in feature/creating-standalone-plugins branch).