Pages

Tuesday, January 10, 2012

Thank You!

Its been a few days, but Happy New Year! 

As I get back to writing content for this blog in this new year, I want to make sure to thank everyone for their support of it. 

A big thank you to everyone, all the regular and casual visitors alike. A special thanks to John Mertic (@jmertic), SugarCRM Community Manager, for his continued support of my efforts, regularly syndicating my content and allowing me the opportunity to post on the SugarCRM Developer Blog as a guest.

My motivation for this blog has never been monetary gain, as the satisfaction from helping people is sufficient for my needs. And your comments, emails and continued visits are quite rewarding and am appreciative of all of them. 

Thanks to all of you, visits to this blog have nearly quadrupled on a month-to-month basis since last year. 

I think it is safe to assume its content is of help. That makes me happy. 

Thanks and best wishes for the new year!

Saturday, November 12, 2011

SugarCRM Tips: Wizard-Less Uploads


A few days ago an interesting topic came up on the SugarCRM Forums. 

In short, a user attempting to upgrade their SugarCRM instance ran into a problem in doing so. The problem was the result of a system limitation imposed by the hosting provider, which in turn affected the functionality of the SugarCRM Upgrade Wizard.

For those not familiar with this wizard, a step within it requires one to upload a zip file -- provided by SugarCRM -- containing the various files needed to complete the upgrade. In this particular case, the system limitation restricted the size of the file which one could upload to a size smaller than the zip file that needed to be uploaded. End result: the upgrade files could not be uploaded, and without completing this step, the upgrade cannot be completed.   

However, there is a way to get around this problem, assuming we have the ability to upload files to the server in question through other means, such as FTP or even the File Manager tool in cPanel

So how do we accomplish this in such a way that SugarCRM thinks the files were uploaded via the Upgrade Wizard? Let us take a look.

Tuesday, October 11, 2011

SugarCRM Logic Hooks: Unintended Loops


There is something intriguing about working with logic hooks. Through their use, one can accomplish quite a bit given that the only real limitation is our ability to write PHP code. 

For example, we can use a logic hook to modify a value on a record that is being saved. We can also use it to connect to a web service and process data whenever a record is retrieved in SugarCRM. In addition, we can leverage the SugarCRM framework and add records in other modules, such as automatically adding a call upon the creation of a new Lead record.

Our possibilities are virtually endless, but at the same time, this power can sometimes present some odd problems that are difficult to troubleshoot or resolve. 

One such matter relates to the duplication of data, usually the result of what appears to be an unintended loop within the code executed by the logic hook. On the surface, this sounds simple enough to troubleshoot, but looks can be deceiving.

Lets take a look a code snippet which we will assume is being executed by our logic hook:

class LogicHookTest {
        function addContact(&$bean, $event, $arguments)
        {
             //Grab contact ID value stored in custom field on current record
             $contact_id = $bean->contact_id_c;         

             require_once('modules/Contacts/Contact.php');
             $contact = new Contact();

             //Retrieve Contact record with matching ID value
             $contact->retrieve($contact_id); 
             //Set value on Contact's custom field 
             $contact->custom_field_c = 'New Value';  
             $contact->save();
        }
}

To elaborate, the code is grabbing a value from the contact_id_c field of the record currently being accessed in SugarCRM and assigning it to the $contact_id variable. For the purposes of the example we will assume the record being accessed is in a custom module.

Next, the code instantiates a Contact object and uses that same $contact_id value to retrieve the record with the matching ID value from the Contacts module. Lastly, a custom field named custom_field_c is modified on that Contact record and then saved. 

In summary, the logic hook retrieves a record from the Contacts module and modifies a field on that record, without us actually needing to be in the Contacts module.

Assuming the referenced custom fields existed, the above code would work. However, this may not always yield the desired results, which leads us into the problem at the heart of this post.