Where is the code for X?

Like myself, many SugarCRM admins/users are not developers by trade. We buy or download SugarCRM, become professional users, and then start looking into code level customizations in order to best fit SugarCRM to the business. The first problem with code customizations that we usually run into is actually finding the code to change. In this article, I step you through how to find that elusive code.

The tools that you will need for this search are the Firefox browser, firebug extension, and any IDE that can search for code in an entire directory ( I use Aptana ).

The key to finding a starting point is to identify a unique indicator or string that you can search for. The more unique the string, the more likely that you will get a few good hits on your search instead of 100 hits on the search. Let’s look at an example.

For this example we will use a recent Sugar Forum question which was “Where is the code that generates the help button?” In order to find a starting point we will go through the steps below.

1. Open your Sugar instance in Firefox and open Firebug

2. In Firebug click the Inspect button

3. Click the help link

This will show the code behind the button in the Firebug window.

4. The next step is to identify a string that you think might be unique to this section of the product.

For example: If you were looking to generate a different link then you may look in the line and determine that the help_action would be helpful. If you were looking for the module code, then you may see that there is a help_module string and just directly go to modules/Help. Either way you instantly know a little more about the Help system than you did before. We will move forward as if we just want to change the URL or how it is generated.

5. In the IDE, execute a string search for help_action across the entire SugarCRM directory.

This search results in about 132 ( there are multiple in some files ) matches depending on your version and edition. Not as unique as we had hoped but many of the matches can be quickly ruled out. There are 6 matches against each theme file.  However we don’t want the URL to change per theme, but rather we want it to change in the core somewhere. There is a match in a file in the cache directory but that will be overwritten at some point because it is a cache file.

We are left with files in two directories which are include and modules. If we wanted the URL to do something completely different in one specific module then we might want to pick that module and start there. If we are changing the way the URL is generated throughout the system then the search results under the include directory are the best place to look. There are only three files under this folder that returned results and we now have a starting point.

This technique is not full proof and is subjective to the user. However, the act of searching through the code for one string that appears unique can assist in quickly identifying a starting point for your code search.  Knowing that the core of the application logic is in the include and modules directories is key and also knowing to ignore anything you find in the cache directory is very helpful.  For a more thorough description of the code structure in Sugar, check out the Sugar Developer Guide.

Good luck with your code searches!

One of the things I’ve seen popping up on the Sugar forums lately is people looking for suggestions on hiding the left shortcut menu on their views. We do this in a number of places in the application, such as in Studio, Module Builder, in the AJAX Email client, and in step 3 of the Import module.

The most common approach I’ve seen discussed is to remove the contents of the side QuickCreate definitions. This will only remove the content of the menu, but doesn’t hide the actual menu from the view. The easier method is to hide the menu via JavaScript; doing this will allow you to simply default the menu to being hidden ( like we do the the aforementioned modules ) or you can completely remove it from the screen.

To have the menu start off hidden ( and preserve the users preference for having the menu visible or hidden ) add the following JavaScript code to display in the view.

<script type="text/javascript">

<!--

// hide the shortcut menu

if (!Get_Cookie('showLeftCol')) {

Set_Cookie('showLeftCol','true',30,'/','','');

}
var show = Get_Cookie('showLeftCol');

if ( document.getElementById('leftCol').style.display != 'none' ) {

hideLeftCol("leftCol");

closeMenus();

}
Set_Cookie('showLeftCol',show,30,'/','','');

-->

</script>

To not display the menu at all, add the following JavaScript code to the view instead:

<script type="text/javascript">

<!--

document.getElementById('leftCol').style.display = 'none';

document.getElementById('HideHandle').style.display = 'none';

-->

</script>

You can add this to output in the display() method of the view.  To learn how to override views, check out the Sugar Developer Guide.  Be sure to put your new view in the custom/ directory.

This is the first of a three-part series devoted to the MVC framework in SugarCRM.  In this particular article I will focus on the Controller.

As many of you know, MVC stands for Model-View-Controller and is a common design pattern to separate application logic from user interface logic while giving the developer easier control over the entire application.  In version 5.0, the Sugar team implemented our own version of MVC which gives us the following:

