Forum Replies Created

Viewing 4 replies - 1 through 4 (of 4 total)
  • The problem isn’t that WooCommerce is broken, so the solution above should only be a temporary one (and will be overwritten the next time that you update WooCommerce.)

    The problem is that wc_get_order_types() isn’t returning “shop_order” as a registered post type at the point this function is called. In my case, it was that a custom plugin was calling new WC_Order() in the “init” action.

    Post type registration happens during “init”, so there’s no guarantee that your plugin can create a new order object during that same action now that the post type is required to be registered in the above quoted code.

    I changed the action in which I was creating my order object to the “wp_loaded” action, which happens later than “init” (but not by very much.) This fixed the problem without modifying the WooCommerce code. Of course, I have the luxury of changing my own plugin, where the error coming from a plugin you paid for elsewhere requires going back to that developer.

    It’s unfortunate that this code acts in the “init” action, as it’s pretty common for developers to use “init” for lots of work that happens early in the WordPress loop. However, adapting and using “wp_loaded” isn’t the worst thing.

    The reason your original call did not return the terms was because there is an argument to the get_terms() function, ‘hide_empty’. Since your terms were not assigned to any posts (products), they were not returned.

    This would work:
    $terms = get_terms('product_cat', array('hide_empty' => false));

    That would be better than manually updating the counts first (which works because then they appear to not be empty.)

    I found your resolution when having the same problem and it made me realize what was going wrong, so hopefully this will help the next person finding this topic.

    Thread Starter AaronOverton

    (@aaronoverton)

    So I looked at what you said. I was actually looking for details about the donation, not the customer, in this case.

    What I’ve implemented is that I can use the “give_complete_purchase” action hook to add my functionality:

    add_action('give_complete_purchase', array($this,'postDonationToImis'));

    (For the benefit of other readers, the reason the callback function is in an array is that I’m using the object-oriented plugin methodology. It provides a way to better contain your code and is far less likely to induce conflicts between plugins. Learn it, love it, use it!)

    That action callback receives the donation ID as an argument. I ended up needing detail about the donation, like the total donated. I can use get_post($donationId) to get the donation custom post type, but what I needed for the total was in the post meta. So I ended up with a function like this:

    function postDonationToImis($donationId) {
      $total = get_post_meta($donationId, '_give_payment_total', true);
      // Do stuff with ID and total
    }

    “_give_payment_total” was the metadata I wanted, true indicated I wanted a single value rather than an array of values. There’s other metadata in there, if you need it.

    Maybe you have a wrapper class similar to Give_DB_Customers that abstracts this access? If so, it would be good to reply to this post with that detail. The above works, though.

    So, the short answer is “no.”

Viewing 4 replies - 1 through 4 (of 4 total)