Introduction

Application Framework

The Sugar application code is based on a modular framework with secure entry points into the application (e.g. index.php or soap.php). All modules, core or custom, must exist in the <sugar root>/modules/ folder. Modules represent business entities or objects in Sugar such as Contacts, and the object has fields or attributes that are stored in the database, as well as a user interface (UI) for the user to create and modify records. A module encompasses definitions for the data schema, user interface, and application functionality.
The structure of Sugar’s root directory is shown below.
65_root.png

Directory Structure

SugarCRM code resides in various directories within the Sugar installation. The structure of the directories within the Sugar application consists of the following root level directories:
  • cache : Various cache files written to the file system to minimize database accesses and store user interface templates created from metadata.
  • custom : Location for upgrade-safe customizations such as custom field definitions, user interface layouts, and business logic hooks
  • data : Key system files, most notably the SugarBean base class which controls the default application logic for all business objects in Sugar
  • examples : Examples of how to extend Sugar, never run from the main app and should be removed from production instances
  • include : Many Sugar utility functions as well as other libraries that Sugar utilizes as part of its operations are located here. Most notable in this directory is the utils.php file that contains the most widely used utility functions.
  • jssource : Non-minified versions of JS files
  • log4php : This has been deprecated as it has been replaced by LoggerManager.
  • metadata : Relationship metadata for all many-to-many data relationships between the business objects
  • ModuleInstall : Code used to support the Sugar Module Loader
  • modules : Contains all modules in the system. Custom modules installed through the Module Loader exist here as well.
  • portal : Customer portal code v1
  • service : Web Services code for SOAP and REST v2 - v4_1
  • soap : Web Services code for SOAP v1; this has been deprecated.
  • themes : Files used to display the various themes
  • upload : Files uploaded into the application such as Note Attachments or Documents reside in this directory (refer to upload_dir parameter in the config.php file)
  • XTemplate : Old templating library that is being phased out and replaced by Smarty, but some code still may use it.
  • Zend : Classes used in the framework

Key Concepts

These are the main files, classes and application concepts that comprise the Sugar platform.

Application Concepts

  • Controller : Directs all incoming page requests. This can be overridden in each module to change the default behavior and relies on Entry point parameters (described below) to serve the appropriate page.
  • Views : A set of user interface actions managed by the Controller, the default views in Sugar include the Detail View, Edit View, and List View.
  • Display strings : Sugar is fully internationalized and localizable. Every language pack has its own set of display strings which is the basis of language localization. There are two types of display strings in the Sugar application: application strings and module strings.
    • Application strings contain the user interface labels displayed globally throughout the application.
      • $GLOBALS[’app_strings’]
        • Array - Contains labels values
      • $GLOBALS[’app_list_strings’]
        • Array - Contains the system-wide drop-down list values.
    • Each language has its own application strings variables.
      • $GLOBALS[’mod_strings’]
        • Array - Contains strings specific to the current, or in-focus, module.
  • Dropdown lists : Dropdown lists are represented as name => value array pairs located in the application strings mentioned above. The name value is stored in the database where the value is displayed in the Sugar User Interface (UI). Sugar enables you to create and edit drop-down lists and their values through the UI in Studio. Use the handy get_select_options_with_id() utility function to help render the <select> input options to work with drop-down lists in Edit Views. Use the translate() utility function to translate the string key you are working with into the user’s currently selected display language.

Files

  • SugarBean.php : This file located under the <sugar root>/data folder contains the SugarBean base class used by all business entity or module objects. Any module that reads, writes, or displays data will extend this class. The SugarBean performs all of the heavy lifting for data interactions, relationship handling, etc.
  • modules.php : The modules.php file contains several variables that define which modules are active and usable in the application.

Variables

  • $dictionary : The $dictionary array contains all module field variable definitions (vardefs), as well as the relationship metadata for all tables in the database. This array is dynamically built based upon the vardefs.php definitions.

Entry Points

The primary user interface entry point for Sugar is through index.php located in the root Sugar folder. The main parameters for most calls are:
  • module : The module to be accessed as part of the call
  • action : The action within the module
  • record : The record ID
The following is a sample URL for a Sugar call:
http://{sugar_url}/index.php?module=Contacts&action=DetailView&record=d545d1dd-0cb2-d614-3430-45df72473cfb
This URL invokes the Detail View action from within the Contacts module to display the record denoted by the record request value.
Other commonly used parameters are return_module , return_action, and return_id. This group of request parameters is used when a user cancels an action such as creating or editing a record.
Note: As of Sugar 5.1, entry points were consolidated into index.php. Previous versions had other files as entry points into the application.