• cleaner and shorter code
• one place for making application-wide changes
• ability to use a metadata driven UI
• developer flexibility to define their own logic

As you already know a typical SugarCRM URL would be something like:

index.php?module=Leads&action=DetailView&record=12345

If we break this URL down, it would tell us to load the Leads module, perform the DetailView action within the Leads module, and load the record with id = 12345.  Out-of-the-box, SugarCRM ships with a default controller named aptly enough: ‘SugarController’ in /include/MVC/Controller/SugarController.php.

SugarController needs to account for using the new application framework while also supporting the old way of doing things (pre-5.0). As we said above, the action is DetailView. If the SugarController finds a file named: DetailView.php in the Leads module, it will load this file, otherwise it will check if the controller has a method named: action_detailview() which will then handle the request. There are several more configuration options which allow us to map actions directly to views or even map actions directly to files, but I will leave those until later.

This is all well and good, but what about when the developer wants to implement their own action_detailview()? In order to do this, the developer can simply drop a custom controller.php file into custom/modules/Leads.

For the SugarCRM MVC framework, we tried to stick with the mantra of convention over configuration as much as possible while also making things as dead simple as we can. Although this can lead to some upfront learning, down the road it will save time as you do not have to create complex configuration files to perform a simple task.  By that token, the developer’s custom controller would be named controller.php and the class name would be: LeadsController, basically ucfirst(module).’Controller’.

Example:


class LeadsController extends SugarController{

function action_detailview(){

//your logic here.

}

}

What this allows then is for the developer to override the methods they want to and allow the SugarController to handle the other methods.

One addition thing to note here is the concept of pre_, and post_ methods.

For each action defined in the controller, there exists the possibility of pre_<action> and post_<action>. So for example a Save action could have:

pre_save(), action_save(), and post_save() each of which can be overridden in the controller.php file. Having these methods gives finer control over to the developer. With our Save example, the bean can be populated from the POST in the pre_save() method within SugarController.php, but the developer could decide then to just override the action_save(), or post_save() without having to repeat the same logic for saving POST variables to the bean object.

For more details, see the User Interface Framework section in the Sugar Developer Guide.

We have been running load test after load test in the Sugar Labs to determine the performance of Sugar 5.1 and where to focus on improving performance in the future.  You will see performance benefits in 5.1 with the new logger utility, SugarLogger, that greatly reduces the CPU load and the revamped internal handling of custom fields that both reduces the amount of code as well as database queries. We already have a list of improvements we’ll be making to 5.2 and 6.0 as well.

We just finished analyzing one of our load tests that we felt the community would find interesting. This test was geared towards showing the benefits of operation code (op-code) caching as well as external data caching with SugarCRM. We ran a load test geared towards the sales automation functionality with a PHP accelerator, and then we ran it again the with the accelerator disabled.

The database was run on a separate server to ensure that it had no impact on the Web server CPU utilization.

What is Operation Code Caching?

When a user requests a PHP page, most PHP Accelerators will compile the PHP code for the requested page into bytecode. It will then save that bytecode in a cache either on the file system or in shared memory that allows the PHP Accelerator to skip the compile step the next time that PHP page is requested. This greatly reduces CPU utilization since a PHP script no longer needs to be compiled on every round trip.

What is External Data Cache?

An External Data Cache is either shared memory or file based storage that many PHP accelerators have that allow for storing data across round trips and sharing data between multiple users. SugarCRM has an API that takes advantage of these and can currently support APC, Zend Platform, and Memcache. This reduces file I/O as well as round trips to the database.

The Results:

We saw that with caching enabled, our test server completed more requests per second and the requests completed faster. Once we disabled caching we saw the average server response time shift from sub .5 second response times to around .75 second response times. You will also note in the graph below how much longer the tail of the chart is without cache. This indicates that there was a noticeable increase in the number of responses that took greater than 1 second response time without the cache enabled.

The biggest factor is the improvement in CPU utilization when you utilize a PHP accelerator. We saw a drop in CPU utilization from around 75% down to around 40% when utilizing both the op-code caching and the external data cache.

Conclusion:

