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

[brandonkelly]

We discussed this internally and decided that there’s a legit need for private plugins in Craft. Modules are great for a lot of things, but the main thing they lack is the ability to be installed, and run their Install migration, which can be especially useful when testing.

So Craft 3.8 and 4.4 are going to include private plugin support (#12716). Private plugins are identical to normal plugins, with the sole difference that they are excluded from license verification. So you don’t need to worry about a third party plugin getting published to the Plugin Store with the same handle, and causing license validation errors for your plugin.

Private plugins are Composer-installed, Craft-installed, etc.. The only way they are distinguished is by having a plugin handle that begins with an underscore (e.g. _foo-bar).

[brandonkelly]

3.8 and 4.4 are out now! We’ve also released Craft Generator 1.3.0 which supports generating private plugins.

@bertoost Exactly. Private plugins don’t get license verification, and can’t be submitted to the Plugin Store.

[bertoost]

thanks @brandonkelly! I discovered the update blog and changelog since I got the update at a project last night 👍🏻

[MoritzLost]

@brandonkelly Is it possible to create a private plugin that's part of the git repository of a specific site? I've often wanted to create a plugin for some site-specific functionality, but ended up using a module because I really didn't want to have those plugins in a separate repository. The plugin documentation only talks about creating plugins as a separate repository – which makes sense for published plugins, but for private plugins it could make sense to create a plugin that isn't a separate Composer package.

Maybe the documentation could be expanded to cover this use case? Is it even possible to create a plugin in a custom location that's part of the repository (so outside the vendor folder)? I know this can always be solved using something like Git submodules, Composer scripts etc. But is there an 'official' way to do this?

[brandonkelly]

@MoritzLost Yes, by adding a path repository to the root project’s composer.json file.

If you use Craft Generator to scaffold the plugin, it will offer to create a path repository for you.

[MoritzLost]

@brandonkelly Makes sense, thank you!!