Improving SugarCRM client-side performance: The SugarCRM AjaxUI

sugarcrmdevelopers —  September 30, 2011 — 27 Comments

Editor’s Note: This post is the final in a three part series where we’ve talked about improving the SugarCRM client side user experience. Previous parts of the series focused on server side and client side performance and what can be done to improve things. In this part, Senior Engineer David Wheeler highlights the new AJAX UI coming to all editions of Sugar 6.3, which provides increased client-side performance and lower server load by using AJAX techniques to optimize the page load.

In version 6.3 of SugarCRM we are introducing a new method for loading pages that uses AJAX to load the html content rather than doing a full page refresh. This has some major impacts on performance. The biggest gains are:

  1. Reduced server load: The server no longer has to render the header, footer, or check the standard javascript, image, and style files for each request. Only the initial load renders these elements.
  2. No full rebuild of the Dom: Rather than destroying and rebuilding the entire Dom tree, only the center content area is updated.
  3. Script files are not parsed: Normally when a page is loaded, even if the javascript files are cached, the browser must reload into memory and parse all the script files. Sugar uses a very large amount of base javascript that remains the same on each page. By only parsing the javascript specific to the current page, a huge performance boost is gained. This is especially noticeable on machines with fast net connections but slow drive/cpu speeds.
  4. Fewer requests per page: When a web server is configured to set very large cache timeouts, this isn’t a very big deal. The client will only load the script, image, and style files once and never make a request for them again until Sugar is updated. However, many servers are not configured this way and the client will make a request to the server, even if it is just to verify the cache isn’t out of date, for every single resource on a page. This can mean up to 100 requests for some pages. With the AjaxUI, these files stay in memory until the user closes the browser even if the cache expire is not configured. For a connection with a high ping, it can make a page load time go from tens of seconds for 50 requests down to a single request taking under a second.

There are some side effects of the AjaxUI that can cause issues with customizations.

  1. document.write: Because the Dom has already “fully loaded” when the page is rendered, any custom javascript that uses document.write will instead of appending to the current page, replace the current content. The best practice here is to use Dom Manipulation or at worst, append to document.body.innerHTML (but this is also not a great idea).
  2. onLoad: Just like with document.write, this event is no longer reliable because the page has already “loaded” before the main content is inserted. If your javascript relies on some content in the page to finish rendering before it can fire, you should wrap your code with YAHOO.util.Event.onContentReady.
  3. Page order vs execution order: One final javascript issue is the order of execution of script blocks. This isn’t always a problem but it tends to be browser specific. If for instance you wanted to use jquery and your code looked something like this:

    you couldn’t guarantee that the second bock would fire only once jquery had loaded. To help with this problem, we’ve added a function to Sugar called SUGAR.util.doWhen. It has an signature similar to onContentReady except that instead of only wait for Dom elements to appear, it can wait for any condition to be true.  The first parameter can either be a string to be evaluated or a function to call, but as soon as either is true, the function passed as the second parameter is fired. So using doWhen, the above block could either look like:


    or even
  4. JSON responses: The final thing to watch out for is php warnings and errors causing invalid server responses. These kinds of errors being displayed won’t cause the same level of headache with a normal UI as the user can often just ignore them and continue until the admin gets around to fixing them. With the AjaxUI, the errors can cause the server response to become invalid and the page fail to load entirely. On a production instance these errors and warnings should be logged rather than shown to the user anyhow, but with 6.3 you might want to double check your settings. Also, if you have a customization that tries to bypass the MVC Controller and send content directly, it could also run afoul of this issue.

If any of these problems crop up and can’t be fixed easily, you also have option of disabling the AjaxUI for a single module or across the entire app. Starting with 6.3 RC1, there will be an admin section for disabling the AjaxUI on a per module basis. It can also be done manually in the config override with a line like:

$sugar_config['addAjaxBannedModules'][] = "Contacts";

That would cause links to the Contacts module in the app no longer attempt to load via the AjaxUI, and use the normal URL structure.

You also have the option of totally disabling the AjaxUI with the following line.


27 responses to Improving SugarCRM client-side performance: The SugarCRM AjaxUI


    Wow, that doWhen is really helpful. I wish it was part of the base yui or even better the ECMA standard.

    But my attempt to use it (in a 6.1 instance) failed.  I grep’ed for it on an install of 6.2, and nothing came back.  Is this going to a be a feature in 6.3?

    If that’s the case, you may want to make that more clear in this post, since the other two modifications (regarding document.write and window.onload) can already be added to any customizations “as is” before the move to 6.3, while this one will need to wait until after the upgrade *and* will need to be changed back in case of a rollback.


    Quite agressive feature! But i think all community was waiting for it.
    And as a developer we will have lots of work (and headache) on porting existing solutions on Sugar 6.3.0, OMG 🙂


    For those looking to be able to use JQuery techniques on new DOM elements brought in via an AJAX call (or whatever).  You can use the .live() jQuery method, that will work on current and future elements.

    For instance I use the following to add a masque to some EditView form fields.

      // Adds an input mask to some form fields.
      $(“:input:not(.masked).phone”).live(‘focus’, function() {


    Hi ,

    I have issue in the AJAX pop up window in the Drop town Editor section. Even I disable
    the AJAX disable option in the config overwrite file also. But still the pop
    with error displaying. Please give the advice to fix this issue. It’s grateful
    for me.
    I have attached my screen. Please review it.


  5. March 16, 2012 at 3:32 pm

    In 6.4.2 the only way to disable “system-wide” this feature is:
    in config.php, add a line:

      ‘disableAjaxUI’ => true,

    in line 5 (or any other).



    Am using 6.4.4 even i disableAjaxUI , when i click edit the POP up UI coming, how to avoid this, i want to directly to full form edit


    Hi everybody,

    I am submitting the data to custom module through ajax, with the help of following function.


    After action completion of called custom module , I want to show the success or error message to client browser on top as we see messages like done or please wait etc..

    Please suggest, how can I do this. I am using the sugarCRM 6.4.

    I found  $_SESSION[‘administrator_error’] for error but I don’t find any thing regarding success. And also this message not shown on top.

    Waiting for response.

    Hrishikesh Mishra


       We have a Developer Blog post coming in a few weeks to highlight this, but here’s a preview of what to do…

      // Display a message to the user before the actionajaxStatus.showStatus(‘Message to display while doing the action’);//// Perform the AJAX action//// Now hide the message when we are doneajaxStatus.hideStatus();


    A belated follow-up here. If you output html/js in your process_record or *_retrieve hooks (or anything besides after_ui_frame/after_ui_footer) it will cause the json returned in AjaxUI to be malformed. If you really need to output it’ll need to be in the after_ui_* hooks.


    Ran into an issue where echoing in an after_retrieve hook caused the AjaxUI to go wonky. Ended up that this would only happen on initial page load. Subsequent ajax requests worked just fine (subpanels, etc). We ended up doing a short writeup about it and how to work around. Left off details on the why:

    Hope that helps someone else who runs into it.


    It seems like there’s still a minor issue going on. I’ve added the following to my config_override.php to disable AJAX UI for my custom module like:

    $sugar_config[‘addAjaxBannedModules’][] = ‘Iface_Encircle’;

    However, the pagination buttons still seem to reference AJAX so when I click on an arrow button to advance through my ListView, I get the following screen:


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s