Version 7.3
Hello,
I have been trying to make changes to the Layouts in Studio, but whenever I make a change (remove a field for example) and click Save or Save and Deploy, the layout in Studio editor instantly reverts back to what it was before I removed the field.
Other non layout related Studio functions seems to be working, For example I have successfully added new fields.
Any idea what I am doing wrong? Driving me a bit crazy…
Thanks
D
Hi,
This issue is known and is logged on our Github: #380
Studio issues are currently being worked through and logged as they are found.
Hi John,
Thank you for the update, but my issues seem to be more widespread then those referenced in the bug and are not solved with a “double” save and deploy as mentioned in the Github link
I have tested further and cannot seem to Save ANY changes I make using Studio. For example
If I attempt to change a layout, remove a field for example, and click Save or Save and Deploy the layout in studio instantly reverts back to its original
If I attempt to add a Field, and click Save, my new field is not in the list.
If I attempt to add a new Field and select Multi Select and Add a new multi-Select criteria list an click save. My criteria I just defined is NOT in the list of available
If I later go into Admin then Repair and Quick Repair and rebuild. The changes miraculously appear in studio now ?? This seems to be a VERY cumbersome workaround to my issue, having to go Repair and Rebuild for every change, but it does not solve all issues. For example if still cannot seem to add a new mutli select options
Any idea what is going on?
D
Hi,
It seems as though they all are Studio Issues, I think most of these are logged in our Github’s Issues and being worked through, but if you feel any are missing then please log them so we can check them out. For now, it may be worth checking that your permissions are correct:
What are the settings of the host of your SuiteCRM instance? Is it Windows or Linux based?
If you go into your config.php file, you can find a section that contains:
'default_permissions' =>
array (
'dir_mode' => '',
'file_mode' => '',
'user' => '',
'group' => '',
),What settings do you have for these?
Hi,
Linux
contains:‘default_permissions’ =>
array (
‘dir_mode’ => ‘1528’,
‘file_mode’ => ‘432’,
‘user’ => ‘’,
‘group’ => ‘’,
),
One thing I did not mention is we installed suiteCRM from Bitnami could there be an issue with their installation?
Thanks again for your help
Bitnami installation sometimes will set the wrong permissions,
Please enter the following:
‘dir_mode’ => 1517,
‘file_mode’=>420,
And in;
‘user’=>’ ’
‘group’=>’ ’
Enter your SuiteCRM instance’s Owner and group user, If you are unsure of what these may be, it may differ depending on your Linux distribution, but usually www-data or apache will work
Also, what are your permissions for the SuiteCRM Instance itself?
Arghh… Same outcome . nothing saving after changes…
Settings are now:
array (
‘dir_mode’ => ‘1517’,
‘file_mode’ => ‘420’,
‘user’ => ‘daemon’,
‘group’ => ‘daemon’,
),
And the rights to the folders are daemon/daemon
The apache process is run as daemon/daemon
Can you clarify “what are your permissions for the SuiteCRM Instance itself?”
D
Hi,
I meant in regards to the folders/files for the SuiteCRM instance,
We usually recommend something like :
Using terminal, cd into your SuiteCRM directory and do the following chmod commands:
sudo chmod -R 755 .
sudo chmod -R 775 cache custom modules themes data upload config_override.php
If it still doesn’t work, you could check your suitecrm.log and sugarcrm.log files.
Our permissions are set as suggested. Same result
Considering paying someone with knowledge to do a clean install and get this working properly. Any idea who can do this for a fee?
Thanks for all your help
D
Hi,
You can find information on how to install the CRM here: https://suitecrm.com/wiki/index.php/Installation
Something to note, you should set your permissions before beginning the install and then Set them again afterwards.
Also, once installation is complete, i would recommend doing a Quick Repair/Rebuild straight away, and to execute any changes if prompted.
Thankyou…
But I was mostly asking if anyone is aware of any individuals or companies we could pay to do the install for us…
D
Hello dp168,
as John has already mentioned these are the series of related issues which are referenced through github.
https://github.com/salesagility/SuiteCRM/issues/380 - layout changes are not displayed after save and deploy
https://github.com/salesagility/SuiteCRM/issues/383 - fields form keeps disappearing, but when it is fixed in the same place with themes/SuiteR/css/style.css -> line 4351 -> add: #toolbox {overflow: auto;} -> QR&R, then fields form changes are not displayed after save and deploy
These issues do not manifest themselves all the time. Sometimes it is possible to add a new item to layout, then click save and deploy and the changes will be visible. The same is for the fields - sometimes it is possible to add a new field, then click on save and deploy and the changes will be visible.
I found that if the changes are displayed correctly, and you go and do QR&R, the changes are not displayed anymore (this can last for a couple of hours).
The code which sits in the function action_popupSave():
if(empty($packageName)){
include_once (‘modules/Administration/QuickRepairAndRebuild.php’) ;
global $mod_strings;
$mod_strings[‘LBL_ALL_MODULES’] = ‘all_modules’;
$repair = new RepairAndClear();
$repair->show_output = false;
$class_name = $GLOBALS [ ‘beanList’ ] [ $_REQUEST [ ‘view_module’ ] ] ;
$repair->module_list = array($class_name);
$repair->clearTpls();
}
takes about 30 secs to execute on my machine and by this time the screen has already been refreshed with some old data instead of the new data that you’ve just added.
I proposed a fix for layout here: https://github.com/vladbar/SuiteCRM/commit/ce9624c8c03c6faab4f427b9f1ae520ba94163f8
and another fix for fields here: https://github.com/vladbar/SuiteCRM/commit/c511ca5a37e5f2bde77ddeea23c3a4f89368b166
Basically in both cases I created a new array view_object_map[], which is the main way for the controller to communicate with the view and then passed an updated parser inside of this array. Therefore changes to the layout and field form happen immediately.
Please also note that in case of the 380 fix I commented out these lines:
// /*
// * Pseudo-constructor to enable subclasses to call a parent’s constructor without knowing the parent in PHP4
// */
// function init()
// {
//
// }
as they did nothing, apart from disrupting creation of a view with the correct view_object_map[] array. Now view.popupview.php gets its init() function from its parent.
Please, let us know if the proposed fix is of any help to you.
I’m still getting this problem in 7.9.11. I have checked permissions and all is fine there. It certainly used to work - but I can’t recall which version upgrade introduced the problem. Is there any recent updates/fixes to this one that people can point to to?