In my last article, I gave you a general introduction to SugarCRM from a marketing perspective. This time I want to delve into how Sugar works under the hood from a broad perspective. I will delve into individual files and what they do in future articles.
Sugar installs like any other PHP application or framework. You load the software, go through an install that hooks up and populates the MySQL database tables. You then log into the Sugar, go through a brief introduction, and come to the home page. Like most web applications you have the front-end of the application, or what the user will see in their browsers, and the back-end admin panel that helps you configure and change the appearance and functionality that the user will experience in the front-end.
The front end consists of a home page and menus that take you to various other parts of the application, for example: Contacts, Users, Companies, Documents, Opportunities, etc.
As you go into each of these areas, you’ll find only three basic views through out the entire application. First, you’ll see a list view that lists all the records in a table format, from there, you can click on an individual record, and see a detailed view that shows more information about that individual record, from there, you can go to the edit view that allows you to enter and edit information in that individual record. Usually the detailed view looks the same as the edit view, with the exception that you can save your changes in the edit view.
There is one other type of view that you’ll find called sub-panels. Sub-panels are located in the bottom section of the home page, and in some detailed view pages. In Sugar, two different types of records can be related to one another, for example, users can be related to a company. When you set up this relationship, Sugar creates a sub-panel to display the related information. If you open a detailed view for a particular company, you’ll see a sub-panel showing a list view of the users in that company. On the home page, you can configure which sub-panels you would like in your home page.
Since Sugar is a PHP open source application, everything in Sugar can be modified or changed, and I do mean everything. And there lies the complexity of Sugar. Sugar does attempt to make this as painless as possible by giving you an extensive back-end admin panel. In one area of the admin panel, called Studio, you can change almost everything about the front-end of Sugar. Any field labels can be easily changed. You can add different types of fields to a detailed view. You can change the layout, or what fields are visible, and where they are located on the page, of the all the views and sub-panels. You can create relationships between different areas of the application. This is all done in Studio.
To go a little deeper, when you first open Studio, you are shown icons of all the different sections, like contacts, users, companies, etc. in Sugar. These sections are called "modules." The key to understanding Sugar internals is to understand modules. In Sugar, there are a lot of modules. Modules allow Sugar to break the application into individual functionality. It also allows developers to create new modules with new functionality that are installed as plug-ins to the application. In the back-end admin panel there are two sections called module builder, and module loader that makes it easy to build and deploy new modules and update existing modules.
Sugar is an MVC application, but this is not easily discernible when you look at the Sugar file structure, nor do you code in Sugar like you would a PHP framework. From my perspective, there are four main areas of Sugar code: core, theme, custom, and cache. Core is the application code that makes Sugar go and should not be changed. The Core files are spread over a number of directories, which makes Sugar a challenge to figure out. The Theme directory configures the overall CSS look of the application. The Custom directory allows developers to change Sugar core code without affecting the core files. Code changes should be done in the custom directory to protect your changes from future Sugar updates. Last the cache directory, Sugar is not a fast application, because on every call for a new view, Sugar gets a ton of information out of the database, and puts this information in an object, called the Sugar Bean. To help with performance, Sugar caches every view. To a developer the cache is a pain, since you have to remove cache to make sure your changes were completed. If you delete the cache directory, Sugar immediately turns around and creates a new cache.
Back to the Sugar Bean, the Sugar Bean is essentially the Sugar version of an ORM for its MySQL database. This gathers all the information in the database for that particular area of the application, or module, and puts it into an PHP object-oriented container. So code, like $users->name; , makes developer's job much easier instead of using SQL CRUD every time you need information out of the database.
Which brings us back to modules, modules allow Sugar to divide the code and put walls around areas of functionality in Sugar. The core code for modules in Sugar are in the modules directory, and if you want to change the code in the modules, those changes are in the custom/modules directory. Every module in Sugar deals with an area of the application. There are modules for Accounts, Administration, Bugs, Calendar, Calls, Campaigns, Cases, Charts, Connectors, Contacts, Contracts, Currencies, Documents, Emails, Employees, Forecasts, Groups, Manufacturers, Meetings, Notifications, Products, Project, Project Task, Prospects, Relationships, Reports, Roles, Schedulers, Shippers, Tasks, Teams, Users, WorkFlow, etc. In addition, every new 3rd party plug-in will have their own module, or modules. Any custom modules you build will end up as a module. This should give you an idea of the breadth of Sugar. Add to that breadth the fact that you can create relationships between modules, and you can see how complex Sugar can get.
I think I'll stop here, this article was an overview of what's under the hood in SugarCRM from a 50,000 foot level. In my next article, I'll go into the the inner workings of the files and directories in a module, and how modules interact with the rest of Sugar.