Define default module activation (onboarding)

[ThierryA]

Opening this issue to discuss if modules should be activated by default or not, maybe all modules other than the experimental for instance. When someone install the plugin, the expectation is generally that there is some preset for features right away.

If it is justified not to have any modules activated, we should at least guide plugin users to the module activation page, for instance redirecting to settings page upon plugin activation with a notice informing them to activate modules (and/or wp tooltip maybe).

[jeffpaul]

Given that this plugin is intended to improve performance, I would be in favor of having all but the experimental items enabled by default and also with an admin notice and settings link on the plugin install page that directs users to the plugin settings page so that they can disable/enable other things that best fit their needs for their site.

[mitogh]

I would be in favor of enabling all the modules by default as long as WP_DEBUG is defined and is set to true usually this is helpful for non-production environments.

Enabling all the modules specifically the ones that might have an impact on the aspect of the site on production by default like changing the enqueued or priorities of assets (JS/CSS) and such might have an impact on the aspect of the site. With that being said I think modules that are BE heavily like changing the default type of image for new uploads can be safely activated as those do not have an impact on the existing behavior of the site. Any module that changes the markup or might modify the aspect of the site should be disabled by default for production environments.

One thing that would be great to integrate is to enable modules during runtime using a query parameter so it can be tested in production without a global impact on the site like: ?performance=module1 would enable that module during that specific request only. Having this behavior can be used to compare before vs after as well in a single page request.

Another thing is even if all the modules are enabled by default some sort of control where the modules can be toggled from within the admin as well.

[tillkruss]

+1 for activating non-breaking modules by default.

[ecotechie]

I would like to see a test for WP_DEBUG and WP_ENVIRONMENT_TYPE. If debug is not on or environment is production, then none of the modules activate on plugin activation. We don't know who will be installing this plugin and what will break if they do. Making enabling modules easy and understandable is a great option. Aren't all the modules experimental? We don't know what will/won't break on sites other than ours... Otherwise these modules wouldn't be here. I like the query string idea as well!

[eugene-manuilov]

We don't know who will be installing this plugin and what will break if they do. Making enabling modules easy and understandable is a great option. Aren't all the modules experimental? We don't know what will/won't break on sites other than ours... Otherwise these modules wouldn't be here.

I agree with this statement. We can't know who will be using this plugin and what may break if they install it on production and activate it without checking for compatibility. All modules in this plugin are experimental to a certain degree and I think it would be better if we force site owners to manually activate modules that they need so that they will need to evaluate the risk of activating a module themselves.

One thing that would be great to integrate is to enable modules during runtime using a query parameter so it can be tested in production without a global impact on the site like: ?performance=module1 would enable that module during that specific request only. Having this behavior can be used to compare before vs after as well in a single page request.

This is nice, but in some cases "query string activated modules" can affect other pages as well 🤔. For example, if a user activates the object cache module and it flushes or changes cached data, it will affect other pages where that data from the cache is being used.

[ThierryA]

We don't know who will be installing this plugin and what will break if they do. Making enabling modules easy and understandable is a great option. Aren't all the modules experimental? We don't know what will/won't break on sites other than ours... Otherwise these modules wouldn't be here.

I agree with this statement. We can't know who will be using this plugin and what may break if they install it on production and activate it without checking for compatibility. All modules in this plugin are experimental to a certain degree and I think it would be better if we force site owners to manually activate modules that they need so that they will need to evaluate the risk of activating a module themselves.

Some module will be tagged as experimental when we don't have confidence it won't break sites. For all other modules, they will be developed with the goal of being production ready and therefore we should consider making them enabled by default. In theory, all plugins should be installed on a testing environment prior to be rolled out to production, this one is no different in that sense.

[JustinyAhin]

I am also in favor of enabling by default the modules that are ready for production. Perhaps in this case we should keep an updated list of those modules that will be activated in the plugin's README.

Also, I'm not too much in favor of an immediate redirection to the plugin settings page after activation. We could opt for an approach similar to the WP Reset plugin (https://wordpress.org/plugins/wp-reset) which displays a small tooltip when the plugin is activated (see screenshot). It's less invasive and unexpected.

[mxbclang]

Please vote for this approach with a thumbs-up or thumbs-down emoji. Voting will close on 1 Feb 2022 at 6pm GMT.

Non-experimental modules will be activated by default; experimental modules will not be activated by default.

[mxbclang]

Voting is now closed.

Based on 19 thumbs up votes and no thumbs down votes, we'll proceed with this behavior:

Non-experimental modules will be activated by default; experimental modules will not be activated by default.

Removing Needs Decision label and adding Needs Dev label.

[kirtangajjar]

@felixarntz I see this issue has a "Needs Dev" label. I would like to take up this issue if you're fine with it.

cc @eclarke1

[felixarntz]

@kirtangajjar Awesome! Assigned the issue to you, feel free to ping me on the PR for review as well.

[felixarntz]

@kirtangajjar Any update on this one? Since it was assigned to you a week ago, it would be great to have a PR to review, especially since this is blocking the initial plugin release.

If you don't have capacity to do it, no worries at all - just please provide an update here.

[kirtangajjar]

Hey @felixarntz, I was mostly busy with other tasks I had this week. I was unaware that this is task was a blocker for the initial plugin release. If I knew about it, I would've prioritised accordingly.

I still managed to create a POC in my local environment in which non-experimental modules get activated by default and it's working for me. I was going to create a PR on it, but I was thinking to create one after I add WP admin UI pointer as described in #61 (comment)

However given the urgency of the issue, I will create a draft PR for it on Monday and share it here so I can get feedback on the work done till now and then add the wp-admin UI pointer.

[felixarntz]

@kirtangajjar Let's focus only on the default active modules in this issue. While the admin pointer came up here, that is more of a separate topic IMO and we should open a new issue for it. cc @JustinyAhin

[kirtangajjar]

@felixarntz Please checkout #191. Added you as reviewer too :)

[felixarntz]

I've opened #193 to implement the suggestion from #61 (comment)