This needed a thread. It's a huge topic.

We can start simple: Which areas of XMB should NOT be pluggable? For example, I would like the installer script to be off limits, unless someone has a significant use case for cluttering up the install system.

Flushedpancake already suggested in a few places using a hook philosophy. I'm not sold on any particular philosophy yet. To me, hooks mean clutter and perfmance drag. We could avoid some of that using the Laravel Service Container style of class re-binding, however that comes with its own problems of duplicating entire files worth of code just to change one thing (to the exclusion of all other plugins).

I agree with not cluttering the installer at all. A separate system for plugin upgrading/maintenance would probably cause less hassle and breakage between versions.

Class rebinding is closer to the older 'hacks', so it might be more appropriate for those who have previously made things for XMB in the past - like you pointed out it means faster performance too. Probably more flexible overall, even if it's harder to maintain over time for potential authors, but it's also an interesting proposal I'm not sure other major forum vendors are applying, so I'm not opposed to it.

(Plus it might actually be easier to maintain templates with your proposal: I remember MyBB's hook/templating system being implemented in such a way that it forces you to disable and re-enable plugins whenever installing a new theme)

So I did a thing, and asked ChatGPT about it all, since I'm thick as anything and don't have a brain. Or well, I do, but it's not useful for coding and stuff.

I also gave it a lot of the core code to analyse so it could come up with something. Pretty interesting, tbh.

Attachment: XMB hook proposal from chatgpt.rtf (7kB)
This file has been downloaded 74 times

Stupid thing wasn't able to automate changing all the lines in the translations to use single quotes though, hmph

Code:

foreach (glob('plugins/*/plugin.php') as $file) { require $file; }

I think that AI learned PHP in 2001

We have to put all options on the table. What about the microkernel pattern? I see projects like Drupal and Nextcloud where everything is a plugin, not just the customizations.

Should we try weird ideas like hooks inside of templates?

Reading about the mediator pattern makes me crazy. It's so poorly defined. Some people talk about it like a strict OO philosophy. Others say it's just a synonym for centralized information flow where the event subscriptions are tracked centrally as opposed to each plugin acting as its own event notifier service.

Quote: Originally posted by miqrogroove

Code: foreach (glob('plugins/*/plugin.php') as $file) { require $file; } I think that AI learned PHP in 2001

technically, everything I knew in php is entirely based off tinkering some early 2000s stuff, and is completely useless now

Quote:

We have to put all options on the table. What about the microkernel pattern? I see projects like Drupal and Nextcloud where everything is a plugin, not just the customizations.

There's definitely some good in this concept, but I'm not entirely sure it fits the scope of the software's appeal both right now and going into the future.

Quote:

Should we try weird ideas like hooks inside of templates?

This was actually an idea I had in mind (though I don't think it's weird, personally!). Being able to extend templates without having to outright edit them manually would actually be incredibly useful.

Quote: Originally posted by flushedpancake

Quote: Originally posted by miqrogroove   We have to put all options on the table. What about the microkernel pattern? I see projects like Drupal and Nextcloud where everything is a plugin, not just the customizations. There's definitely some good in this concept, but I'm not entirely sure it fits the scope of the software's appeal both right now and going into the future.

I'll be honest, the scope and appeal of XMB as-is might be incompatible with a modern plugin system. Taking today's procedural code and littering it with dynamic hooks to produce a WordPress-like monstrosity with load times in the thousands of ms makes me sad.

If we look at some other framework philosophies, they can be suggestive of a system where hooks are dynamic only within the plugin registration phase. We can then take a leap from userland hook resolution to a mild form of self-modifying code where each hook is nothing more than a placeholder which gets swapped for native PHP code and saved in a new PHP file every time a plugin is activated or deactivated. This would be a very slick way to maximize performance. The other implication is that it would not be possible to modify any hook registration while handling a page request.

Quote:

If we look at some other framework philosophies, they can be suggestive of a system where hooks are dynamic only within the plugin registration phase. We can then take a leap from userland hook resolution to a mild form of self-modifying code where each hook is nothing more than a placeholder which gets swapped for native PHP code and saved in a new PHP file every time a plugin is activated or deactivated. This would be a very slick way to maximize performance. The other implication is that it would not be possible to modify any hook registration while handling a page request.

Yeah, we don't need to go too overboard with the system to the point of it being, as you said, a 'Wordpress-like monstrosity'.

This sounds simple enough for the needs of most things that were usually hacked into XMB and it keeps the performance steady, so I'm perfectly happy with this approach.