Making Sugar a bit more filesystem friendly every day…

bsoremsugar —  June 27, 2012 — 5 Comments

Our architecture team has been cranking away over the past year in trying to make Sugar a bit more sensible in how it treats the filesystem, namely in that making cache/ a true volatile storage area ( meaning you can wipe it out and not loose anything ), custom/ the place for all non-volatile disk writes ( such as putting customized files and other bits needing stored by the filesystem ) and then making the rest of the filesystem being able to be read-only.

Right now, the directories used for writing are…

  • cache/ – volatile content, can be deleted ( Though some temp files from the upgrade process can be there, so don’t delete in the middle of an upgrade :) )
  • upload/ – user-supplied files such as pictures, imports, documents, etc., that are uploaded to the Sugar instance.
  • custom/ – customizations and other long-term storage. This should be seldom written except for working with Studio/Module Builder or installing modules.

There are a few exceptions to this, where Sugar may write to files outside these locations. These are..

  • Logs ( sugarcrm.log, upgradeWizard.log, install.log ). You can put the sugarcrm.log in a different location by using the config directive ‘log_dir’ to specify it, or write your own logger class to managing the log with a different backend.
  • Configs ( config.php, config_override.php ). If you don’t want to change the system settings, these can be read-only.
  • Any module loadable package that installs new module or overrides an OOTB file.

We’ve made some pretty good strides in this area recently that I thought I would share with everyone…

  • All generated files throughout Sugar are now written to the cache/ directory, namely all of the combined and minified javascript files that were under the include/javascript/ directory are now in the cache/include/javascript/ directory.
  • The blowfish keys are now in the custom/ directory rather than cache/
  • Moved uploads out of cache since they should be externally writable, and should be preserved as they can’t be regenerated.
  • Cleaned up the code in modules like Emails, so it puts uploaded things into uploads/ but can copy it into cache if needed for display purposes.
  • Enabled putting the cache or upload directories in any directory, even if it’s outside Sugar tree.

Both of these items are now current as of Sugar 6.4.

We are continuing to find more ways to Sugar a bit more filesystem friendly, and would welcome your suggestions in the comments.

5 responses to Making Sugar a bit more filesystem friendly every day…

  1. 

    Another enhancement could be to push language file generated through the studio to the Extension directory (custom/Extension/modules/xxx/Ext/Language/) and not to it’s own directory (custom/modules/xxx/language/). Because currently when an admin modifies a language string or app_string  through the studio we never can override it with a package.

Trackbacks and Pingbacks:

  1. Cache & Upgrades Folder Content - January 24, 2013

    [...] [...]

  2. SugarCRM Developer Blog » Blog Archive » Deciphering the SugarCRM Cache Directory - January 28, 2013

    [...] ( 2013/01/28 ) – See this article for updates to how the cache directory is used now in Sugar [...]

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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