loadPlugins() is now the preferred option, since it does all the proper checks.
In addition, the server now acknowledges that loading a single plugin may cause multiple plugins to be loaded, so returning only a single Plugin is not representative of what's actually happening.
loadPlugins() is now a superior option to loadPlugin(), since it enforces dependency checks and also supports automatic loading of plugins when new loaders are installed.
it's not worth this turning into compatibility baggage just so that we can parse plugin_list.yml, especially when we have new ways to handle data parsing coming in the pipeline.
For something as small as plugin_list.yml, it's easier (and in this case better too) to just validate it manually (respect/validation was anyway too strict considering it's YAML we're dealing with).
for some reason we were reading and parsing the plugin.yml at least twice for every plugin loaded.
We were repeating work already done by the initial loadPlugins() triage (discovering correct loader, loading plugin.yml from disk, parsing plugin.yml, validating plugin.yml) every time loadPlugin() was called with that plugin.
this could lead to harmful results, e.g. if a developer typo'd while writing the plugin.yml, an admin-only command could become accessible to everyone, since commands are by default accessible by everyone.
this makes translation usage much more statically analysable.
The only places this isn't used are:
- places that prefix translations with colours (those are still a problem)
- places where server/client translations don't match (e.g. gameMode.changed accepts different parameters in vanilla than in PM)
it's better to just implement this for stuff where there's explicitly designated aliases, otherwise we could end up with unexpected BC breaks (e.g. hardcoding POSTWORLD in plugin.yml would suddenly break if the core enum was changed, even though it remained valid).
* Allow plugins to use PSR-4 namespace mapping
this is a reduced implementation which serves the 99% use case without being horribly breakable.
Plugins may now specify a `src-namespace-prefix`, which should be set to the namespace of the classes in `src`.
If the old system is used, `src-namespace-prefix` can be omitted, or set to an empty string.
Examples:
- If `src-namespace-prefix` is `dktapps\test`, `dktapps\test\Main` will be searched for in `src/Main.php`, instead of `src/dktapps/test/Main.php`.
* Migrate TesterPlugin to PSR-4
Plugin is the interface by which the server core interacts with plugins, so it should be limited only to the stuff that the server actually uses.
These methods are still provided by PluginBase, so in 99.9% of cases there will be no BC break.
literally nobody uses this. I don't think anyone even knows it exists.
It's also an obstacle to separating event handler registration from PluginManager.
this fixes#3200.
This causes permissions to be registered before plugin load, which changes some behaviour, but after discussions on #internals-dev we couldn't see any reason to keep the behaviour the way it was, and several reasons to change it to be something like this.
this fixes a few crashes that could appear from invalid plugin_list.yml setups, which was the reason #3228 was opened to begin with. Respect also has nicer error messages, as long as you don't use the static API :)
