Problem/Motivation

There are simple, off-the-shelf solutions like cer that work with entityreference, but don't work with product_reference. It's kind of backwards to require that these modules be hacked to use product_reference, instead of adopting/embracing entityreference more completely.

Proposed resolution

There's the attached patch which has the negative UX consequence of allowing the user to select add_to_cart_form as the field formatter for entityreference field instances that don't actually target product entities. The way around this would be to add a form_alter hook for field_ui_display_overview_form to inject a call that queries the field info API and asks if the entityreference field instance actually is targeting entities of type product and modifies the options accordingly.

Remaining tasks

If this is found to be a good idea, then what remains is to add the alter implementation to the patch. If not, then perhaps it would be good to push this up to core field module and ask for the option to supply a callable that determines if a formatter can be used, rather than hard-coding the entity names.

User interface changes

You would get to use entityreference as well as or instead of product_reference, at least as far as add_to_cart_form goes.

API changes

Anyone expecting the entity id field to be named 'product_id' would be SOL unless we make a point of supplying control flow to mask the difference, since entityreference calls this field 'target_id'.

Comments

rszrama’s picture

I'm not sure we really want to add this complexity to the 1.x branch, as it's really just a half-step toward the solution I'd actually like to see baked into Commerce 2.x - a full dependency on entityreference to replace all of our custom reference field types. I wasn't aware of cer, though, so thanks for the tip! That will be perfect for solving the bidirectional link between orders and their line items.

Do you mind me repurposing this issue and linking to it from #1467180: Open 2.x Drupal Commerce branch? My recommendation in the meantime would be a contrib module that adds entityreference support through the appropriate alter hooks.

wamilton’s picture

That's a quick and evenhanded response. Glad to see this is already being considered for 2.x, please repurpose as it suits you.

You will almost definitely want a core patch to the field module for dynamically allowing fields for formatters, though -- that's the only clean way to make sure that the entityreference field instance actually targets entities of type product before making the cart form formatter available.

amitaibu’s picture

I'd be happy to see this patch go in. The integration I'm writing for Zariz and commerce will need it. (Zariz alters the schema of the ER field and adds a UUID item to it -- which can't be done on the product reference).

amitaibu’s picture

Status: Active » Needs review

Correct status

bojanz’s picture

+1 on my side. This is a good as it can get in 7.x-1.x.

amitaibu’s picture

Status: Needs review » Reviewed & tested by the community
rszrama’s picture

Status: Reviewed & tested by the community » Fixed

Thanks guys. : )

I hope to put a 1.9 out soon... have a few patches pending review, but it shouldn't be long. Welcome to the committers log, Will.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

Status: Closed (fixed) » Needs work

The last submitted patch, entityreference_instead_of_product_reference.patch, failed testing.

rszrama’s picture

Status: Needs work » Closed (fixed)