Updated 2009-01-07. One of the projects I am working on at the moment at my day job is customizing SugarCRM. We want to start managing all changes to SugarCRM using subversion, so we need to know which bits should be under version control and which bits should not. During my analysis I came across the ill‐named and infamous cache directory.
SugarCRM’s cache is anything but that. I already knew that uploaded files and e-mails were also stored in the cache directory, but I needed to know exactly what was in the cache so I can make some informed decision on what to put under version control and what bits of a production system should be backed up. I found my answer, after a whole lot of searching, reading the SugarCRM source code and asking around. It turns out that the cache directory contains a hodgepodge of user data files, configuration files and—oh yes, there are some real cache files in there as well.
If there is one thing to take away from this article it’s “Don’t mess with the cache unless you know what you’re doing”. That bears repeating:
“Don’t mess with the cache unless you know what you’re doing”
With that firmly burned into the back of your eyeballs, here’s an overview what the cache directory contains.
- cache/
This top‐level cache directory contains many subdirectories. All the standard directories are described below. Sometimes Sugar creates even more directories in here, for example when upgrading from one version to the next. Unless explicitly noted below you should never delete any of the files under the cache directory.
- cache/blowfish/
This directory stores the blowfish encryption keys that SugarCRM uses to encrypt and decrypt your POP3, SMTP and IMAP passwords. If you remove them, SugarCRM can’t decrypt the passwords anymore and you will need to re‐enter them.
- cache/csv/
Exports in CSV format are stored here temporarily before you download them. You can safely remove these.
- cache/dashlets/
Sugar keeps a list here of all dashlets that you can use. You can safely remove it. Sugar will recreate it automatically when it’s missing.
- cache/diagnostic/
When you run Sugar’s diagnostic tool, this is where it stores the diagnostics file. You can safely delete these files.
- cache/dynamic_fields/
This directory contains caches of all the custom modules and fields in order to speed up Sugar. You can safely delete it. When data is missing from it, Sugar will recreate it automatically. If you use the “Quick Repair and Rebuild” function it will also be cleaned and repaired.
- cache/feeds/
When you users subscribe to RSS feeds in SugarCRM, they will be downloaded to this directory before being displayed to the user. You can safely delete these files. Sugar will re‐download them.
- cache/generated_forms/
If you have created any web-to-lead capture forums, this is the place where they get stored. If you use these forms directly on your website (for example via an i‐frame) then you cannot delete them. But if you are like me and simply used them to create the correct HTML for your own website then you can safely remove these forms.
- cache/images/
-
This is a very nasty directory because it contains multiple types of data. Do not mess around with it!
The first type of data it contains are images that you embed or attach into outgoing mail. These images are cached here before actually being attached to the e‐mail when you hit “Send”. If you are using SugarCE (Community Edition) then you can safely remove these files.
If you are a SugarPro or Sugar Enterprise user then you’re out of luck. These editions of SugarCRM come with the Knowledge Base add‐on module. This directory is the permanent storage area of all the files and images you embed and attach to your Knowledge Base documents. You should not delete these!
This directory is a prime example of how not to use a cache. Bad developer, no Twinkie for you!
- cache/import/
When you import data in csv format, the uploaded files will be stored here. You can safely remove them.
- cache/jsLanguage/
Here you will find the JavaScript versions of all the language files. If they are missing they will be regenerated by the Sugar MVC View class, so can safely delete them if you want to.
- cache/layout/
In Sugar 4.0.1 and below, this directory holds the HTML files for the views that you customized with Sugar Studio. In Sugar 4.5.x and up this directory doesn’t seem to be used any more because the custom views are now stored in the custom/ and modules/ directories. So, this directory should be empty, but if you run an old Sugar (4.0.1 or prior) then do not delete the contents of this directory.
- cache/modules/
This is the directory where SugarCRM stores caches for all of the modules, templates, views, vardefs and more. You can safely remove most of these files, except some directories in the cache/modules/emails directory as listed below. They will be regenerated automatically when they are missing.
- cache/modules/emails/*
Updated: Thanks to spaps for this one. If your users are using their e-mail inside Sugar then the emails cache directory will contain multiple directories with uuid directory names (like 1e1c2480-473f-ee19-16f0-48c63de4bec8). You must not delete these.
- cache/pdf/
When you download a report in PDF format and Sugar cannot stream it directly to your browser, it will store the PDF file in this directory and offer it as a download. They can safely be removed.
- cache/smarty/
This directory contains three subdirectories that hold caches and configuration files for the Smarty templating engine that is used by the new MVC system in Sugar 5.0 and up. For a detailed description of what they are for you can read the Smarty manual. You should not remove these directories.
- cache/smarty/cache/
Smarty is able to cache static HTML version of templates which are stored here. Sugar does not use this functionality so this directory should be empty. If it’s not empty then you can safely clear it.
- cache/smarty/configs/
Here live the configuration files for the Smarty templating engine. It should be empty (as of Sugar 5.1RC), but if a future Sugar update ever installs a file in this directory it should not be deleted because it’s a configuration file.
- cache/smarty/templates_c
This directory contains compiled versions of all the Smarty templates. They are similar to the cached templates but they are dynamic PHP code instead of static HTML code. Smarty will automatically regenerate them if you delete them.
- cache/upload/
This contains all the files that you uploaded or attached to things in Sugar as well as your installed modules and upgrades. The contents of this directory should not be deleted. If you do, you will loose all the e‐mails, attachments and other files that your users added to Sugar!
- cache/xml/
The pipeline graph and various other graphs that SugarCRM displays are generated from XML files. These XML files are stored here. Sugar will regenerate them so you can safely delete the contents of this directory.
There is one directory that I haven’t quite figured out yet. On the SugarCRM forums a user called SugarDev.net posted a recipe for getting SugarCRM under Subversion control. He manually created the cache/data directory. None of my Sugar installations have that directory and grepping the SugarCRM source code yielded me no results about it either. When I do figure it out I will update this article accordingly.
Comments
#1 CRM Migration (http://www.mrvoip.com.au)
Looks like a bit of smarty template reading is on order too.
#2 Sander Marechal (http://www.jejik.com)
#3 spaps
Thanks for a comprehensive listing!
Much better than the answer I got from Sugar Support.
But I like to add some info about the cache/modules/emails/ directory:
If the SugarCRM users are using email in the system, you will get subfolders named something like "1e1c2480-473f-ee19-16f0-48c63de4bec8"
(it's the users id, there will be one for each user) under cache/modules/emails/.
Do not delete them or their content.
#4 Sander Marechal (http://www.jejik.com)
#5 Vishwas
It will b useful for newcomer like me to understand sugar in detail.
#6 Ragin Hari
Any files beyond modules/emails that cannot be removed?
#7 Sander Marechal (http://www.jejik.com)
#8 SugarDev.net (http://sugardev.net)
Great work on the articles here by the way.
Loek
#9 Vince Synolia (http://www.synolia.com)
thank a lot for this post, your article is really interesting and allow me to find one article for a lot of spread infos.
I did a french translation (not a pure translation by the way) for the french community (crm-france.com) and put a link back to your article, hope you don't mind ?
Here is the french version http://www.crm-france.com/dernieres-nouvelles/le-repertoire-cache-de-sugarcrm-demystifie.html
Regards,
Vince
#10 Sander Marechal (http://www.jejik.com)
#11 Rick Byers (http://www.ctigroup.com)
#12 Sander Marechal (http://www.jejik.com)
In both cases the data is on a different server but could potentially still be accessed through the DMZ server.
The only other thing I can think off is moving all of SugarCRM to a different server outside the DMZ and then use a proxy solution like Apache's mod_proxy to give access to SugarCRM from the outside.
#13 marsclark
Very helpful information to me as I administer SugarCRM for our company.
My question is, can I apply the suggestions for removing files from the various cache subfolders to our 5.2 version? I ask because your post #7 makes me think this is for 5.1 and maybe not 5.2?
#14 Sander Marechal (http://www.jejik.com)
So, when in doubt: don't delete.
#15 treats
Did you ever conclude what needed to be under version control to allow you to drop your revisioned code onto a fresh install of sugar and get out your production version again?
#16 Sander Marechal (http://www.jejik.com)
Also, here is a list of all my SugarCRM articles.
#17 Loek van Gool (http://sugardev.net)
#18 Sander Marechal (http://www.jejik.com)
#19 Niklas (http://www.oribium.se/CRM)
SugarCRM can be a jungle every now and then depending on what you're doing, and its work like this that helps people like me to find the right path out - thanks!
#20 Cesspool
#21 Mark (http://markvletter.nl)
#22 Wyatt (http://whatan00b.com)
#23 Alex (http://www.mohuweb.com)
#24 Keilaron (http://keilaron.ca/)
Very annoying.
#25 Tony (http://www.amazon.com)
#26 sugaroutfitters (https://www.sugaroutfitters.com)
This is simply a misunderstanding on how SugarCRM works and the best practices around managing multiple instances (dev/test/prod). Nothing is relied upon being in the cache. You can spin up a copy of an instance without the cache and it'll rebuild it appropriately.
#27 Keilaron (http://keilaron.ca/)
It IS bad design. I've been going over how to keep multiple instances (because we DO maintain dev, test, and prod environments for all our clients) and I noticed that when uploading some changes for newer versions of Sugar, repair didn't repair; it expected some data that the dev copy had only placed in the cache.
#28 Karl (http://www.yellow.co.nz)
A lot of the issues around things being in cache that shouldn't be have now been resolved - in particular the Blowfish Ciphers and Email module!
Comments have been retired for this article.