Ability to extend core files

sijad

as is very discouraged to edit core files, It'd be great if there was an ability so developers could extends them
for example let think a developer wants to run some codes before Flarum\Core\Foo\FooClass::Foomethod but it can't done by listening to events, so developer can make a php class lets call it Acme\Bar\BarClass which contains this:

<?php
namespace Acme\Bar;
use Flarum\Core\Foo\FooClass;
class BarClass extends FooClass
{
	protected function Foomethod() {
		// do something here
		return parent::Foomethod();
	}
}

and flarum loads Acme\Bar\BarClass instead of Flarum\Core\Foo\FooClass. it's called Monkeypatch.
in php it can be done by using spl_autoload_register (same function that composer autoload using to load vendors classes)
what do you think?

Franz

Reminds me of AOP. Which, I think, this is a little over the top. 😉

As I posted it on GitHub, Flarum already is pretty extensible, by sticking to object-oriented coding principles and having events all over the core.

sijad

IMO you need to use Monkeypatch otherwise you have to add event fire everywhere like wordpress and it's not pretty

Franz

Well, if you have a use case where an extension can not be accomplished with the current system, please do tell us. 🙂

Davis

Franz While working on an extension I realized I had to recreate a decent amount of flarum API when I only needed to edit one controller file.

https://github.com/Dav-is/flarum-ext-inviteonly

luceos

Modded some message because they became too off topic in relation to the seriousness of the topic at hand.

ccesar

Well, maybe I have a use case.
It is not a serious project, but I wish a way to create "personas", sub-users, with all user properties, like avatar, signatures, etc. A user would choice a persona to perform the forum interactions, so the persona would own topics and replies, but he user would receive notifications. This is handy for roleplay focused forums, where each user can have many characters. SMF have a mod for this [1] and some other profile ticks related to roleplay forums or forums for players of MMOs.

There are some ways to do this, but all need some extra information on core models. We can:
1 - Create real users and handle the switch of users. We need to store who is the main user and who is a personas and route all notifications to active user. The easiest way for the first is extending core's User and core's notification system.
2 - Create dummy users that has a profile but no login information. The easiest way is to change core's Post and Thread to belongs to a persona and get visible info from persona class, and to a user, and send notifications to the user.

Without the ability to change core's class that maybe can be built monkey punching the post editor to add a character select, storing in a dedicated table the post and the character ids. So, we need to intercept post events to check them against this fast growing table, performs a lookup for the persona data and monkey punch name, avatar, signature, etc. Stills possible, but if the post belongs directly to the persona we would have less complexity and less resource waste.

1 - http://www.simplemachines.org/community/index.php?topic=241961.0

luceos

ccesar everything you explained can be done using Extensions, it might require some effort to do so, but it's certainly possible and not nearly as "complex or wasteful" as you say.

Extending core user. This is unneeded you can create a polymorphic table explaining what "personas" belong to each user. Or you can even then create a seperate table with its own model Persona (or use the user model) that extends the User model that sets a different table. Both implementations will require a session variable registering switch the "persona switched to" and the "user coming from". I would go for a seperate Persona model so you can trigger the right user for notifications.
This can be solved with my previous suggestions.

As an autodidact dev I might not make that much sense, I would love @Franz to reply with a technical differentiation of IoC vs your proposed monkey punching.

ccesar

luceos I think that can be done with extensions too, but with greater performance and complexity cost than overloading the core classes.
But with a deep thought on it, the core classes are ORM models and if we make changes in the models we will create plugin incompatibilities, and that is worse than some overhead.

Franz

Davis Are you talking about the RegisterController?

Davis

Franz RegisterUserHandler is the only file I modified but I had to create a whole new API route and copy over the controllers.

vabhik

Davis I've checked your RegisterUserHandle file. I've one doubt please help, are you able to upload an avatar through this route using avatar url in your api call ?
As I have seen in Flarum\Core\CoreServiceProvider class there is one method

protected function registerAvatarsFilesystem()
    {
        $avatarsFilesystem = function (Container $app) {
            return $app->make('Illuminate\Contracts\Filesystem\Factory')->disk('flarum-avatars')->getDriver();
        };

        $this->app->when('Flarum\Core\Command\UploadAvatarHandler')
            ->needs('League\Flysystem\FilesystemInterface')
            ->give($avatarsFilesystem);

        $this->app->when('Flarum\Core\Command\DeleteAvatarHandler')
            ->needs('League\Flysystem\FilesystemInterface')
            ->give($avatarsFilesystem);

        $this->app->when('Flarum\Core\Command\RegisterUserHandler')
            ->needs('League\Flysystem\FilesystemInterface')
            ->give($avatarsFilesystem);
    }

Wouldn't it be conflicting while we try to upload an avatar using any other handler ?

Davis

vabhik it's possible. I haven't had much time to look at it.