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
Comment | File | Size | Author |
---|---|---|---|
#1 | 1101042-1-update_sf_retrieve_function.patch | 1.08 KB | rjacobs |
Comments
Comment #1
rjacobs CreditAttribution: rjacobs commentedAttached is a simple patch that changes 2 uses of of $sf->retrieve() with salesforce_api_retrieve().
Ryan
Comment #2
EvanDonovan CreditAttribution: EvanDonovan commentedI 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.
Comment #3
rjacobs CreditAttribution: rjacobs commentedCool, 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
Comment #4
EvanDonovan CreditAttribution: EvanDonovan commentedHmm...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.
Comment #5
longwaveThis works for me with the current -dev release of salesforce_api.
Comment #6
EvanDonovan CreditAttribution: EvanDonovan commentedOk, 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.
Comment #7
EvanDonovan CreditAttribution: EvanDonovan commentedFixed in -dev.