Studio Layout changes not saving

When I alter the layout in Studio, save and deploy indicates the save has been made. clicking back into the same layout I have changed shows the change did not take place.

Confirmed with user view… changes not saved.

SuiteCRM 7.9.7
CentOS 7
Apache
PHP 7.0w
MySQL

persmission
/var/www/html/
drwxr-xr-x. 17 apache apache 4096 Nov 13 07:53 .
drwxr-xr-x. 4 root root 33 Nov 10 07:37 …
drwxrwxr-x. 15 apache apache 199 Nov 13 07:54 cache
-rwxr-xr-x. 1 apache apache 3590 Oct 18 10:12 campaign_tracker.php
-rwxr-xr-x. 1 apache apache 3094 Oct 18 10:12 CODE_OF_CONDUCT.md
-rwxr-xr-x. 1 apache apache 462 Oct 18 10:12 composer.json
-rwxr-xr-x. 1 apache apache 17908 Oct 18 10:12 composer.lock
-rwxrwxr-x. 1 apache apache 641 Nov 14 00:48 config_override.php
-rwxr-xr-x. 1 apache apache 10604 Nov 14 01:49 config.php
-rwxr-xr-x. 1 apache apache 5052 Oct 18 10:12 cron.php
-rwxr-xr-x. 1 apache apache 2446 Oct 18 10:12 crossdomain.xml
drwxrwxr-x. 10 apache apache 150 Nov 14 00:43 custom
drwxrwxr-x. 3 apache apache 104 Oct 18 10:12 data
-rwxr-xr-x. 1 apache apache 2388 Oct 18 10:12 dictionary.php
-rwxr-xr-x. 1 apache apache 12541 Oct 18 10:12 download.php
-rwxr-xr-x. 1 apache apache 2392 Oct 18 10:12 emailmandelivery.php
-rwxr-xr-x. 1 apache apache 4912 Oct 18 10:12 export.php
-rwxr-xr-x. 1 apache apache 967627 Oct 18 10:12 files.md5
-rwxr-xr-x. 1 apache apache 2811 Oct 18 10:12 HandleAjaxCall.php
-rwxr-xr-x. 1 apache apache 1683 Nov 14 01:12 .htaccess
-rwxr-xr-x. 1 apache apache 2367 Oct 18 10:12 ical_server.php
drwxr-xr-x. 58 apache apache 4096 Oct 18 10:12 include
-rwxr-xr-x. 1 apache apache 2374 Oct 18 10:12 index.php
drwxr-xr-x. 6 apache apache 4096 Nov 13 07:52 install
-rwxr-xr-x. 1 apache apache 30501 Nov 13 07:53 install.log
-rwxr-xr-x. 1 apache apache 31896 Oct 18 10:12 install.php
-rwxr-xr-x. 1 apache apache 2275 Oct 18 10:12 json_server.php
drwxr-xr-x. 3 apache apache 125 Oct 18 10:12 jssource
-rwxr-xr-x. 1 apache apache 34539 Oct 18 10:12 LICENSE.txt
-rwxr-xr-x. 1 apache apache 2313 Oct 18 10:12 log_file_restricted.html
-rwxr-xr-x. 1 apache apache 2376 Oct 18 10:12 maintenance.php
drwxr-xr-x. 2 apache apache 4096 Oct 18 10:12 metadata
drwxr-xr-x. 3 apache apache 102 Oct 18 10:12 ModuleInstall
drwxrwxr-x. 112 apache apache 4096 Oct 18 10:12 modules
-rwxr-xr-x. 1 apache apache 2890 Oct 18 10:12 pdf.php
-rwxr-xr-x. 1 apache apache 304 Oct 18 10:12 php_version.php
-rwxr-xr-x. 1 apache apache 3735 Oct 18 10:12 README.md
-rwxr-xr-x. 1 apache apache 73 Oct 18 10:12 robots.txt
-rwxr-xr-x. 1 apache apache 3588 Oct 18 10:12 run_job.php
drwxr-xr-x. 12 apache apache 133 Oct 18 10:12 service
drwxr-xr-x. 2 apache apache 4096 Oct 18 10:12 soap
-rwxr-xr-x. 1 apache apache 4091 Oct 18 10:12 soap.php
-rwxr-xr-x. 1 apache apache 125471 Nov 13 07:53 sugarcrm.log
-rwxr-xr-x. 1 apache apache 5327 Oct 18 10:12 SugarSecurity.php
-rwxr-xr-x. 1 apache apache 154 Oct 18 10:12 sugar_version.json
-rwxr-xr-x. 1 apache apache 2296 Oct 18 10:12 sugar_version.php
-rwxr-xr-x. 1 apache apache 529787 Nov 14 01:57 suitecrm.log
-rwxr-xr-x. 1 apache apache 169 Oct 18 11:41 suitecrm_version.php
drwxrwxr-x. 6 apache apache 63 Oct 18 10:12 themes
-rwxr-xr-x. 1 apache apache 5843 Oct 18 10:12 TreeData.php
drwxrwxr-x. 3 apache apache 220 Nov 14 01:12 upload
-rwxr-xr-x. 1 apache apache 2248 Oct 18 10:12 vcal_server.php
-rwxr-xr-x. 1 apache apache 2980 Oct 18 10:12 vCard.php
drwxr-xr-x. 2 apache apache 37 Oct 18 10:12 XTemplate
drwxr-xr-x. 8 apache apache 228 Oct 18 10:12 Zend

