AliasType plugins

[kimpepper]

No description provided.

[davereid]

We'll want a generic ContentEntityAliasType instead of NodeAliasType

[Berdir]

I guess this should then extend PluginConfigurableInterface and PluginFormInterface.

[Berdir]

I think we should include the module name in the path here, Plugin/pathauto/AliasType probably.

[kimpepper]

OK. Forgot we're not in core anymore. :-)

[davereid]

So interesting to note that I think that the actual configuration form should be Pathauto pattern config entities, not forms provided by the AliasType plugin. We want to get far away from having a 'giant screen of pattern inputs' - see https://www.drupal.org/node/273104#comment-2452322

[davereid]

I wonder if we could also use derivatives for not only all the entity types, but all the bundles, and then translated language as well

[Berdir]

So interesting to note that I think that the actual configuration form should be Pathauto pattern config entities, not forms provided by the AliasType plugin

I don't understand this.

I want to clarify that all I want to do here is replace the existing hook by using plugins. If we want to completely plugify the whole module, this issue will never be done. I don't expect a perfect solution, just some that is at least as good as what is there now (which shouldn't be too hard ;)).

[davereid]

The forms for patterns should not be in these plugins. They should be config entities.

[davereid]

Hrm, I guess the plugin could have the configuration form for the pattern, but it should be one pattern form in the plugin, and not a lot of patterns, since we'd be using derivatives for those.

[Berdir]

The arguments here changed, parent now expects an interface before the annotation class.

[Berdir]

Reviewed. Likely next steps:

1. Add the other hook implementations to plugin classes. Separate for now.
2. Add a method for batch_update_callback, possibly an optional separate interface as not all types might support this.
3. Then start to actually use this and kill pathauto.pathauto.inc.

[larowlan]

nitpick: missing blank line before }

[kimpepper]

later on could this go in a dialog?

Sure.

Reviewed.

Great. Are you ok to merge? This only adds new classes, and shouldn't be swapping out existing implementations (yet).

[Berdir]

Hm. Not sure about merging it like this already, or if we should continue a bit to see if it actually works. But i guess we can change it just as easily in later pull requests as we would here. Ok then ;)