| Project: | Salesforce Suite |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (duplicate) |
Issue Summary
Josh K/Aaron/Bevan,
As you know, I was having no luck having this module connect to our SF sandbox instance at TreePeople (we need to test on Sandbox before launch). It turns out that PHP aggressively caches SOAP wsdl files. Since the module had initially connected to Production, it was using the old wsdl rather than the new sandbox enterprise.wsdl.xml that I placed in the salesforce_api/toolkit/soapclient folder.
The workaround is that I added the following cache-disabling code in line 13 of the salesforce_api.module (right before the "// Define directory paths for the Toolkit and WSDL files."):
ini_set("soap.wsdl_cache_enabled", "0");
Could you consider including this patch? Or recommend another place for this code, or a better workaround? I could patch manually, but was hoping the module could include some setting/feature for changing the connection between Production and Sandbox (I don't mind manually swapping out the wsdl). (Thanks to Sid from CraftySpace for helping with the code).
Renu
Comments
#1
#2
Hey Renu, I just now committed some documentation of this same issue from alex_b.
I'm reluctant to add code to disable the SOAP cache by default because in most (production) cases you *really* want this enabled. Having Drupal parse the whole .wsdl every time would kill performance.
However, we should look into some way to "clear the salesforce cache", since we will also need to clear our object definition cache along with the SOAP wsdl cache in these kinds of situations. I'm updating the title of this issue to reflect this.
#3
Or it could be a "no cache" thing with a nag (ala theme developer). We can make sure this doesn't happen by using the "cache_wsdl" option on the creator ala:
http://www.php.net/manual/en/soapclient.soapclient.php
#4
Josh,
Thanks for the explanation. Sounds like you've created a better feature-request as a solution. For my current testing and launch-readying purposes, utilizing my workaround as needed will actually work just fine (I'll re-activate the caching now that I reset the cache contents). I'll make sure to watch the release notes/this board/README.TXT just in case the feature-request gets implemented.
Renu
#5
rbora patches to add the 'clear cache' feature to salesforce' UI are very welcome!
#6
patched @ v.6--2
This patch adds a checkbox entitled "Disable PHP's SOAP WSDL cache" to the Salesforce API Settings fieldset on admin/settings/salesforce.
If the checkbox is checked, salesforce_api's hook_init will call
ini_set("soap.wsdl_cache_enabled", "0");and display a "nag" message to admins as long as this setting remains in effect.
#7
The WSDL cache seems to be stored in /tmp. I don't know if there is a safe/reasonable way to: 1) Figure out which wsdl file you'd need to delete and 2) have a user privileged enough to delete files from /tmp.
I imagine this is configurable on the server level, but clearing the php wsdl cache is likely outside of what this module can do, but others might have a different opinion on this.
#8
I'm not sure if there is a way that this could be case-specific to my setup, but I am noticing a strange issue that seems to be directly coordinated to whether or not I have this patch (#6) applied.
Essentially, a short time after applying the patch (not immediately) I inevitably receive a white-screen-of-death (site-wide) with an error:
Fatal error: Call to undefined function drupal_get_path()
Which further refers to salesforce/salesforce_api/salesforce_api.module - line 15
I know that this sounds very strange and totally unrelated to this patch (especially as drupal_get_path() is a core drupal function that has nothing to do with this patch), but I simply don't see this problem if this patch is not applied. If I remove the patch (patch -R) and disable/re-enable the salesforce modules the problem goes away, and stays away until I re-apply this patch (strangely, always about 1 hour after).
Searching some forums seems to reveal that that error (Fatal error: Call to undefined function drupal_get_path() ) is typically related to a caching problem, and furthermore to the use of hook_init (something about hook_init not being called on cached pages). I don't have caching enabled on my dev environment, but I do see that this patch does implement hook_init.
Does that make sense to anyone? I'm sorry that I can't explain more, all I can say is that this problem is directly coordinated to the application of this patch on my system... so I figured I should note something here.
Best,
Ryan
#9
This issue is superseded by #785264: Allow SF admins to upload new WSDL through the web, which clears the sets the ini variable, soap.wsdl_cache_enabled, removes all wsdl files from drupal's tmp directory, and flushes all caches (probably overkill). If all this is still insufficient, the README contains instructions for the user to add soap.wsdl_cache_enabled to settings.php
Pearlbear was on the right track (comment #7), and thanks to pcave for the patch.
Ryan:
If you are still having problems, please open a new support request issue.