Implemented multi-currency features (now with full support of per-currency pricing)

[daigo75]

As per subject, I added initial support for multi-currency features. At this stage, the Product Fees plugin allows to enter one fee in base currency, and its amount will be converted automatically to the active currency when the product is added to the cart.

Summary of changes

• Added helper class. The class has been adapted from our code examples, and I added a prefix to prevent clashes with other plugins.
• Added call to convert product fee to the active currency before applying it to the cart.

[daigo75]

Update

I updated the code to implement full support for multiple currencies. The modifications maintain full backward compatibility (an uncommon feature in WooCommerce plugins) with single currency environments.

Summary of changes

• Added support for one product fee per currency.
• Updated Admin interface to allow entering product fees in each currency.
• Optimised helper class (minor optimisation, to avoid calling get_option() unnecessarily.

[WPprodigy]

In efforts to keep this a MVP, I think it would be best to keep this outside of the core. I added extensibility to the plugin with https://github.com/WPprodigy/WooCommerce-Product-Fees/commit/05bd0d5579458b819a79633c26fccb3f19c6684b, and tested it with this plugin: https://gist.github.com/WPprodigy/34a45dc2686e1f9b4ba8

I believe I covered all areas that this PR needs to hook into, and it shouldn't be much work to transfer everything over to it's own function with a hook. I'd be happy to help if you would like, but I didn't have the currency switcher plugin to test against - tis the world's most useless plugin on exhibit in that gist ;)

[daigo75]

If you wish to extract all the multi-currency features to a separate add-on, and you have an idea about how to write it, you can give it a go, but I would strongly recommend not to do that.

The changes have to be part of the core of a plugin, for several reasons:

• Multi-currency environments are getting more common by the day. Sticking to the idea that WooCommerce is "single currency by design" is a mistake. Having support for multiple currencies out the box is indeed part of an MVP solution.
• 3rd party plugins should not be extended "from the outside". As you have seen, the changes require modifying the user interface provided by the plugin, saving data, retrieving it, and it's something that the plugin itself must do.
• Each 3rd party plugin (such as this one) can change at any time, and only the original developer knows what changed and when. The best person to make the plugin multi-currency aware and maintain such features is its original developer (our contribution simply shows how easy is to do that).
• Having to install yet one more "bridge" plugin for each 3rd party plugin to "inject" multi-currency features is something that customers do not want to do. Having to do that would effectively mean doubling the amount of installed plugins, and highly increase maintenance the the risk of having issues if the original 3rd party plugin changes.

All the above is based on extensive experience acquired with our collaborators and 3rd party developers. The best way to have multi-currency features is to designed the plugin to be multi-currency from the beginning. It's very easy to do so, as the pull request showed. The changes maintain 100% compatibility with single currency environments, therefore there is no risk of issues from that perspective. :)

[WPprodigy]

I do agree that multi-currency support is a growing market, but I'm not sure it would be a necessity for 80% of the user base: https://dzone.com/articles/applying-8020-rule-software

As for the bullets:

1. Per the above, I'm not sure it fits into MVP at the moment.
2. I'm not sure I agree with this. Core plugins should make themselves extensible, and third party plugins should do the extending. Adding fields and saving them can be done quite simply still: https://gist.github.com/WPprodigy/34a45dc2686e1f9b4ba8#file-example-product-fees-prefix-php-L15-L34
3. When the plugin is extended externally, the changes are geared for a specific reason. As long as the plugin keeps the hooks/filters functioning in the same way, everything runs smoothly as the third-party dev has full control of his extensions.
4. I do agree with this 100%. Plugins get a bad wrap and people don't want to install two plugins if they can do one instead. However, what it all comes down to is code, and a plugin is essentially the same weight on a website as a little bit of code in the theme's functions.php file. However, the risk of changes does not stand because of the above point.

[daigo75]

I don't want to sound snotty, but I know the 80/20 principle, I've been developing software for 20 years now. :)

What you write makes sense in most cases, but this one is an exception: our multi-currency solution is not "just a simple plugin". It extends WooCommerce core functions, and it's technically "closer" to WooCommerce than other plugins. Support for multiple currencies has to be considered part of the ecommerce core, and treated as such.

To make an example using a crude diagram, the interaction between our multi-currency solution and external plugins cannot be this:

WooCommerce core <-- 3rd party plugins <-- Multi currency solution

It has to be this:

[WooCommerce + Multi-currency solution core] <-- 3rd party plugins

In terms of integration, our solution's purpose is not to make other plugins multi-currency aware, by altering them from the outside, but to make it possible for other plugins to become multi-currency aware.

As for your #3, I have enough experience to tell you that many plugins rarely maintain filters and functions consistent, as the software lifecycle of most plugins is often irregular and inconsistent. Even in WooCommerce itself, breaking changes are quite common. Maintaining an external plugin would mean chasing all those changes and jumping through hoops to make the integration work with different versions of the 3rd party plugin (some customers may have an old version, and they may want to keep it).

On the other hand, we guarantee that our software contract will be consistent, and there won't be breaking changes unless a significant change in WooCommerce core requires them. Our solutions are never a "moving target", to be clear. :smile: Once implemented, the multi-currency features have zero maintenance (apart from when the external plugin changes, of course).

In short, the cost of writing and maintaining external integrations between a multi-currency core and external plugins is huge, and that's the reason why recommend not to use that approach. For the same reason, we do not write, nor maintain such kind of integrations. Our plan is not to extend 3rd parties' plugins, but to help 3rd parties extending their own plugins (like I did in your case).

[daigo75]

@WPprodigy Following a recent discussion with some clients and developers, I thought of writing this note to point out that my last explanation is still valid, and it applies to any plugin that has to become multi-currency aware (that's a conclusion based on solid facts, not a personal opinion).

To summarise, the question to answer is "does plugin X work with a multi-currency core?" If the answer is "no", then the plugin imust be updated, like I did in this pull request. The multi-currency layer won't "magically" inject multi-currency features in other plugins, and external integrations are sub-optimal (although, if the plugin author decides to write them, that could also be a temporary solution).