Hi, sorry if this is a dumb question. I just upgraded from 7.9 to 7.10, and now my site seems to have lost its CSS. The upgrade went just fine, with all permissions checking out ok, etc, I just seem to have lost my theme. As far as I can tell, the theme files are in the right place. Is there something I need to do to get my CSS working again?
FWIW, I’ve tried it in multiple browsers, cleared the cache, etc - it’s definitely something server-side.
This normally doesn’t happen, except when there are permissions issues. But to work around it you can try Admin / Repairs, not only the Quick Repair and Rebuild but also a few others (the ones mentioning javascript).
You can also check your logs for errors, and you can delete the directory “cache/themes”, it will get rebuilt.
Thank you for the reply, I appreciate all the help I can get!
I went through the admin/repair thing, and did the following items:
Quick Repair and Rebuild
Rebuild SuiteCRM Dashlets
Rebuild Javascript Languages
Rebuild JS Compressed Files
Rebuild JS Grouping Files
Rebuild Minified JS Files
Repair JS Files
I notice that on most of them, it would give me a message saying that it might take a few minutes, and then shortly after that, I’d get a new message that just said “undefined”.
I also deleted cache/themes, and as you predicted, it came back when I refreshed my page. Unfortunately, none of these steps seem to have affected my problem any. I looked through suitecrm.log, and the most interesting thing I found there was this:
Wed Feb 21 14:45:20 2018 [613763][1][FATAL] ERROR: rmdir_recursive(): argument cache/themes/SuiteP/modules is not a file or a dir.
Sure enough, I don’t have a directory called “modules” in that folder - should I?
Can you please post the results of this command, given from your SuiteCRM root folder?
ls -al
Also, if you go into Admin / Upgrade Wizard, and run only the first step of the wizard (don’t worry, you don’t need to upgrade), does it complain about files that are not writeable?
Thanks again for the reply, I really appreciate the help. Here are the results of the command you gave me:
drwxr-xr-x 21 cfcmtool cfcmtool 4096 Feb 20 13:53 ./
drwxr-x--- 4 cfcmtool nobody 4096 Nov 18 15:18 ../
-rw-r--r-- 1 cfcmtool cfcmtool 1689 Feb 20 15:15 .gitignore
-rw-r--r-- 1 cfcmtool cfcmtool 1376 Nov 18 15:18 .htaccess
-rw-r--r-- 1 cfcmtool cfcmtool 839 Feb 20 15:15 .travis.yml
-rwxr-xr-x 1 cfcmtool cfcmtool 3094 Feb 20 15:15 CODE_OF_CONDUCT.md*
-rwxr-xr-x 1 cfcmtool cfcmtool 2808 Feb 20 15:15 HandleAjaxCall.php*
-rwxr-xr-x 1 cfcmtool cfcmtool 34539 Oct 28 11:57 LICENSE.txt*
drwxr-xr-x 3 cfcmtool cfcmtool 4096 Oct 28 12:12 ModuleInstall/
-rwxr-xr-x 1 cfcmtool cfcmtool 3837 Feb 20 15:15 README.md*
-rwxr-xr-x 1 cfcmtool cfcmtool 5327 Oct 28 11:57 SugarSecurity.php*
-rwxr-xr-x 1 cfcmtool cfcmtool 5839 Feb 20 15:15 TreeData.php*
drwxr-xr-x 2 cfcmtool cfcmtool 4096 Oct 28 12:31 XTemplate/
drwxr-xr-x 8 cfcmtool cfcmtool 4096 Feb 20 13:54 Zend/
-rw-r--r-- 1 cfcmtool cfcmtool 411 Feb 20 15:15 bower.json
drwxrws--- 2 cfcmtool cfcmtool 4096 Feb 20 13:53 build/
drwxrwxr-x 15 cfcmtool cfcmtool 4096 Feb 21 08:01 cache/
-rwxr-xr-x 1 cfcmtool cfcmtool 3587 Feb 20 15:15 campaign_tracker.php*
-rwxr-xr-x 1 cfcmtool cfcmtool 1027 Feb 20 15:15 composer.json*
-rwxr-xr-x 1 cfcmtool cfcmtool 114330 Feb 20 15:15 composer.lock*
-rwxr-xr-x 1 cfcmtool cfcmtool 11621 Feb 21 07:48 config.php*
-rwxrwxr-x 1 cfcmtool cfcmtool 584 Feb 21 08:21 config_override.php*
-rwxr-xr-x 1 cfcmtool cfcmtool 5052 Oct 28 11:57 cron.php*
-rwxr-xr-x 1 cfcmtool cfcmtool 2446 Oct 28 11:57 crossdomain.xml*
drwxrwxr-x 10 cfcmtool cfcmtool 4096 Feb 20 13:53 custom/
drwxrwxr-x 3 cfcmtool cfcmtool 4096 Oct 28 11:57 data/
-rwxr-xr-x 1 cfcmtool cfcmtool 2386 Feb 20 15:15 dictionary.php*
-rwxr-xr-x 1 cfcmtool cfcmtool 12566 Feb 20 15:15 download.php*
-rwxr-xr-x 1 cfcmtool cfcmtool 2390 Feb 20 15:15 emailmandelivery.php*
-rwxr-xr-x 1 cfcmtool cfcmtool 83031 Feb 20 15:14 error_log*
-rwxr-xr-x 1 cfcmtool cfcmtool 4918 Feb 20 15:15 export.php*
-rwxr-xr-x 1 cfcmtool cfcmtool 967627 Oct 28 11:57 files.md5*
-rwxr-xr-x 1 cfcmtool cfcmtool 2367 Feb 20 15:15 ical_server.php*
drwxr-xr-x 58 cfcmtool cfcmtool 4096 Feb 20 13:53 include/
-rwxr-xr-x 1 cfcmtool cfcmtool 2374 Feb 20 15:15 index.php*
drwxr-xr-x 6 cfcmtool cfcmtool 4096 Feb 21 08:10 install/
-rwxr-xr-x 1 cfcmtool cfcmtool 18032 Oct 28 23:35 install.log*
-rwxr-xr-x 1 cfcmtool cfcmtool 31893 Feb 20 15:15 install.php*
-rwxr-xr-x 1 cfcmtool cfcmtool 2275 Feb 20 15:15 json_server.php*
drwxr-xr-x 3 cfcmtool cfcmtool 4096 Oct 28 12:09 jssource/
drwxrws--- 7 cfcmtool cfcmtool 4096 Feb 20 13:53 lib/
-rwxr-xr-x 1 cfcmtool cfcmtool 2313 Oct 28 11:57 log_file_restricted.html*
-rwxr-xr-x 1 cfcmtool cfcmtool 2376 Oct 28 11:57 maintenance.php*
drwxr-xr-x 2 cfcmtool cfcmtool 4096 Feb 20 13:53 metadata/
drwxrwxr-x 119 cfcmtool cfcmtool 4096 Feb 20 13:53 modules/
-rwxr-xr-x 1 cfcmtool cfcmtool 2886 Feb 20 15:15 pdf.php*
-rwxr-xr-x 1 cfcmtool cfcmtool 304 Feb 20 15:15 php_version.php*
drwxrws--- 2 cfcmtool cfcmtool 4096 Feb 20 13:53 public/
-rwxr-xr-x 1 cfcmtool cfcmtool 73 Oct 28 11:57 robots.txt*
-rwxr-xr-x 1 cfcmtool cfcmtool 3588 Oct 28 11:57 run_job.php*
drwxr-xr-x 12 cfcmtool cfcmtool 4096 Oct 28 12:23 service/
drwxr-xr-x 2 cfcmtool cfcmtool 4096 Oct 28 12:24 soap/
-rwxr-xr-x 1 cfcmtool cfcmtool 4088 Feb 20 15:15 soap.php*
-rwxr-xr-x 1 cfcmtool cfcmtool 154 Feb 20 15:15 sugar_version.json*
-rwxr-xr-x 1 cfcmtool cfcmtool 2296 Feb 20 15:15 sugar_version.php*
-rwxr-xr-x 1 cfcmtool cfcmtool 127067 Oct 28 23:35 sugarcrm.log*
-rw-r--r-- 1 cfcmtool cfcmtool 251622 Feb 21 10:30 suitecrm.log
-rwxr-xr-x 1 cfcmtool cfcmtool 168 Feb 20 15:15 suitecrm_version.php*
drwxrwxr-x 6 cfcmtool cfcmtool 4096 Oct 28 12:24 themes/
-rwxr-xr-x 1 cfcmtool cfcmtool 2030211 Feb 21 07:53 upgradeWizard.log*
drwxrwxr-x 3 cfcmtool cfcmtool 4096 Feb 20 15:14 upload/
-rwxr-xr-x 1 cfcmtool cfcmtool 123 Oct 28 23:23 userTest.php*
-rwxr-xr-x 1 cfcmtool cfcmtool 2976 Feb 20 15:15 vCard.php*
-rwxr-xr-x 1 cfcmtool cfcmtool 2248 Feb 20 15:15 vcal_server.php*
drwxrws--- 18 cfcmtool cfcmtool 4096 Feb 20 13:53 vendor/
The upgrade wizard tells me everything is fine. I even tried doing the upgrade again (this time using the 7.10 to 7.10 upgrade file), but it didn’t do any good.
Same thing happened to me… I’m half way though the upgrade to 7.10 when all of a sudden I get a text screen. Basically the system lost the CSS. If this happens to you, scroll all the way to the bottom and you will see "continue’ button of the install. Click that and go on with the install… each screen will require you to scroll down again and click.
When done you need to look in the list for the Logout can click that.
When done you then have to get to your Suite directory (on FTP if running on a server) and go the Cache folder and make sure that the Themes folder and ALL of the files and folders under it have 775 as the permission. You also want to check the JSLanguage folder for a file called en_js.us and set it to 775 as well.
You should be able to bring up your login screen the normal way and it should render correctly and 7.10 should be installed (Go to the About screen)
In all the years of using Sugar and then Suite I’ve never had an install as messy as this one was. I should have waited a week or two for release 7.10.1.
Holy moley, it worked!
I tried setting the permissions to 775 for the “Themes” folder and everything in it, and that didn’t do it, even after I deleted the cache/themes folder again. The only JSLanguage folder I could find was in the cache - I tried changing the permissions on the en_us.js file there, and that didn’t do it either. Finally I set the permissions on the whole cache folder (cascading down) to 775, and my CSS came back!
Many thanks to both of you, I really appreciate the help! Now I can get back to configuring everything. 
There are two Theme folders… on in the root directory of the site and one in Cache. I have no idea what there are two of them. I already had the one in root at 775 so I then cascaded 775 in the one in Cache as that is where the CSS is for the SuiteP theme.
I was very relieved when it worked. I was almost ready to do a fresh install… but as I remember there is no easy way to do a fresh install with an existing database. The install creates a new tables in an empty database but I’m sure that I could change the config.php file to point to the old database so long as it was not corrupted. It would be nice if SuiteCRM’s installer gave us the option to create a new database or use an old one from the same release version.
Had this not worked I would probably do the above procedure for old data and then start fresh with a different database and figure out how to import old data. I like the X2CRM open-source product… or maybe I’d go with something hosted where ‘they’ maintain it.
Anyway, SuiteCRM was able to be fixed so I’ll stick around for another year at least.
Guys, I’m really glad you got things working, but bear in mind that there is no reason for a well-configured SuiteCRM system do degrade it’s permissions, meaning, you shouldn’t have to reset any permissions at all after the initial settings when you first install.
Saying permissions are “775” doesn’t mean anything until you specify the other elements used in the evaluation of permissions, namely, user name accessing the files, file ownership, group memberships, sticky bits, umask.
So you should watch out for the real cause of your problems:
are your cronjobs running as a different user than your web server?
did you remember to stop your cron jobs before doing the upgrade? You don’t want anything messing up your cache during an upgrade (BTW, I believe this is the reason both of you ran into problems)
do you have any weird permission settings in the default_permissions array in config.php, or in utils.php?
I am sorry if this is a bit complicated when you just want it “to work” but this is the technical reality of what’s going on. Some of these things I have plans to improve when I get a chance.
When you say cron job do you mean this script:
#!/bin/sh
cd /usr/www/users/xxx/xxx/suite; /usr/local/bin/php -f cron.php > /dev/null 2>&1
This runs once an hour and I have no idea what it does or why it runs and no doubt it runs as a different user than the web server which uses fastcgi as “me” because when I ran it as ‘nobody’ it totally screwed up SugarCRM updates. SuiteCRM usually does not care about the user name during updates.
I’ve always had to re-do the permissions on only one file after an update… en_js.us file. For some reason every update always revered it back to 650 or something and it screwed up part of the Suite user interface.
Over the ten years I’ve run Sugar and then Suite, upgrades have always been a hold-your-breath-and-pray kind of thing. Nothing has changed! Today was the worst update I’ve ever seen and it is a good thing that I have good system skills. The average user would never in a million years get this fixed.
I don’t complain because I get SuiteCRM for free and so my expectations are lower than if I were paying for it. All in all both Sugar and Suite have served me well.
The good news is that you really don’t need to suffer this permissions craziness anymore. Just get your config right and it will work, for good.
A couple of years ago all the instructions about this were misguided and often times, wrong. You can do it right now.
Go into Admin / Schedulers and see the instructions about setting up cron at the bottom.
That will tell you which user’s crontab you should use. Of course, you also need to remove it from the current crontab.
The next time you do an upgrade, comment out that cron line to stop cron during the upgrade, then put it back the way it was, once the upgrade is finished.
After you fix cron, you may need to reset all your ownerships/permissions one final time.
What that cron job does is run the SuiteCRM Schedulers service. People normally configure it to run once a minute, so it reacts quickly to events in the CRM. Then these jobs will do several things, on they’re own schedule, as listed in Admin / Schedulers.
Important functions that depend on this are Global Search indexing, Workflows, Campaigns, Inbound Email, and Email reminders. But there are more.
Changing permission setting to 775 for the cache->themes->SuiteP->css->Dawn in the cPanel did the trick for me. When I went to change the layout style under profile settings from Dawn to Day, it automatically reverted. I had to go back to cache->themes->SuiteP->css and this time I noticed Day appeared in the css folder, when I changed its permission settings to 775, and refreshed the link to the crm, then the new style was viable. I repeated the settings for Day to Dusk and Dusk to Night. Now all the styles are usable with out the loss of css style.
I hope this helps someone dealing with the same issue.
Thanks @athiele, for sharing your workaround.
Please - if somebody has this same problem, and wants to apply the fix, run some diagnostics first so I can understand exactly what was broken, otherwise we can’t fix it.
A quick command to analyze permissions on a server is this:
tree -iupf cache/themes
There I’m only focusing on the cache/themes folder, but you can also use it for the entire SuiteCRM tree, and then grep it for what you want (for example, “root” ownerships).
If you add a “d” option to the command, instead of showing you files and directories, it will show you directories only. This might be useful to get a quick, higher-level view.
Sorry, I understand my message needs some clarification. (Can’t I edit posts/reply’s?)
With images, I mean the CSS icons like the home button, the magnifying glass for search and the little check mark next to the status of the lead.
Any suggestions? Your help is very much appreciated!
@hoenie You probably upgraded to 7.10.2. which uses new icons. Probably all you need is a Quick Repair and Rebuild, and perhaps some time for any caches to clear.
You can also delete “cache/themes” directory, it will get recreated.
Thanks pgr. I took a look at the error logs and found the following:
Permission denied:
/home/******/themes/SuiteP/css/suitep-base/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable and that /home/******/themes/SuiteP/css/suitep-base/’ is executable
So I set /themes/SuiteP/css/suitep-base/ to 775. Please note this is not the cache.
It works now…
After seeing that I tried x2CRM. Just another bucket of problems and far less forum support. Threads just die without any answers. I can’t even login after the initial install. It 500’s all over itself.
… that said …
It’s been one week into using suiteCRM. While there are a TON of issues with this program, for open source, it seems to be the best option. In short, don’t get your hopes up for something better because another CRM was mentioned.
About six months ago I abandoned SuiteCRM after 15 combined years with it and Sugar. I moved everything over the free/open-source EspoCRM https://www.espocrm.com/ and have been happy with it. It is like Suite but with a newer codebase that is way less ‘broken.’ It is not quite as featured, but I just need basic CRM functionality and Espo has all that I need for my business.
Nice … I’ll check that one out too! Thanks!