App Store

[FoksVHox]

I remember Dane talked on a Livestream about some sort of default app store for extensions. Personally, I like the idea, and I think that this thread could be a good place to discuss that feature.

@DaneEveritt, are you able to elaborate on how you think it would work?

[catalystsitaly]

support for non open source extensions which is like the wordpress eco system

[FoksVHox]

If this suggestion comes to reality, then this should be possible to make. Personally, I'm currently ready to start working on a PR for it, however, I still don't know how I would be able to add modifications to Wings, without mixing the code (like a modular solution) when I have overcome that, I should be able to start on it.

[FoksVHox]

Personally, I think the best approach to this is using https://github.com/nwidart/laravel-modules which does all the necessary things to have modules enabled/disabled. My biggest hiccup is with Wings, from my knowledge of Go, you're not able to have something like laravel-modules in Go.

[matthewpi]

With the way wings is currently laid out, adding a "plugin" system would be complicated, time consuming, and would be difficult to manage. Wings is highly complicated (when compared to the panel) and has a higher risk of any addons causing problems or instability by merely calling a function at the wrong time. There are ways to load go code during run-time through the use of yaegi or something similar, but these have their problems and downfalls.

I am aware of the want/need for there to be a way for people to extend functionality, especially in wings, but like many things, there is never a simple answer.

[FoksVHox]

@matthewpi I totally understand that. I just hope that some of this functionality is coming soon. Cause if I wanted to have two different addons in Wings, that would almost be impossible at the current state of the extensibility. Personally, I feel the extensibility was removed when we went from JS to Golang :(

[schrej]

The old Daemon wasn't really extendable either. It was just easier to hack stuff into it as you don't have to compile it. Well, and JavaScript makes it way easier to hack around in general (and produce horrible, unsafe code) as you can override methods in a somewhat non-destructive way more easily and so on. If you want to extend wings, you can also do that, but you'll have to recompile it yourself (which is as easy as it can be).

Go has a plugin system in it's standard library, it's just a lot of work to properly integrate that into wings. Then people will also cry for automatic distribution and upgrades of those plugins and so on, which makes it even more complex.
It certainly would be cool to have that though.

[DaneEveritt]

It would be cool, but I'm not really interested in building out such functionality. Absolutely none of this is easy, and lets not forget the complete nightmare that it will be when random combinations of plugins cause crashes/open security vulnerabilities/etc and then we have to deal with bug reports and try to track down if some external plugin was the source of the issue.

[FoksVHox]

The old Daemon wasn't really extendable either. It was just easier to hack stuff into it as you don't have to compile it. Well, and JavaScript makes it way easier to hack around in general (and produce horrible, unsafe code) as you can override methods in a somewhat non-destructive way more easily and so on. If you want to extend wings, you can also do that, but you'll have to recompile it yourself (which is as easy as it can be).

Go has a plugin system in it's standard library, it's just a lot of work to properly integrate that into wings.
It certainly would be cool to have that though.

I understand that, but my biggest argument that there should be a plugin system/module system is that with the current version, it is hard really hard for addon developers, to create an addon for Wings, if the user wants to have two addons at the same time, without giving the source code out.

Then people will also cry for automatic distribution and upgrades of those plugins and so on, which makes it even more complex.

This shouldn't be a thing that Pterodactyl handles IMO.

@DaneEveritt

It would be cool, but I'm not really interested in building out such functionality.

I understand that your standpoint might have changed since you did that since you made that interview in October.

It would be cool, but I'm not really interested in building out such functionality. Absolutely none of this is easy, and lets not forget the complete nightmare that it will be when random combinations of plugins cause crashes/open security vulnerabilities/etc and then we have to deal with bug reports and try to track down if some external plugin was the source of the issue.

I clearly understand that you spend your free time on this, and I'm great full for that. I know it would be a big maintenance burden on the Pterodactyl teams shoulders.

[AlphaCraft9658]

I would actually support the idea of a proper extension API or something like that. There is Blueprint, but most plugins are paid and proprietary, it's third-party code being injected into Pterodactyl, and I also couldn't get it running.

[prplwtf]

You'd probably see the same result if there would be an official extension API as developers usually want to get paid for their work.