Plugin conflicts with Mollie API

[TeoWin]

Hi,

I have an issue with the Mollie/Woocommerce plugin: The Mollie WooCommerce plugin does not test if the class is allready registered by another plugin. Therefore other instances or other versions of plugins that use the Mollie API use the files and directories of this plugin.

[davdebcom]

It's not just enough to check if the class is already being loaded by another plugin. The other plugin could be using an older version of the mollie-api-php. For example, the WooCommerce plugin is not on the latest version (with support of gift cards) and other plugins are not, if another plugin is loaded first and uses it's version of mollie-api-php, the WooCommerce plugin will run into issues as the gift card classes are missing.

I'll do some research and see what is the best solution. Namespacing comes to mind.

Possible idea: https://stackoverflow.com/a/6143552

[willemstuursma]

There's no real solution for this @davdebcom, except to use a dependency manager such as composer.

@TeoWin what is your use case for having multiple Mollie API clients in your installation?

[TeoWin]

IMHO there are simple checks available like the check for existance of a class, which means there is another plugin using the same class.

Mollie does not check if another plugin uses the API and registered classes.

I ran into this situation multiple times. One simple use case is Woocommerce with the Mollie payment option and Formidable Pro contact form with my Mollie for Formidable Pro plugin. (customer sells books with Woocommerce and consults with Formidable Pro contact form).

I have seen the same issue with a shop and donations for charity.

[davdebcom]

@willemstuursma

• Won't name spacing Mollie API PHP do the trick?
• Use case: multiple plugins that use Mollie, like WooCommerce and Mollie Payments, plus Paytium or Mollie Donate (by Nick).

@TeoWin Checking for the class won't be enough, I'm afraid. Plugins might use different versions of the API, with or without support for a new payment method etc. This was the case a few months back.

[TeoWin]

I wonder if it would work to make the API a separate plugin, accessable from all plugins that need the Mollie client class.

What I see is that different plugins that use Mollie have the API in different directories below the plugin source. That is the main source of the conflict I described.

If there would be a technique that registeres the class centrally, the Mollie API files all would be in the same folder. One client object/one class for everyone. Also preventing the issue with different client versions.

And it would not hurt if Mollie would have a mailing list announcing updates.

Or is this too simple? I use the same approach for my plugin that is partly integrated in another plugin, partly stand alone. And partly integrated in a webshop. For the same purpose: the reservation part can send an invoice, the webshop can send an invoice and the website owner can create invoices manually. All using the same number range. Works fine. May be also useable for Mollie.

Pronamic seems to follow the same approach too.

[willemstuursma]

I wouldn't want all of our merchants to go through the hassle of installing two plugins to get this working. We would still have the version issues.

It's a pretty specific case. If there are more reports of this problem, we can look into it.

[TeoWin]

It is kind of common practise to install the plugins that you depend on during installation.

I don't get the issues about versions: there would be only one version of the Mollie API present on the installation.

I have seen several conflicts: Donation with Mollie conflicts with my plugin (rare combination, I agree), Your Woocommerce plugin conflicts with both mine and the donation plugin.

If you install multiple Mollie related plugins besides eachother to find which one is best for you, you're in trouble.

The only way to get something working is to do it like the guys who skip the entire Mollie API and use CURL.

I have refunded money because of this conflict. It seems that the choise to use Mollie API is only good if you don't care about refunding.

Like I said: it is not strange to have a plugin that installs dependencies. It would have the big advantage that plugin authors don't have the hassle of keeping the Mollie version of their plugin up to date (nice in case of security leaks) but the plugin takes care of that.

The case is much less specific than you think. But the plugin which is not Mollie API dependant has a big market share. The problem only exists for plugin authors that use the Mollie API.

It looks like I have to fork the Mollie API, and rename the class to get this to work.

I am deeply dissapointed to learn that there is no more in this than raise shoulders and case closed.

[davdebcom]

I think this should no longer happen as we are now name-spacing the API client: https://github.com/mollie/mollie-api-php/commits/master

[TeoWin]

I am very glad to edit this twice and remove the largest part of my comment. :-)

From a short look around, I found posts from someone else with the same issue with a Stripe plugin. I got the impression that all is fine when every plugin developer would use another namespace in your API.

Could you include a test for the existense of a namespace/class name and a warning to rename it? I suppose not everyone is reading this thread.

But it looks like the case can be closed indeed.