plugin sort order dependencies

[apiuser]

Feature request from airbone42, posted on GitHub Dec 22, 2014

Hi,

I'm currently playing around with the plugin interceptors. Currently the only way to handle the order of plugins is by the sortOrder attribute. Unfortunately that's very lmiited as it only accepts a hardcoded integer value. Especially if you have dependencies between different modules it's very risky to use these, as if some other module changes it's sort order your extension might break.

Would Magento be interested in a solution where you could define a before or after attribute (similar to the layout blocks) to define if a plugin should be run before or after any other specific plugin? For me that would be a great solution to also handle bigger dependency chains and it's less likely to break if when the amount of plugins is growing. What drawbacks can you see in this solution?

[apiuser]

Comment from airbone42, posted on GitHub Dec 23, 2014

Good point, I thought more about backwards compatibility, but that's non-sense in a system which is in that early stage and when changing the syntax. Thank god it's friday

I would anyway encapsulare the before and after elements in some kind of sortOrder-parent (without a value) to be more flexible when other child types will be added. But that's more a personal preference and has no real technical reason.

[apiuser]

Comment from airbone42, posted on GitHub Jan 25, 2015

So as an alternative: It's possible to have plugins of plugins, so everyone can also execute something before, after or around another plugin. Just looks weird to have method names like beforeAfterFilter.

The question is: Is this the best practice? Shouldn't we remove in this case the sortOrder attribute at all to force one way of solve these conflicts? The hardcoded integer sortOrder solution is quite instable if you work with 3rd party extensions you have no influence to.

[apiuser]

Comment from CodeMonkey90, posted on GitHub Jan 26, 2015

@antonkril Have you decided whether you'll implement this proposal yet? I think this is an important change that should rather be made sooner than later (esp. since some people have already started porting their modules to Magento 2).

[apiuser]

Comment from vpelipenko, posted on GitHub Jan 29, 2015

Internal ticket: MAGETWO-32336

[apiuser]

Comment from alankent, posted on GitHub Jan 30, 2015

As we get closer to M2 end of dev beta we want to stabilize things. Until then it is a question of priorities. What is not clear is how often plugins will be on same method, and how often the ordering in such cases matters. This would then influence priority of such work over other work. Its not a question of "is this a good idea", but rather "is this more important than what it would replace on the backlog". (If the community does it, then that overhead is lower - it is more "is it the right solution").

So "what are our plans here"? There is not a single answer yet, but personally my question is how big an issue is this. How often is it going to be used? I would like to understand if the before/after is really going to fix the problem. Does it matter for plugin 1 to be before or after plugin 2? (Is it a problem in 1.X with event observers?) If not, it may be we just make sort order optional and discourage its use by extension developers. Leave it for a system integrator / developer to resolve conflicts in the rare case it matters.

I personally think before/after makes more sense as it talks about specific combinations, implying the developers talked together and worked out between them which was important to come first or last. I would love to hear some examples of why it is important as I think that would help verify the technical solution proposed. (E.g. if its for two extension developers to work out the ordering between them, great. If that would not happen, then it seems conceptually nicer but not that important in practice?)

The negative I can see is if extension developer 1 says "I should be first" and extension 2 says the same thing, then how to resolve that difference?

[apiuser]

Comment from CodeMonkey90, posted on GitHub Jan 31, 2015

Personally, I've had to solve rewrite conflicts in Magento 1 quite a few times. Since M2’s plugins are supposed to make rewrites unnecessary in many cases, there will most likely be multiple plugins on the same methods.

Does it matter for plugin 1 to be before or after plugin 2?

In some cases, it does (multiple plugins which affect the price calculation / one module sets a product attribute that another module depends on / …).

If not, it may be we just make sort order optional and discourage its use by extension developers. Leave it for a system integrator / developer to resolve conflicts in the rare case it matters.

I think you should do at least that before M2 is released (deprecate the sort order and provide some way to order plugins manually if a conflict arises). I suspect that in many cases the shop owner/developer will have to solve those conflicts manually anyway. One question, though: How are developers supposed to fix the ordering if no mechanism like the one outlined above is introduced?

The negative I can see is if extension developer 1 says "I should be first" and extension 2 says the same thing, then how to resolve that difference?

If that happens, the extensions are obviously not compatible and should not be used together. As I suggested above, M2 should treat that like an unresolved dependency and die with an appropriate error message.

[apiuser]

Comment from wsagen, posted on GitHub Feb 04, 2015

Actual rewrite conflicts can be eliminated in Magento 1, currently, in most cases using events etc but this doesn't rule out logic conflicts.

These are extremely frequent especially in areas of common functionality e.g. product prices, product attributes, quote object and order objects. Offering a before or after field is great however it requires the extension developer to have some view of what is already running on a system.

The ideal scenario is to be able to manually configure the order of execution via the admin panel. Either sort order or before/after field would work in this case. In the same way as you can currently view extension conflicts with the widely available Extension Conflict tool, you could view dependency conflicts and resolve.

As an extension developer, I would actually prefer to go last than first

[apiuser]

Comment from joshuaswarren, posted on GitHub Oct 16, 2015

Now that a few M2 extensions have been released, I'm curious if anyone has seen a problem with this "in the wild", and if anyone has thought from an SI/developer point of view what you plan to do when you come across a site with a sort order conflict/issue like this? Obviously we could edit the sort order in the extension's XML file, but that means at every future extension update we have to re-apply our change which is less than ideal.