Plugin store licensing issue

[matt-adigital]

Description

We created a plugin a few months back whilst building a site and given it a pretty generic name (Importer) so that the client could see what it does. We've not released it as it is quite specific to the needs of this project due to their internal API which they are using. Instead we are including the plugin as a local repository after following the steps described in this article. The client has recently reported seeing a licensing issue banner though at the top of the CMS related to the plugin. This has confused us as it is a plugin which we built that isn't on the plugin store and hasn't had any issues or changes made to it for the last few months.

After doing a search on the plugin store for "importer" we cannot see any plugins published with the same name. We did find one here though with a cost attached to it.

Possible Solution

We could simply update our internal plugins name but theres nothing to stop this from happening again in future, unless we uses an obscure name that the client probably wouldn't understand. A better solution would be if it was possible for the plugins to match on their composer.json name attribute e.g. adigital/importer. I'm not 100% sure on how plugins currently check their licensing rules but this could act as a unique identifier and eliminate the possibility of this happening for anybody else. Thank you.

Additional info

• Craft version: 3.0.13.2
• PHP version: 7.1.19
• Database driver & version: MySQL 5.7.22
• Plugins & versions: Importer 1.0.0

[brandonkelly]

We chose to validate based on handles because they are harder to change. If we used the package name, and you wanted to use a commercial plugin without paying for it, all you’d have to do is fork it, and install your fork.

For internal stuff, writing a module rather than a plugin is probably a better option. I’ve started working on documentation for that approach on the v3-restructure branch of the docs. Key pages so far:

• Extending Craft
• How to Build a Module

The docs don't cover it (yet), but modules don't have to live within the project repo; you can build them as their own Composer packages just like plugins, and add them as dependencies wherever needed.

If you’re interested in going that route, please feel free to let me know what areas you could use more clarification on, either in Slack or Discord or as issues on the craftcms/docs repo.

[matt-adigital]

Cheers for the links Brandon. For now I've updated the plugin handle and fixed the knock on effects of that so that the client no longer sees the banner at the top of the CMS. Moving forward though I shall refactor this plugin into a module using the documentation you've provided (and of course pluginfactory.io). Thank you very much for your help.