Plugin Replacements and aliasing

[ericp-mrel]

I see the following method in the winter blog plugin where it has an array of classes to alias https://github.com/wintercms/wn-blog-plugin/blob/main/Plugin.php#L116-L139 Is this still needed on the latest versions of WinterCMS (v1.1.6)? I couldn't find any references to that plugin's method anywhere in Winter\Storm library or any of the winter modules and so I assume that is just a legacy method which was used in an earlier build of Winter CMS and everything should be handled pretty much automatically from now on as long as the replaces key is defined in the Plugin.php or plugin.yaml file?

Just need to confirm as I am moving some of my plugins to a different namespace and want to make sure they will remain backwards compatible with the old namespace automatically.

Thanks!

[mjauvin]

That's exactly right, Eric.

[ericp-mrel]

Awesome, thanks!

[LukeTowers]

See https://wintercms.com/docs/plugin/registration#plugin-replace

[ericp-mrel]

On a somewhat related note, I have several plugins which depend on each other and I am changing the namespace of all of them and I am trying to use the replacements feature so I can gradually move them over one by one but some of them have polymorphic relations between each other.

What is the best way to deal with table names with something like a many-to-many polymorphic table. Currently I have a model which is something like this:

<?php
// Model from plugin which depends on Acme.Links plugin Model

class AcmeModel extends Model {

    public $morphToMany = [
        'social_links' => [
            \Acme\Links\Models\Link::class,
//            'table' => 'acme_links_linkables',
            'name' => 'linkable',
            'pivot' => ['order'],
            'order' => ['order'],
        ],
    ];

}

What's the best way to handle this situation where the tables are renamed to match the new plugin namespace on the Acme.Links plugin, because the problem is if you omit the table name from the relationship definition it doesn't reference the correct table in the DB. When omitted it tries to use the table linkables instead of adding the plugin namespace prefix automatically (acme_links_linkables).

[LukeTowers]

I'm not sure I understand exactly what the issue is

[ericp-mrel]

Alright, let me see if I can explain this better.

Hopefully I don't get in trouble for using the October name as an example, can't think of better names to use at the moment and I feel this name might help make the example more clear.

Just as an example, Let's say I have two plugins called October.Link and October.User and the October.User, October.User plugin depends on October.Links plugin.

Here are some example Models that could exist in both plugins:

List of Created Tables:

• october_link_links
• october_link_linkables (used for polymorphic relations to attach links to other models (e.g. User Social Links))
• october_user_users

<?php
// October.Link

class Link extends Model {
    public $table = 'october_link_links';
}

<?php
// October.User

class User extends Model {
    public $table = 'october_user_users';

    public $morphToMany = [
        'social_links' => [
            \October\Links\Models\Link::class,
            'name' => 'linkable',
        ],
    ];
}

So, right now even before we worry about the change in branding/namespace if you try to fetch the social links using the User model the query will fail, because it is trying to use the linkables table (which doesn't exist, because we vendor prefix tables). And so the only way to fix this is to hard-code the table name in the User model in the social_links relationship.

So that leaves us with the following model afterwards:

// October.User

class User extends Model {
    public $table = 'october_user_users';

    public $morphToMany = [
        'social_links' => [
            \October\Links\Models\Link::class,
            'name' => 'linkable',
            'table' => 'october_link_linkables',
        ],
    ];
}

With the table name hard-coded in the User model that at least gets the relationship working, but then if we re-brand the October.Link plugin to Winter.Link and change the table names replacing october with winter the polymorphic relationship will now fail to execute the SQL query because it is still trying to use the old october namespaced table.

The goal would be to not hard-code the polymorphic relationship table name so that either plugin can be used with the user plugin and not need to add a conditional checking if the October or Winter version plugin is installed and adjusting the table name with the correct prefix. Unless maybe creating a pivot model with a const is the best approach so that the User model can just reference the Pivot model and use the defined table name from there and everything would switch depending on which plugin version is installed?

Hopefully this makes sense and describes what I'm trying to accomplish in better detail.

[josephcrowell]

Just stop prefixing your private table names with october_ ... You'll have to rename them in a migration. Winter takes care of converting the dependencies from legacy October to Winter. You don't have to do that.

New builds of October no longer work with the marketplace so you're supporting legacy builds of October that will eventually die, however.

New builds of October also diverge from Winter enough to the point that they are no longer compatible. Even if you do find a way to make your plugin work with current builds of October and Winter, eventually they will diverge enough that it won't be possible to make the plugin work on both.

[ericp-mrel]

@josephcrowell I'm not actually using OctoberCMS, it was just an example Author namespace to demonstrate the original namespace of the plugin and Winter being the new namespace for the plugin.

But, the best way I can think of to deal with this situation of re-branding the tables and renaming them to the new migration. You would either need to update the plugin depending on the other plugin to only work with the new forked version and hard-code in the new linkables table or create some sort of pivot model which contains a constant or something which you can reference so the plugin dependent on the links plugin can use either the original version or the new "forked" version with the re-branded namespace tables.

[bennothommo]

@ericp-mrel You could take a look at what we did with the Winter forks of the main RainLab plugins - such as the Blog plugin: https://github.com/wintercms/wn-blog-plugin/blob/main/updates/v2.0.0/rename_tables.php

As long as you are using models in all queries and defined relations, it should be graceful, since the model defines the table used. I would recommend doing the rename as an important update so people are fully aware this is making a big change to the data structure.

[ericp-mrel]

Yeah, I've already looked at the winter plugins, but the problem is when using polymorphic many to many relationship, the table name must be provided unless you follow Laravel table naming conventions, but unfortunately that isn't the case due to namespacing plugin tables. This is kind of where I'm stuck on how to best proceed other than just making the plugin only compatible with the new namespace set of plugins. Luckily the plugins I'm doing this for are all internal, but it'd be nice to be able to convert them over one by one instead of needing to update them all to reference the new namespace straight away.

…

On Mon, Sep 13, 2021, 7:40 PM Ben Thomson ***@***.***> wrote: @ericp-mrel <https://github.com/ericp-mrel> You could take a look at what we did with the Winter forks of the main RainLab plugins - such as the Blog plugin: https://github.com/wintercms/wn-blog-plugin/blob/main/updates/v2.0.0/rename_tables.php As long as you are using models in all queries and defined relations, it should be graceful, since the model defines the table used. I would recommend doing the rename as an *important* update so people are fully aware this is making a big change to the data structure. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#306 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APFXGHHRP5ES547OX47WSVDUB2KZDANCNFSM5DX6OOUA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[bennothommo]

As much as it would be nice, the fact is we are simply going to diverge more and more from October as time goes on. The effort it would take to allow aliasing on all fringe cases is likely too much when faced with that fact.

I think we've reached a good balance between allowing people to move over with the most common plugins without any issue and keeping the performance implications and maintenance burden of the plugin replacement/aliasing feature to a minimum, but for specialised cases, it's going to be the hard question of going with October or going with Winter.

In your case, I think you could possibly achieve what you are looking for by using the extend method on the model with the polymorphic definitions and dynamically adjust the relation table as needed (ie. within a Winter project). That's all I can think of, off the top of my head at the moment.