-
Notifications
You must be signed in to change notification settings - Fork 16
Description
Hello,
I am currently looking at the feasability of integrating mollie in our application and thus the compatibility with our dependencies and saw that the plugin depends on sylius/admin-order-creation-plugin. It is not a problem and should not blocking in any way, however, we would most likely end up disabling this plugin as it would not integrate well with our application considering how many modifications we brought to the base Sylius.
Thus I wondered why would a payment plugin require a plugin that adds an order form in the back-office so I searched through the code base and it does not seem to be used much :
CustomerProviderInterface::provideNewCustomerwhich simply calls the customerFactory and sets the customer's email and could be reimplemented in the projectPaymentTokenProvider::getPaymentTokenwhich is a 10 line function and bothers me a bit more but it seems to be basic payum boilerplate codeCustomerRepositoryTraitbut its method is not used in the projectProductVariantRepositoryTraitbut its method isnot used in the project- Imports of the routes in the yaml config, it seems like none of the routes of the bundle are used by
mollie/syliushowever, so I suppose this could be left up to the dependent projects which want to use the plugin, if they do they add the configuration lines in their yaml files, else they ignore it - In tests, but it being made a
required-devdependency would fix the problem, I suppose it still makes sense to keep tests related to it to make sure it integrates well with the plugin
I'd be happy to discuss this furthermore and help implementing the changes, and sorry if I omitted something and it is not doable for some obvious reason. Otherwise the biggest issue I see is that it would probably be a breaking change for dependent libraries.