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 11 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.