Exportables and Features integration for Drupal Commerce

I'd have to dig through all the code, but I think 2 points.

1.) We don't want to be forced to use features module. Code committed to d.o would probably benefit from NOT using features if it's not absolutely necessary, and I think that some of the more 'polished' drupal commerce ecosystem modules will probably be interested in not having a features dependency.

2.) Furthermore, I know from talking with Randy he'd like to see this in 1.x, and I know from talking with you Ryan that the changes I would propose here are probably not 1.x material in your mind since I'd want to actually change certain hook from returning arrays to objects and other such similar "api" changes. I'm honestly not interested in that particular debate, 1.x/2.x I'll let you two hash that out, I'm just saying we can get these sorts of exportables if we just do a little schema work and a little hook work in probably quite a few cases with no new dependencies, no new modules, just dotting our i's and crossing our t's in regard to ctools compatibility. Also, in the one instance I cited in my code, we'd actually get to remove quite a few lines of code from drupal commerce. I suspect there are other such places that I've simply not had the chance to find yet.

In any event, whether we go direct features compatibility or ctools exportables, we still need to define what all those areas look like, and if that means we do features for commerce 1.x and ctools for commerce 2.x that's completely cool by me, but I think we definitely want to focus in on making the various components of commerce that SHOULD be exportable (and already are in some cases) EASILY exportable. Yes you can store a checkout pane in code, no it's not readily obvious how to do that if you're not willing to dig into the code a bit. We can solve that, and that's really all I'm proposing here.

Actually digging through the code today:

hook_commerce_currency_info()

I know Ryan and I have discussed this one before. I assume a need for new currencies exists as the world changes and this seems pretty straight forward in that regard. The only thing that I'm giving weird glances is the numeric_code since I'm unsure what the canonical source for such a thing would be. Moving to export on this would give us the ability to easily provide a UI for generating new currencies if necessary. Again totally unsure about the numeric_code though so that's something to discuss at least.

hook_commerce_order_state_info()
hook_commerce_order_status_info()

Both look uncomplicated and straight forward.

hook_commerce_line_item_summary_link_info()

Not 100% sure what I'm looking at here, and with its need for access controls it may require something a bit more extensive than just simple exportables integration.

hook_commerce_order_state_info()

Again this looks pretty straight forward from the core implementations I'm seeing.

hook_commerce_order_status_info()

Commerce Checkout's version of this looks significantly less straight forward than Commerce Order's. Commerce order leads me to believe this would be relatively simple to do, commerce checkout leads me to believe that work done to hook_commerce_checkout_page_info() would translate over to this info hook which might mean this isn't a good candidate for exportability. Still not clear from reading the code.

hook_commerce_customer_profile_type_info()

Unsure about the ramifications on this one. It doesn't look problematic, from the use case that's in core though. However it does appear to be another way to generate checkout panes.

hook_commerce_line_item_type_info()

Looks like it's the commerce_line_item's version of bundle handling. I've been wanting to do essentially this with nodes for a while to prove it will work, I think this is a potentially awesome win from an exportables perspective if we can get it working. I don't actually know of any reason it shouldn't work, and it would probably translate over to product types rather easily in a 2.x implementation and give us a good foundation for doing exportable product types.

hook_commerce_checkout_pane_info()

I've basically done this one already in the code I mentioned in the initial post, however after further review, I think that checkout_panes are probably a much better candidate for a ctools plugin architecture based on what all I'm seeing that they do and how they're implemented. I'd love to actually dive into this one a bit more. Plugin doesn't mean that there isn't some sort of exportable plugin wrapper around some element of it. A single plugin can actually represent MANY implementations simultaneously through some pretty awesome voodoo built into the plugin system, which makes writing a single plugin that handles 'exportables' of a like type of content_pane rather straight forward. I think this could be a superb use case for things like the commerce_fieldgroup_panes module.

hook_commerce_checkout_page_info()

Appears to be fueling the checkout wizard. If we're going to make panes a plugin and/or exportable, this seems another big win from an exportables/plugins perspective. I'd need to dig in further to figure out exactly which it should be, but if a page is just a holder for panes (i.e. no custom elements that aren't defined as panes) then it can probably just be exportable.

hook_commerce_payment_totals_row_info()

Due to the amount of logic I'm seeing in the implementations of this hook, it's probably not exportable. Should either stay as it is, or become a plugin. There is only one implementation to look at though so I can't say I'm getting a real deep look at what the hook can do beyond this single case.

hook_commerce_payment_method_info()

Guessing based on context that payment_methods are probably best represented by a plugin.

hook_commerce_payment_transaction_status_info()

Take it or leave it, this seems very DX to me.

hook_commerce_price_component_type_info()

Guessing that if this maps to anything in ctools it's also a plugin.

hook_commerce_product_type_info()

Exactly what I was talking about earlier. I think this is a prime target for exportables.

hook_commerce_tax_type_info()
hook_commerce_tax_rate_info()

Seem fairly straight forward at first glance, probably good candidates.

We could certainly play with it in a contrib module, but we'd end up doing a LOT of schema alter work to make that happen, and I think that planning with exportables in mind in a 2.x branch might push us to reorganize the schema just a little (schema is often in the _ui module and ctools exportables sort of expects ui modules to actually be ui, not ui + schema... we could debate whether that's a good or bad thing, I'm simply stating what "is").

Ryan, ok that sounds good. I just wanted this issue to exist as a place we can discuss and plan for 2.x in this regard.

Yes 'ctools exportables' should be descriptive enough. Your question is a little difficult to answer. I can see ctools integration being a wide enough topic to cover a few issues depending on what all we decide to use, however the boundary between plugins and exports gets foggy in a situation like this one.

Something is "exportable" by virtue of the fact that we added a few lines to the appropriate schema, and thought through the schema so that it matches what we need (which should probably be the next task in relation to these hooks). However, sometimes we end up with things like content_panes which in and of themselves are probably better as plugins... this can become confusing since a single plugin can provide multiple options by wrapping exportable items. That being said, from an 'identification' stand point, I think this can all reside in a single issue, but breaking it up into tasks we might want to treat it very differently.

Continuing on this topic, exportables can be given a UI from ctools by implementing an export_ui plugin. This is very useful as it builds all the import/export/revert/clone/etc features for us, however this is technically unnecessary and we CAN roll our own. I wouldn't suggest it though. Export_ui plugins are pretty easy to write for most things.

Entity API is something I've not worked with extensively. Does the 'export' export individual entities (say product x and y). If so, I personally have no desire to try to replace such a tool. If (on the other hand) it's exporting bundle information or information about the entity definition itself, then I'd be much more interested in putting something ctools related there, though I'm certainly not sold on that either direction.

@pcambra

Yes what Ryan said, I am certainly in no place to mandate, I'm just trying to illustrate the possibilities and their implications.