Repository navigation
Allow programmatic control of which modules are enabled #33
Description
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_modulesthat filters the return value of theperflab_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'shas_filter()function).
Activity
felixarntz commentedon Dec 2, 2021
cc @ThierryA I opened this based on your comment in #27 (comment).
eugene-manuilov commentedon Jan 8, 2022
@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.phpandload.phpfiles. 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 commentedon Jan 11, 2022
@eugene-manuilov can we remove the Needs Dev label from here too, as it is in Progress now? @bethanylang
eugene-manuilov commentedon Jan 11, 2022
Done.
felixarntz commentedon Jan 12, 2022
@eugene-manuilov I don't think
add_theme_supportis 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 commentedon Jan 12, 2022
@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?
felixarntz commentedon Jan 16, 2022
Could someone else review the PR #87? Approved from my end, but best to have at least two approvals. cc @JustinyAhin
felixarntz commentedon Jan 18, 2022
Fixed via #87