Plugin Contributor
Zack Katz
(@katzwebdesign)
Yeah that makes sense; it’s not set up for the sandbox.
Plugin Contributor
Zack Katz
(@katzwebdesign)
I will consider adding a Sandbox mode in a future release. Thanks for bringing this up.
If we use it in full production mode is there any chance of data integrity issues? Can we corrupt the Salesforce database by a misplaced item?
Plugin Contributor
Zack Katz
(@katzwebdesign)
I don’t know; that’s a question for Salesforce. I’ll look into the Sandbox feature soon.
If you want to test against a demo environment, you can get a free Developer instance at http://developer.force.com. Developer instances work like production instances (but have pretty tight user and data limits), but would thus be accessible by this plug-in.
That said, it’s pretty tough to corrupt a Salesforce database. I mean, you can pour a lot of dirty data in there with forms and this add-on, and that could affect your reporting, and all that comes with poor data integrity, but you’re not going to “break” Salesforce by creating new records with forms and this add-on. As long as you’re not writing into record ID fields, you shouldn’t write over existing data either, just create new records.
Can the plugin files be changed to point to test.salesforce.com and then once the sandbox has been move to production, change it back to salesforce.com?
@zack – Can you put in the FAQ that the plugin does not currently support Sandbox environments?
@zack – Actually! Quick fix around line 668 in salesforce-api.php:
$wsdl_xml = apply_filters( 'gf_salesforce_partner_wsdl_xml', plugin_dir_path(__FILE__).'developerforce/include/partner.wsdl.xml' );
$conn->createconnection( $wsdl_xml );
With that filter in place, people can set their own wdsl, one that is specific to their own sandbox environment wsdl (ex. https://cs12.salesforce.com/soap/wsdl.jsp).
Are you willing to add this filter in the interim until you add support natively for sandbox?