Do you see any relevant errors in your logs at the time of the save and deploy?

Hi,

there was an issue with the opcache cache module for PHP, which might still cause these issues. Could you check your php file which you might find here (linux):

/usr/local/etc/php.ini

and look for this?


[opcache]
; Determines if Zend OPCache is enabled
;opcache.enable=1

Modify to


[opcache]
; Determines if Zend OPCache is enabled
opcache.enable=0

(make sure to remove the semicolon before “opcache”)

afterwards restart your webserver / php-fpm and please report if this has been resolved.

Looking through my log file shows no fatal errors, will turn up the logging level and see.

I did have a permission problem with the /cache/theme/SuiteP/modules directory (the -R must have missed it for some reason)
Also no time zone setting in php.ini.

config.php has the correct user group for

Changing menu filters is fine, just not the studio.

I did notice looking just now that the /cache/theme/SuiteP/modules dir has permission issues.

I’m not sure why this reverst back to drwxrwx—
in any event it does not fix the issue. I still can’t save studio changes

as for opcache in my php.ini. it does not exist as an option.

Hi, just to make sure, could you check if the following file exists on your system?

/etc/php.d/opcache.ini

Alternatively could you create a php file phpinfo.php with the following contents:

<?php
phpinfo();
?>

Open the phpinfo.php in a browser and see if opcache is anywhere on this info page?

no ini file exists

@djcomber you can have a look at this post for some commands to scan your entire directory tree for problems:

https://suitecrm.com/forum/suitecrm-7-0-discussion/15171-how-know-if-permission-issue#51172

Your permissions can degrade for several reasons, namely that some SuiteCRM functions actually set permissions differently, or because you can be missing the proper SetGID and SetUID bits oni some directories (that control how new files and new subdirectories are created). You can also have .htaccess files messing things up.

However, you shouldn’t even assume that you have permissions issues just because you see a directory with “drwxrwx—”. If your web server owns that file, the only bits that will apply are the first three “rwx”. The others will be ignored.

Permissions are only meaningful as a cross between 3 things: permissions set on the file, ownsership set on the file, user trying to access.

no issues found using tree all files and folders in /var/www/html owned by apache

cgi-bin is owned by root? not sure if that is a problem. haven’t seen cgi-bin mentioned in any forum post.

You can check two more things:

  1. If your web server is indeed running as “apache” user: see Admin / Schedulers, the text at the bottom instructing how to set up cron jobs, it should read something like
crontab -e -u apache
  1. Make sure you followed that instruction precisely, and your cron jobs are running as “apache” also. If they are running as root, they will cause permissions degradation.

https://pgorod.github.io/Scheduler-Jobs/