workspaces for web application process
The aim of this article is to run through the procedure I have used to test the Salesforce module on Drupal 5.1, availing ourselves of the 5.x-1.x-dev version I have recently committed.
First of all you will need a Salesforce developer account (unless you are going to test on another valid Salesforce account). Follow the instructions outlined in this awebfactory Salesforce article.
Well, the first step was to set up a fresh Drupal 5.x (5.3) install.
Then, enabled core contact and profile modules (required by legacy salesforce module).
Then, copied 4.7 salesforce module into ./sites/all/modules, and edited salesforce.module and salesforce.install so that the function module_exist() became module_exists().
Then, enabled salesforce module. Install went ahead with the usual success messages (created tables, created profile fields).
Profile fields were created.
I have to make a decision on what to do about the salesforce module architecture.
On the one hand it uses the nusoap library (modified so as not to conflict with PHP 5 soap namespace), and a GPL based api written by Ryan Choi.
Well, because a client needs it.
AWebfactory (your humble servants) are currently developing a new site for helpargentina.org , based in Buenos Aires. They are using the CRM on the legacy site and hope to continue doing so with the new site, and to expand on the existing functionality also.
Steve McKenzie's Drupal Sandbox code which fathered the Drupal Salesforce module and comprised its initial import, was composed of an install and module file, as well as a sub-directory of includes.
So, I have created the Drupal Salesforce module on the basis of Steve McKenzie's important work in this regard.
This blog entry, and other coming after it, I can imagine, deal with my experience getting the module operational and following the announced roadmap (see module description).