Allow programmatic control of which modules are enabled

[felixarntz]

Based on the settings screen from #27 which allows to toggle individual modules on/off via UI, it should alternatively be possible to programmatically control which modules should be enabled. This can be useful for advanced users or environments which would like to use certain modules from the plugin without confronting end users with control over them.

Suggested approach:

• Introduce a filter perflab_active_modules that filters the return value of the perflab_get_active_modules() function.
• Skip adding the plugin's settings screen (see perflab_add_modules_page()) if the above filter is being used (check via WP core's has_filter() function).

[felixarntz]

cc @ThierryA I opened this based on your comment in #27 (comment).

[eugene-manuilov]

Suggested approach:

• Introduce a filter perflab_active_modules that filters the return value of the perflab_get_active_modules() function.
• Skip adding the plugin's settings screen (see perflab_add_modules_page()) if the above filter is being used (check via WP core's has_filter() function).

@felixarntz, how about using the theme support feature instead of the custom filter? In this case, if someone programmatically activates a module using the module slug (for example, add_theme_support( 'webp-uploads' )), they won't need to re-activate it in the future when this module makes it to the core.

I have prepared a draft PR #82 that implements this idea. Do you mind taking a look at it?

P.S: that PR contains some refactoring for the general utility functions defined in the admin/load.php and load.php files. Nothing special, just re-organised them a little bit and made it possible to use settings and module related functions not only in the admin.

[eclarke1]

@eugene-manuilov can we remove the Needs Dev label from here too, as it is in Progress now? @bethanylang

[eugene-manuilov]

Done.

[felixarntz]

@eugene-manuilov I don't think add_theme_support is appropriate for this, since these modules aren't theme features. While it would work, as the name of that function states, it should be used for theme features provided by a plugin or core, which would be enabled from within the theme's codebase. But the use-case here will be most likely must-use plugins, e.g. injected by an agency or hosting provider that wants the site to use a predefined list of modules and not allow the user to change them.

The typical core approach for modifying an option like this would be a filter as suggested in the issue description.

Looking at #82, it is massive for this type of change :) I don't think this is the right place to do this refactoring, typically in WordPress core changes should be kept as simple as possible and avoid refactoring unless it is necessary for the issue or if the issue itself is about refactoring. Can you please simplify this to working with how things are currently written? I don't disagree with the changes there overall, but we should discuss this in a separate issue - feel free to open one. 👍

[eugene-manuilov]

@felixarntz, ok, got it. Thanks for the feedback. I have decided to create a new PR with suggested changes: #87. Do you mind reviewing it?