Create a standard to limit plugin command names, permission nodes and more

We should create a standard for Plugin Development.

This standard should define:

  • What folders should a plugin create (Lowercase, the same as the plugin name, …)
  • What permission nodes should the plugin declare (All nodes with a standard name like pluginname.whatever)
  • What commands does the plugin handle (I hate commands that register commands like /world or /player, they should register /pluginname whatever, unless we are talking about essentials (/spawn, /home…) or complex plugins.

Also Sponge should check the list of plugins loaded and check it with an optional config list (To check that all expected plugins are loaded) and to stop the server if the owner expects some plugin to be loaded that is not loaded (Because it may have crashed).


I disagree on just about every point made.

The plugin folder should/would be the name of the actual plugin (ID).

As for every other point, stop trying to police. It’s not our job to do so. If a shitty plugin is made no one will use it. If they do then there is a demand and WE should adapt to support what the community want.


Just… No…

Plugins should not be restricted just like what @ElgarL said.

However a plugin days folder should be recommended.

I am not trying to be mean about it. Devs just should not be restricted.

A version command would be nice although that is not a plugin standard.

Maybe not restricted but reccomended.

I will agree with Kevin96AT on the matter of adding a file with permissions and possibly the commands associated with it. It’s simple and it was one of the weaknesses of Bukkit, having to go to every individual page for every plugin to hunt down the plugin permissions and commands associated with it. With his suggested idea, you only have to look at one place for permissions, your own plugins folder. I’d definitely support adding that to the system.

1 Like


For folder names in bukkit I believe currently uses a-z,A-Z,0-9,"_", “-” and no space(spaces are converted to an underscore.)

It would be incredibly inefficient if you had to enter in the plugin name for ever command that you used on the server.

1 Like

I think there should be a kind of guidelines for plugins - if there will a distribution platform, plugins which do not match these maybe could get banned. This leaves the opportunity for server owners to create shitty plugins, but if they want to release them via the platform, they have to pay attention to those little formalities.

Would make permission management or something like that a lot easier!! :smiley:

In my opinion, those guidelines don’t have to be very strict - I think it’s okay if they are limited to name + folder, the permissions format and no reload command but handling a ConfigurationReloadEvent (of course only if it’s implemented ;)) - last thing would require that the files are checked by a staff, as some plugins don’t have a config.

Also a permissions.json, a commands.json, a help.json and using the translation API (if implemented) should be suggested and the uploader should get warned about not including them.


You mean a “Sponge Plugin Code Of Ethics”

1 Like

Pretty much the only thing that I agree with the OP is that there should possibly be some basic formatting control of the plugin folder name for its config, if you do it through the plugin ID name then you could restrict the plugin id name to common non-special character names, kind of like what they do with bukkit.

People who would read these guidelines (especially community driven ones) would follow these conventions anyway.

Some of the plugins in bukkit do this already(like /wg for the worldguard control commands.), but it’s the decision of the plugin authors whether or not they want to do that, and it should stay that way(That’s my opinion.).

1 Like

Well I kind of replied with the mind set of what the OP would want which sounds a bit like a restriction of command names, which is why I may have come off in a bit of a brash way.

1 Like

I really like this idea. With the permissions I suggest that the permissions for that specific plugin can be divided into groups as said, but there is still a central permission file that would inherit from these groups using pluginname:group.
For example, Essentials permission file would have a group like teleport, that allowed all teleportation commands, then in the central permission file you could just give the owner the teleport group. This way the next day you could give the same teleport group to donators without a lot of work.

1 Like

If you ban one on a guideline you have to ban ALL who break that same guideline. Then it’s not a guideline it’s a rule.
If you want to create a tutorial for writing plugins you are more than welcome. Forcing people to use it is definitely a no-no.

Sponge is an API to help and encourage plugin development. If we go the route of “YOU MUST DO IT OUR WAY” we fall into the horrible ways of Bukkit.
Innovation comes from experimentation and in most cases it comes from people not trained/brainwashed into thinking the same as everyone else. Lets not stifle that creativity before it’s even had a chance to see the light of day.


Actually. If you open up a bukkit plugins jar-file with winrar or some other archiver you’ll notice that most include the permissions in the plugins.yml file that you can find there. :wink:

1 Like

The plugins yml file is being done away with in sponge, so you would have to rely off of getting the perms off of the plugins pages for the individual plugins, if there isn’t another way if getting these perms.

Well, then it has to be solved one way or the other. I just answered to the old bukkit plugins not containing the perms. :slight_smile:

Use a plugin if you want to. If a plugin is well documented and contains what I need, I will most definitely use it over a plugin that is not well documented and has no readily available support.

I think the idea of having the commands.json, permissions.json is definitely a great idea, but thats provided the dev keeps those files updated as they make changes to the plugins, there is nothing more frustrating with bukkit than having to dig around for permission nodes or nodes that don’t match up to what they have listed, sometimes resorting to checking the plugin.yml to find its incorrect as well so turning to a decompiler and digging throug hsource for them.

as a developer (and i know there’s a handful that agree with me on this) i kinda found it unnecessary for there to be anything outside of the code (e.g. the plugin.yml in Bukkit). of course, this is purely preference but outside configuration files everything can be done by implementable classes and/or annotations as done in the main class of a Sponge plugin (@Plugin(id="", name="", version="")).

1 Like