If you are not running SugarCRM with a PHP accelerator, you really should be. You will see dramatic improvements in performance as well as scalability leading to better user productivity and reduced hardware needs. You can check out our wiki page on PHP Accelerators for more information.

Following quickly on the heels of the Sugar Developer Guide, you will now find the Sugar entity relationship diagrams available online.  The Sugar Community Edition ER diagram is available here and the diagrams for Professional and Enterprise editions are availble along with the software here.

The Sugar Developer Guide is now available to view online or download.

The Sugar Developer Guide provides information for developers who want to extend and customize SugarCRM functionality using the customization tools and API’s provided in the Sugar Community Edition, Sugar Professional Edition and Sugar Enterprise Edition. From adding custom fields to building new modules, from extending existing UI controllers to integrating data via Web Services, the Sugar Developer Guide details how the Sugar code works and and how to work with it.

The Developer Guide is found along with the other Sugar documentation.

We are pleased to bring you this useful tool and we look forward to expanding on it with your feedback. You will note that you can add comments to the HTML version of the document. We encourage you to contribute to the accuracy and thoroughness of this new guide.

–The Sugar Team

I can’t believe it’s already September! The nights are getting cooler, the days getting shorter, and for a large chunk of the world, it’s time to start re-engaging your brains as the fall school semester begins.

For those of us who have been out of the school rhythm for a while, maybe it’s time to think about taking a class to brush up on a skill or to learn something new. community colleges, at least here in California, are running a lot of their courses online and during evening hours to accommodate students who have regular jobs but want to further their educations or change careers.

One of our local community colleges here in Silicon Valley, California (Foothill College) has an online PHP and SQL course that is taught online starting September 22nd. The class still has openings, and is self-paced so you can fit it in to just about any busy schedule. Registration is open to any California resident, and you can visit this page for information about the online programs offered by them.

If you’re outside California, check with your local community college or university extension to see if they have classes that may interest you. Learning shouldn’t stop when we leave school; it’s a lifelong event.

As Abraham Lincoln once said, ” I don’t think much of a man who is not wiser today than he was yesterday. “

I was recently working with a customer and they were moving files about their Linux servers. Any time they edited a file, they downloaded it to their Windows desktop and changed it with Notepad. Then they would upload it back to the server using FTP in text mode.

Notepad adds Windows formatted EOL characters (End Of Line). When the file is uploaded back to the Linux box using FTP in text mode, the file now has a bunch of bad characters that affect the way PHP parses the code.

While this can happen at any time after editing files remotely, I ran into this most often when moving Sugar installations from server to server and we needed to edit the config.php or config_override.php files.  We first saw this issue when the Web Services API started failing mysteriously (see below):

The easiest thing is to use an editor like vi or emacs on the Linux server.  But if you don’t have SSH access, then be sure to upload files using FTP in binary mode. I also recommend Notepad++ for Windows. On a side note, I haven’t run into this issue on Mac OS X.

However, if all else fails, you can use this command to recursively change all text files from DOS format to UNIX format:

for i in $(find . -name "*" -exec file {} \; | grep text | sed 's/:.*//g'); do dos2unix $i;done;

That command is safe to run against any instance of Sugar. It will not attempt to convert the file unless it is a text file. dos2unix must be installed on your server and you’ll need shell access.

In Sugar 5.0, we revamped the Emails module to increase its value to users and to simultaneously improve the user experience.

Our goal was to increase user adoption of the application and help our customers maximize the return on their investments.  Our goal was not to build a fully-loaded email client, such as Outlook, or to replace the Sugar Plug-in for Outlook, but to provide a solid alternative to managing email correspondence within applications outside of Sugar.

The target users for the enhanced Emails module are power users of the application, such as Sales Representatives and Support Engineers.  For those users, the ability to conveniently communicate with prospects and customers through Sugar, and to easily relate their communications with the accounts, opportunities and cases, can save a lot of time and energy.

Functionality in the Emails module that existed prior to the 5.0 included the ability to create and use email templates and signatures, the ability to create records from emails, automatic importing of emails into Sugar, automatic association of the emails with existing contacts, leads and targets, an HTML editor for composing emails that can contain embedded images and the ability to set up group inboxes to share emails with team members.

