Problem/Motivation

The uc_product_classes features export code does not export the field definitions as if the product classes were simply content types.

Proposed resolution

Fix this.

Remaining tasks

Review, write tests.

User interface changes

None.

API changes

None.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

solotandem’s picture

Status: Active » Needs review
FileSize
2.34 KB

The attached patch provides the features integration.

I will commit if someone will review and mark as RTBC.

longwave’s picture

Can't we just reuse the 'node' pipe for this? There is already a comment to this effect, and I was fairly sure I tested this when I first implemented this feature:

  // Create a pipe for the CCK fields and variables to be exported.
  $pipe = array('node' => $data);
solotandem’s picture

The existing code did absolutely nothing when I tried it. The patch enables the export of the product classes (essentially content types) and the attached fields as you would expect.

longwave’s picture

This is actually a regression in Features; the existing code works with Features 6.x-1.1 but not 6.x-1.2.

longwave’s picture

git bisected to this commit: http://drupalcode.org/project/features.git/commitdiff/bba147a

Reverting this Features patch makes the 'node' pipe work again: #904558: Multiple features and strongarm conflicts

But perhaps we will just have to copy this code from features.node.inc into Ubercart now?

longwave’s picture

Perhaps instead of "Ubercart product classes" being a separate exportable type, we should just automatically include Ubercart class data if the user exports a node type that is a product class?

solotandem’s picture

Regarding #6, I don't believe the product classes are selectable as a node type. Since Ubercart controls these "node types" they are not handled by the standard content type code. That is why this patch is needed. Interesting it is a regression in Features.

longwave’s picture

Invoking the pipe function directly seems to fix this in 6.x-1.2.

solotandem’s picture

I have not tested the patch, but the function call should not have the "&" on the second parameter, $export.

longwave’s picture

Version: 6.x-2.x-dev » 7.x-3.x-dev
Assigned: solotandem » Unassigned
Status: Needs review » Patch (to be ported)

Committed #8 without the & and with additional comments to explain why this has changed. Perhaps needs porting to 7.x for the same reasons, marking as such until someone tests it.

longwave’s picture

Status: Patch (to be ported) » Fixed

Same fix was needed in 7.x, committed.

Status: Fixed » Closed (fixed)

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