Here are some useful things for developers to know while developing in SugarCRM, that have fixed problems for me, or I've used while developing.
Generating a Unique Record ID
Sugar has a method that will generate a unique id for your application for use in your custom code, or in entering records directly in the database.
$uniqueDatabaseId = create_guid();
Let's take a look at the outcome. You, of course, would use this only while inside the Sugar application in custom hook code.
Turning Off Cache While You're Developing
In the admin panel go to Admin->System Settings-> scroll down to the "Advanced Tap" and click the "Developer Mode" check box. You should turn this off in production and test environments.
Turning Off AJAX use in Modules
Since SugarCRM version 6.3, a new method for loading pages that uses AJAX to load the html content rather than doing a full page refresh is being used. This has pluses and minuses. Yes, you do not have to redraw the entire page, however, when getting information back from the database through hooks, if the web page uses Ajax to refresh the data, SugarCRM does not know which information to provide the hook, the initial page information, or the page information from Ajax updates to the page. Consequently, Sugar throws an error, a popup alert message box is drawn on the screen which will stop the page from loading. The hook information will not be populated.
I also ran into a problem when using Ajax with sub menus not appearing on pages, or appearing once and then disappearing. To get around this you can turn off Ajax use on a module by module basis. The only ill effects is the page will have to be redrawn completely when ever the page is updated, which in most cases, you'll hardly notice the difference.
Open up the /config_overide.php file in the top level directory. Create a new entry in the file, like this:
$sugar_config['addAjaxBannedModules'] = "Accounts";
Since Sugar only reads the configuration files on log in. Log in again, or do a Admin->Repair->Quick Repair and Rebuild to get this change to take effect. Be aware, if you're changing the config file in your development system, and you need to turn off the AJAX in a module for your hook code to work correctly, you'll have to change the config files in all the servers running your application.
Finding your Sugar Version Number
When looking through the API, you may want to know what version of Sugar your using in your application. That's kept in a file in the top level directory:
The sugar version, database version, type of Sugar(CE, PRO), the build number, and the time installed is in this file. Here's what my file contents looks like:
$sugar_version = '6.5.16'; $sugar_db_version = '6.5.16'; $sugar_flavor = 'PRO'; $sugar_build = '1082'; $sugar_timestamp = '2013-10-20 11:31pm';
Adjusting the Sugar Session Time Out
Sometimes while your developing, Sugar will time out and you'll have to log back in before you can continue on with your work. Adjusting the time that Sugar uses for its time outs is adjusted in the php.ini file of your server. Here's the entry in the php.ini that you can adjust:
; After this number of seconds, stored data will be seen as 'garbage' and ; cleaned up by the garbage collection process. ; http://php.net/session.gc-maxlifetime session.gc_maxlifetime = 1440
The default setting is 24 minutes, which might seem like a long time, but developers can spend hours playing with one screen in Sugar. If your sysadmin will not let you mess with the php.ini file, you can use the .htaccess file to override the gc_maxlifetime PHP setting.
Getting Custom Modules to Appear in Display Modules & SubModules
Sometimes custom modules may not appear in Admin->Display Modules & Subpanels, which is frustrating because you can't get the menu on the front screen to access the module. You want to put the custom module in the list of modules for display in the top menu.
On install of the custom module, the file: custom/Extension/application/Ext/Include/[your-module.php] should have been auto-generated. This file is only auto-generated once by module loader. If the file is there, open the file and make the following changes;
<?php $beanList['your-module'] = 'your-module'; $beanFiles['your-module'] = 'modules/your-module/your-module.php'; //Prevent the module from being added to the no show list by commenting out these two lines //$modules_exempt_from_availability_check['your-module'] = 'your-module'; $report_include_modules['your-module'] = 'your-module'; //$modInvisList = 'your-module'; //takes the module out of the no show list if it is there unset($modules_exempt_from_availability_check['your-module']); unset($modInvisList['your-module']); //add the module to modules list $moduleList = 'your-module';
If the file in not there, create an empty file at the above location called: [your-module].php. And save the above content into the file.
Removing Nulls from Studio Fields
This was a time-consuming annoying problem for quite awhile before we figured it out. Every once in awhile you'll find one or more nulls in your Sugar Studio fields located in Admin->Studio->[your module]->Fields. Having a null visible within Studio causes errors when you try to Save. It can also cause the module to hang, and in certain instance crash the app. To remove these fields you need to find the file with the nulls and delete the nulls.
Open Studio to the fields tab that shows the nulls in your module.
Open custom/modules/[MODULE_NAME]/Ext/Vardefs/vardefs.ext.php and look for a field definition that is NOT listed in the list of fields shown in Studio. This may be found by looking for the field name(s) on either side of the "null" in the Studio field list. Comment out the suspect field and save the file. If the 'null' disappears in Studio, you have identified the correct/offending field definition. This file is auto-generated so this is only a temporary fix, until you rebuild the app, but it will help you find the correct null file.
Go to custom/Extension/modules/[MODULE_NAME]/Ext/Vardefs/sugarfield_[FIELDNAME]_ext.php. These are files that contain the custom fields. There should be one for each custom field found in the above auto-generated file, and these are the same files used to auto-generate the above file. Copy the file to another name in case the file does not regenerate on a rebuild, then remove (or rename) the file with the null. Do a rebuild, and the vardefs.ext.php file should be regenerated, and the null should be gone. I have on occasion seen the file not be regenerated, thus the reason for the copy.