4

I am building a plugin that uses Stripe for the payment processing. I have included Stripe's PHP library into my plugin and everything works great. But what if someone else makes a plugin that also uses Stripe ... or worse, an older version of Stripe that isn't compatible with mine? Sounds like there could be conflicts if someone had both of our plugins activated at the same time.

Do I need to namespace Stripe's classes? Is that advisable? I imagine that being a maintenance nightmare if I ever want to upgrade to a newer version of Stripe's library.

I'm totally OK doing that, but I want to make sure I'm following best practices here.

Thanks! Tony

2

I went ahead and namespaced Stripe. Everything worked just great. And now I don't have to worry about any one else's Stripe library messing up my stuff.

Original:

namespace Stripe;

New:

namespace MyRadNamespace\Stripe;

If anyone is interested in seeing how it's done, feel free to browse my repo:

https://github.com/Spokane-Wordpress-Development/Freezy-Stripe

Cheers!

0

As I looked through the link to the repo attached in the answer, I noticed the incredible amount of requice statements in a single file. The main problem is that the repo is missing a autoloader that can be optimized project wide and as well as that the plugin includes all those files no matter if needed or not.

When you start using Composer to manage attachments, you will find that it creates an autoload.php file for every single package that you write (or fetch). You can then create complete projects using Composer as package manager, which, as a nice side effect, also creates a centralized autoload.php file instead of one autoloader per included package (plugin/theme/etc). On top of this single autoloader, Composer also builds a "Class > File" map as "cache" to avoid as many disk reads as possible, which will keep class lookups as fast as possible.

This will avoid having to namespace vendor namespaced classes. Meaning that in case multiple packages have a composer.json file, there will be only one location where those vendor packages will get saved (therefore saving bandwidth and disk space) and fetched from. Even if one did not ignore vendor files in a VCS controlled package, there is no need to load them anymore.

# Before in Package (A)
$stripe = new \MyRadNamespace\Stripe;
# Before in Package (B)
$stripe = new \MyFunkyNamespace\Stripe;

# After – anywhere!
$stripe = new \Stripe;

In case a plugin or theme does not support Composer yet, you can simply fetch it via the WPackagist proxy/mirror service.

To get a quick start with the Composer package manager, I suggest using wecodemore/wpstarter by @gmazzap – docs here.

  • This is a Wordpress plugin. And unfortunately they don't support composer. I use composer for everything else. But for Wordpress, it's not an option. – Tony DeStefano Mar 6 '16 at 15:51
  • @TonyDeStefano See the update about packages not supporting it and WPStarter to bootstrap your projects. – kaiser Mar 6 '16 at 16:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.