WooCommerce Integrations, which I’ll talk at length about a bit more in the moment, is a neat way to provide your custom set of options into the native WooCommerce platform.

But if you’re using namespaces, WooCommerce, WordPress, and more then it can get bit cumbersome when trying to make all of it work together.

Luckily, thanks to the nature of open source and people involved, we don’t have to operate by ourselves, and there’s plenty of people and resources available to help us get our questions answered and get our work done.

I’ll talk a bit more about these particular individuals later in the post, but first I want to cover WooCommerce integrations and how to make them work with namespaced code.

WooCommerce Integrations

If you’ve never worked with WooCommerce or worked specifically with WooCommerce Integrations, there’s a great example by Patrick Rauland in the documentation. And to be honest, I’m working on a project that includes integrations for the first time right now.

WooCommerce Integrations Example

First, think of WooCommerce Integrations as a way to easily, ahem, integrate your set of settings and options into the native WooCommerce user interface. You get a lot of stuff for free when you do this (like sanitization, validation, and more).

Secondly, this does come at a cost: If you’re not familiar with how to work with third-party classes or work through sample source code, then it can be a bit challenging. That’s why I recommend reading through the link above.

And if that’s not enough, then the WooCommerce Documentation isn’t bad if you’re good at reading through source code. It takes time, but it’s worth it.

WooCommerce Integrations: WooCommerce Classes

With all of that said, I did hit a snag in the project I’m on right now, and that comes with the nature of WoCommerce Integrations and WordPress namespaces. That is, I use namespaces in my code (and I’ve talked about this before).

Namespaces with WooCommerce and WordPress

But, in WordPress, namespaces aren’t often used. Everything is part of the global namespace. Usually, it’s easy enough to gain access to instances of these objects as you just provide the usual PHP methods for making sure you’re referencing via the global namespace.

WooCommerce Integrations, on the other hand, require a slightly different approach. That is, to get your work going, you’ve got to setup a filter that will add your custom integration to an array that WooCommerce manages:

If you’re using namespaces, though, it’s not as clear as some of the examples make it out to be. Instead, you have to make sure that you pass the class name with the fully qualified namespace as a string so the WC_Integration class can reach it during runtime.

This means:

  • You can use the use keyword,
  • You don’t try to extend your namespaced class while accessing the global parent class,
  • You don’t have to avoid using namespaces.

Instead, you set up the filter’s callback like this:

And that takes care of it.

Again With The Open Source

Earlier in the post, I mentioned that the code above was not the effort of my own. Sure, I love sharing information that I’ve learned, and I like sharing information that helps other developers, but the truth is that not everything we do is in a silo.

It rarely is.

And were it not from pointers from Pippin, Sternberg, and Carl, then this post wouldn’t have been written. The thing is, I’m not used to passing class names around as strings (blame it on PHP or my lack of experience with some of the nuances of PHP or both :). I’d rather work with, you know, instances of the classes. 🙂

But the point is that if you’re reading this, and it helps, tweet them and thank ’em for the help. The final point is that this is yet another example of open source in action. It’s people and examples like this that provide a solid reason to get involved in software, isn’t it?


Join the conversation! 4 Comments

  1. Hey Tom,

    Alternatively, if you’re able to use PHP 5.5+, you can use the ::class magic constant (http://php.net/manual/en/language.oop5.basic.php#language.oop5.basic.class.class).

    This allows you to import the class, and directly reference it, instead of using a string. The benefit is that you will immediately get a compile-time error, instead of eventually reaching a runtime error later during the execution.

    Here’s how that would look:


    namespace Acme\Inc\Integration;

    class Acme_Integration_Bootstrap {

    public function init() {

    if ( class_exists( 'WC_Integration' ) ) {

    include_once 'class-acme-integration.php';

    array( $this, 'add_integration' )

    public function add_integration( $integrations ) {

    // Notice that you must provide the fully-qualified class name.
    $integrations[] = Acme_Integration::class;
    return $integrations;

    If the class is from a different namespace, you’ll need to import it first, though (with a use statement at the top).



    • This allows you to import the class, and directly reference it, instead of using a string.

      You had me at “instead of a string.” :)

      If the class is from a different namespace, you’ll need to import it first, though (with a use statement at the top).

      This is something I was actually talking with Pippin about, as well, though it seems that if a class is part of the global namespace, then using use following by the class name is generally a shortcut.

      That is, for anything extending a class a the global level (not necessarily Acme_Integration). I just mention that for the sake of having it captured here in the proverbial paper trail :).

      • Regarding the use statements at the top, as these are required for all stuff external to the current namespace, the side effect is that you have a neat list of external dependencies at the top of each file. You should at all times be aware of external dependencies either way, and namespaces & imports make this very explicit.

  2. It worked like a charme.

    Thanks for sharing!

Leave a Reply