Incorrect headers and missing data when exporting custom data

[awjrichards]

This issue is essentially the same as this:
http://forum.civicrm.org/index.php/topic,11217.msg57790.html
They never found a solution and I figured since it was so old I ought to start a new topic.

When I export contacts or contributions with custom fields, it occasionally works as expected (it seems like it depends on the custom field).  With certain custom fields, it displays the header as 'custom_<id>' rather than the field name (eg 'custom_45' rather than 'contributor_comment').  When this happens, NONE of the custom data for that particular custom field makes it into the column.  Unlike the poster from the original topic, I am not seeing any errors or warnings generated (I have debug on and am logging to Drupal's watchdog). 

I am using Civi 3.1.6.

Anybody have any ideas what might be causing this?

[Dave Greenberg]

I was a bit surprised that there was no resolution to the previous post given that it was evidently recreatable. So I did a search in the Issue Tracker and found that it was reported as an issue and marked Fixed for 3.1.5:

http://issues.civicrm.org/jira/browse/CRM-6161

So my first guess was that the same / similar bug is still present for Contributions (and Contacts?). I checked out the "diff" for that issue which u can see at:
http://fisheye2.atlassian.com/viewrep/CiviCRM/branches/v3.1/CRM/Member/BAO/Membership.php?r1=26284&r2=27348

One line was added to the exportableFields method in Membership/BAO/Membership.php:

Code: [Select]

        //CRM-6161 fix for customdata export
        $fields = array_merge($fields, CRM_Core_BAO_CustomField::getFieldsForImport('Membership'));

So then I checked for similar code in Contribute/BAO/Contribution.php exportableFields (and in Contact/BAO/Contact.php). Both classes seemed to be already handling this (the good and bad news).

So two options:
1. See if you can follow the code / add some debug statements from exportableFields and figure out where things are breaking down.
2. See if you can find a pattern to recreate this reliably on the 3.2 demo so we can track it down.

[awjrichards]

I just noticed that this was happening on our live site but NOT on our dev site (same code, nearly identical data set).  On a whim, I used the CiviCRM drush script to clear the cache on the live site - voila!  The problem disappeared.

So, I'm keeping my fingers crossed that this has gone away...

Thanks for the reply David!