Functionality added in 5.0 includes the ability to view and manage multiple email accounts and the option to selectively import emails into Sugar.  The advantage of being able to select specific emails to import into Sugar is reducing the amount of Spam and other emails that do not belong within Sugar.

In addition to a greater control over emails, users can now organize imported emails within personal or group folders in Sugar, as well as handle frequently emailed recipients within mailing lists.  And new in 5.1 is the ability to configure automatic creation of case records from inbound emails, which can significantly reduce the number of steps Support Representatives need to take to begin corresponding with customers and increase the amount of time they have to spend on resolving customer issues.

How successful have we been so far with the new Emails module?

Since launching it, we’ve received a lot of feedback from both customers and the community.  And we have taken a lot of it to heart.  There was an adjustment period for many users who were accustomed to the simplicity of the old interface and who had to access the same functionality differently in the new interface, and that has been the topic and subject of several Sugar Forums threads and customer support cases.  Many of the issues encountered and reported have been prioritized and fixed in the patches released since 5.0.

Moving forward, we plan on continuing to focus on improving the quality and performance of the Emails module, and fine-tuning the user interface so that it requires even less clicks to manage emails and related records.  However,  we remain open to the ideas and suggestions that we obtain from our user base about what we should consider for the Emails module in future releases.

We’ve received mixed input about how much further Sugar should go with the Emails module.  Are we going in the right direction with focusing more on the quality and performance and less on developing new features for the module?  Or is Emails lacking functionality that would truly make it useful within a CRM application?  Would it be better to continue developing and deepening other CRM features in Sugar?

Please feel free to let us know what you think.  We’re all ears!

How would you like your sugar served? In grains, cubes, in a bowl or in a packet? Yes, this may be a cheesy play on the SugarCRM name but it is the perfect metaphor for the deployment options you have with SugarCRM.

Many of the CRM vendors today have one or maybe two deployment options. With SugarCRM, you can deploy in any of the multiple ways you will see outlined in this article.

First let’s recap on just a few places and platforms that we have seen SugarCRM installed. We have seen it on the Bitnami LAMP/WAMP stack, in the cloud with Amazon EC2, hosted by SugarCRM Inc with Sugar On-Demand, or installed on your local Window, Mac OSX or Linux server.  Of course all of these different server installation options can be accessed with your web browser, mobile device or using the Sugar offline client.

To add to this list, we now have the SugarStick.  I initially created the SugarStick a year ago to show the flexibility of SugarCRM at the first SugarCRM Atlanta Meetup. The SugarStick is a completely self-contained Apache, PHP, MySQL, SugarCRM installation running from a USB drive or “stick”.  No, it’s not a VM image.  No, it doesn’t install the stack software onto your machine.  Read on…

A few issues arise when you start thinking about running a CRM application from a USB stick. The first is how to run Apache, MySQL, and PHP on a USB stick without having anything get installed to the host system. To overcome this, I found CH Software’s MoWeS Portable package.  It is a lightweight and easy-to-configure software package that runs Apache, PHP and MySQL without installing those software packages on your machine.

The next problem is, what if the host system is already running a Web server or DB server? This can be corrected by changing the default ports that the server runs on. In my How to make a SugarStick tutorial you will see a step-by-step guide on how to get this up and running.

To make it even easier, the people at CH Software have added SugarCRM to their package list on their download site. This means that when you download MoWeS portable, you can simply choose to include SugarCRM and it will come preinstalled.

Now that you know what the SugarStick is, you may be wondering what the uses for this would be. The benefit of this would be that it can be used on any Windows system and will not clutter your host with extra services that you might not need all of the time. The best use that I have been able to come up with is for entrepreneurs that are very mobile. The SugarStick enables them to use SugarCRM anywhere, with or without an Internet connection. It also enables them to work from different systems, if needed, by simply plugging in the USB stick to any system they are working on. The last use is as a promotional item. USB sticks are cheap, so brand them, install SugarCRM and give them away for people to play with and use.

To further discuss the SugarStick you can visit the tutorial post in the Sugar Forums: How to make a SugarStick