Hey there,

This was totally puzzling to me at first. I just started testing the newest dev versions of the salesforce_api and uc_salesforce and suddenly noticed that browsing to the "salesforce" tab of any ubercart order was now resulting in a white screen of death. Upon consulting the error log I noticed:

PHP Fatal error: Call to undefined method stdClass::retrieve()

Upon checking uc_sf_order.module I see the line (around 530):

$data = $sf->retrieve(array($order->salesforce->sfid), $order->salesforce->name);

which seems to be where the error is sourced from. What is so strange about this is that I am certain that I was able to open an order's "salesforce" tab in the past, while using the same uc_sf_order.module code. Even looking back at very old revisions of uc_sf_order.module (which I know have not shown this problem) I see this same $data = $sf->retrieve[...] line.

Anyway, I searched around the api code for similar "retrieve" patterns/functions and noticed that instead of $sf->retrieve(), salesforce_api_retrieve() seems to be used as a wrapper that eventually calls$sf->client->retrieve(). So my guess is that the above line should be:

$data = salesforce_api_retrieve(array($order->salesforce->sfid), $order->salesforce->name);

Upon making this change, things seem to work again.

So I'm guessing that something about the API changed recently which broke things. Perhaps there is some clue at #1046692: [refactoring] Get rid of salesforce.class.inc? I'm guessing that any use of $sf->retrieve() should be replaced with salesforce_api_retrieve().

Ryan

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

rjacobs’s picture

Status: Active » Needs review
FileSize
1.08 KB

Attached is a simple patch that changes 2 uses of of $sf->retrieve() with salesforce_api_retrieve().

Ryan

EvanDonovan’s picture

I think this might be backwards-compatibility breaking, since the salesforce_api module is in such flux still. I'll have to look into it more before committing.

Could always conditionally define the salesforce_api_retrieve function in uc_salesforce if it didn't already exist - if that was necessary. I'll let you know.

rjacobs’s picture

Cool, thanks.

Yeah, it's been quite an interesting process keeping up with all the ongoing changes to the Salesforce modules and the API. I've been getting really close to a place where I think I can "freeze" the code we are using (as it meets our case-specific needs) and then suddenly regression errors pop-up. Anyway, I guess it's a necessary battle as there have been some great enhancements coming out within the API dev version, and I'm also hoping to be on-board (and up-to-date) once there is a formal upgrade path available.

Ryan

EvanDonovan’s picture

Hmm...yea, I haven't been upgrading my salesforce_api.module in my development, once I start on a project. It's too much of a moving target to chase. I'm still using a version from December on cityvision.edu.

longwave’s picture

Status: Needs review » Reviewed & tested by the community

This works for me with the current -dev release of salesforce_api.

EvanDonovan’s picture

Ok, I found the commit on Salesforce Suite that pertains to this: http://drupalcode.org/project/salesforce.git/commitdiff/6cc8d07ffd9f2e37....

Looks like this change would break backwards compatibility since the Salesforce API changed. I'd have to create a wrapper function for salesforce_api_retrieve if it doesn't exist if I wanted to maintain backwards compatibility.

But I don't think that's worth it, so I'll just commit this as is.

EvanDonovan’s picture

Status: Reviewed & tested by the community » Fixed

Fixed in -dev.

Status: Fixed » Closed (fixed)

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