drealty_listing field definitions are being exported/imported in both the connection controller and the listing type controller. If one were to build a feature with the drealty_listing type exported and a connection you would have three separate definitions of the fields on the entity.

The listing entity export, as opposed to connection export, has been working fine through features. With the Features 2.x improvements in field export, I can't see any reason not to leave field export to Features.

The attached patch removes field import/export from DrealtyListingTypeController and drealtyConnectionEntityContoller.

The export/save methods were simply removed from DrealtyListingTypeController since a) the export of basic entity properties was removing important fields and b) everything else in those two methods had to do with fields.

A tangential effect of letting EntityAPIControllerExportable handle export is that this issue: https://drupal.org/node/2097507 is resolved.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

alexweber’s picture

Status: Active » Needs review

Is this gonna require any kind of upgrade path?

thebravecowboy’s picture

The current exports end up just ignoring each other's field definitions. Whichever fires first gets respected and the others are ignored. This is basically just a cleanup thing to allow the field api to do its work and not clog up features/exports with extra field definitions that are unneeded.

The one reason to leave this in would be to allow full export without Features installed. This patch assumes you're going to exporting your drealty_listing types using a Feature.

shauntyndall’s picture

geekygnr’s picture

The patch didn't work on the latest dev version so I re-made it.

It seemed to have solved a lot of issues with creating a feature.

geekygnr’s picture

Re rolled the patch to work with 3.0