Provide a base "Module" to help scaffold Craft specific things for developers

[Mosnar]

Description

Having barebones modules is great, but sometimes we need to be able to save some settings from the CP. We can achieve this of course; however, the amount of boilerplate code necessary to add a settings page and show an icon in the CP is significant. The alternative is to use fields and globals; however, I've always thought this felt a bit awkward since the fields are storing settings rather than content - which could lead to things like API keys getting exposed. It would be nice if Craft provided an abstract "BaseModule" and/or a "ModuleSettingsTrait" that would provide minimal Craft integration of our module, similar to the base Plugin class.

As I write this out, it feels like what I'm essentially asking for is the ability to create private plugins; which has been a topic of discussion for a while. Maybe this is an adequate solution to that problem?

Related

#3314

[brandonkelly]

If we do this, I think it should be done in a way where the base Plugin class extends it, so we aren’t doubling our efforts.

[Anubarak]

@Mosnar What would be the difference between a plugin and a private plugin?

[Mosnar]

@Anubarak The trouble with plugins is that they presume you're going to publish them publicly simply by existing. The issue really comes down to the plugin handle being used for licensing. For example, early on in Craft 3, we created a small plugin to store the view counts on entries - since modules don't support self-contained migrations, we made it a plugin rather than a module in the case we want to reuse it. A few months later, a view count plugin with the same handle was published and the CMS began showing a license error. Not knowing any better, the client went ahead and purchased the license (you're welcome @lindseydiloreto)

I've heard on Discord of people submitting their plugins to the plugin store without publishing simply to reserve the handle.

Further, a "private plugin" is one I would expect to behave more like a module, where it is always enabled and cannot be removed by the user as it was probably added to support some critical core functionality.

Of course all of this can be accomplished in Craft one way or another, it just makes scaffolding a little more time consuming and begs to be canonicalized.

[mmikkel]

Tangentially related: I'm sure there's a good reason for it, but I've always been puzzled that the Plugin Store doesn't use the package name (i.e. vendor/pluginhandle) and not just the plugin handle, to identify unique plugins.

[brandonkelly]

@mmikkel That’s explained here: #3054 (comment)

[Anubarak]

@Mosnar there is (in my opinion) a simple solution for this: use a unique constant as plugin handle instead of a hard coded string. it's really easy to change the plugin handle in that case, furthermore you can use something unique like "vendor-prefix-plugin-handle"

I don't really see a benefit in a "private" plugin class. The issue is one can then fork the plugin, just switch the class and get if for free without much issues. Of course there are several ways to get a plugin for free but having a private class for this makes it much more easy.

Maybe it's just me but handling custom settings in modules and storing those doesn't require that much effort. And if it does for you, maybe a trait would be more helpful 🤔
They could provide a ModuleSettingsInterface with a ModuleSettingsTrait to handle such things. I did the same by the way