Almost everything in Sugar in one way, or another, interacts with Sugar Modules. Each module works with a certain area of the application, or addresses a specific functionality. For example, we have modules for calls, meetings, contacts, accounts, employees, and many more. Modules are Sugars way of separating functionality into compartments and putting some walls around that functionality. It offers a way for other developers to add functionality to Sugar through custom modules and plug-ins. Modules also directly relate to tables in the database where the module's data is stored.
Although each module is different in functionality, with the exception of a couple of files here and there, they are all basically structured the same way. Let's take a look.
A modules core code is located in the modules/[a specific module] directory, so the accounts module is in modules/Accounts directory. If we look at the two examples of a modules directory in the accompanying image, in this case in Accounts and Bugs, we'll see a similar directory structure in each module. You'll also find similar file names and files in each module.
In looking in the bugs directory, we'll see some files. Bug.php is the main code for the bugs module. In the Accounts module, this would by Account.php, and so on for all the other modules. This file creates a variable for each field in the module, and it puts all the relationships with other modules in an array. It has a main "Bug" method that extends the base SugarCRM core functionality, and a bunch of database query methods, like: create_list_query, fill_in_additional_detail_fields, get_list_view_data, fill_in_additional_list_fields, get_summary_text, and save. When you click on a menu item, like bugs, on the home page, you'll go to this file which sets up and initiates the Bugs module, and then brings up the Bugs list view.
The BugsQuickCreate file is used when you want to create a new bug's record. Sugar has a quick create sub form that pops up in the home page window. You can use this form to create a record, or click on a button in the quick create sub-form and bring up the full form.
The field_arrays file is an array of the fields in the bugs module. This file is updated by Studio, the back-end admin GUI tool for customizing modules.
The Menu file contains an array used to build that module's menus. If you want to put extra menu item in a bugs view, you want to edit this file.
Finally, we have the vardefs file. This is an important file in each module. The vardefs file details how data fields are defined in the database. It connects the Sugar to the database. The vardefs file contains the module’s database table structure, its fields, indices, and relationship to other modules. Any custom fields created in Studio is added to the vardefs file, in addition to the database itself. This is what Sugar uses to translate the MySQL database to a SugarBean object.
Now, let's talk about the directories found in a module. All the directories are basically the same for all modules. I'll show you images of the files inside a couple of sub-directories, but in the interest of brevity will not cover all the files.
The views directory contains files with information needed to construct each of the views for that module in the front end of the application, in each view file is a class which extends the Sugar core view classes. For example, the BugsViewDetail class in the bug's view.detail.php file extends the include/MVC/View/views/view.detail.php core file. In this way, the Sugar MVC core is incorporated into the Sugar application. The view files add all the code from the core files needed to display the form, and it also incorporates the variable data that contains the information needed to display each field of the form. The views directory is all about the front panel display for that module.
The tpls directory stands for templates. In my overview, I mentioned that Sugar uses the Smarty2 template language. There is usually a QuickCreate.tpl file in this directory. This uses Smarty syntax to put the various variables and buttons needed into the Quick Create sub form on the front screen. Any templates used with modules are placed in this directory. Some third-party plug-in modules make extensive use of templates.
And so we arrive at the metadata directory. This directory contains all the metadata files for all the views and search forms in the module. These files are usually labeled with the view, like detailviewdefs.php, and contain the information that is created in Studio's layout GUI. The file contains an array of where fields are physically placed on the form, and what labels should be used for the form fields. If you go into Studio and change the layout of a view form, you're changing the corresponding metadata file for that view when you save the layout. In the same way, there is a subpanels directory for when you configure the subpanel layouts in Studio.
The language folder is about languages. Sugar is multilingual. When you set a main language in the locale settings in the admin panel you are telling Sugar to use a particular language file, in my case, I'll use en_us.lang.php, or U.S. English. Inside each language file there is a huge array of every possible field label in that module. Here you can change what Sugar will show for a field label in the front page of the application. When you change a field label in the admin->Studio back-end, you're changing this language file. If you're just using one language then you only have to worry about one of these files in your application. I will say this, there are many language files for a specific language in Sugar in other locations, related to both a specific module and the overall Sugar application, and which language file to use for a specific customization is one of the causes of headaches for developers.
Last, we have the Dashlets directory, Dashlets are like widgets in modern apps. There dynamically updated subpanels usually found on your home page, like the activity stream on the home page. Anything to do with dashlets are found in this directory.
That's it for a basic overview of a module and how they are set-up in Sugar. There is a lot more complexity, like auto-generated files, that Sugar uses that we won't get into at this time. From my description above, you can see that the back-end Studio GUI has considerable power to alter what is displayed in the front of the application by altering module files. So, I’ll cover the back-end GUI interface, Studio, in my next article, and show you how Studio can be used to easily modify the files we talked about today.