Add API for Coupon Meta

[JustinSainton]

Lots of potential coupon meta, but the initial use case in my mind is descriptions. Knowing the exact purpose of a coupon with a short description can provide incredibly helpful context when running reporting on coupon usage.

[benhuson]

I guess you would propose storing this in the existing WPSC meta table - same as country regions, product category meta etc?

If we were to move Coupons to a post type at any post, if we have a robust API I guess migrating meta data as well should;t be too tricky. Not sure wether the plan was to do that at some point?

[JeffPyeBrook]

@benhuson a custom private post type would be really nice to work with. Defining the well known attributes saved as meta on the post would provide a clean interface for third parties that want to do interesting things with coupons.

Also don't discount the value of using a custom post type vis-a-vis getting import and export capabilities for free. It would be really nice to be able to move coupons between sites for all of the obvious reasons.

Also, going with a post type, and associating the product categories, product tags and other product taxonomies give some really powerful conditions.

Last but not least, it will perform well.

[JustinSainton]

@benhuson @JeffPyeBrook Awhile back, I had been really into the idea of coupons as a custom post type.

And then I started working with daily deals sites that created anywhere from 10K - 100K unique coupons...for every deal they ran...and the idea of that being in the post table sort of terrifies me now.

That said, I think having a robust API to work with (for all the reasons states - taxonomies, meta, import/export, etc.) will be great. I'm just no longer convinced that custom post types are the right way to go.

[JeffPyeBrook]

100K posts in a posts table isn't a real big deal, WordPress can handle it well if the design of the custom post type is considerate of the implementation under the hood.

You are correct to be concerned if the implementation isn't done with performance in mind. WPEC already can have performance issues with large product catalogs because it is using parent-child posts for product variations. I have one site where each of 1200 different products can have more than 600 variations each, it didn't do well with WPEC variations.

If we need to support 100K or more active coupons I am not sure I would implement each coupon code as a distinct custom post. The post would encapsulate the rules and attributes of the coupon. There are probably many ways we could store the code associated with a coupon. The admin list table with 100K+ records feels a little tough to use.

If we did do it that where a one coupon code is equal to one post, i am pretty sure it would work because the WordPress post management caching is pretty well tuned.

[JustinSainton]

Indeed, there are too few qualifiers in your comments for me to think it's a good approach.

However, with a properly abstracted data layer, there's no reason someone couldn't swap out the underlying data store. I just don't think it's the best approach for us today. If we were having a discussion about whether or not to add a new table for coupons or to just use CPTs - I might be a bit more swayed to avoid adding a new table.

We already have a generic meta table. We already have a coupons table. We already have a very decent start on a Coupons API that uses object caching. So for those reasons, I feel like we wouldn't actually gain that much migrating things over to CPTs.

[benhuson]

I agree with @JustinSainton

If we were build afresh, I'd probably go with CPT, but as we are where we are probably best to put a robust API in place then there are possibilities for changing data store in future.

Having said that, import and taxonomies out-of-the-box would have been nice 😞