Hi everyone, I’ll try to provide a clear explanation of the problem we’re facing. We’re making large changes across different client applications, all within Studio. The two main issues we’re encountering are: Changing field labels. Modifying record layouts in a module. I suspect the problem is related to caching, and I imagine the solution involves adjusting the cache configuration. For example: We change a field label and save it. The change is saved. Then, we change another label in the same module, and at some point, we lose the changes to labels we had previously saved. We have to rename the field again, only to find that another label disappears. Another issue is with module record layouts. If we make changes, save, and deploy, the changes don’t appear on the current screen—even though they are actually saved. However, if we make changes gradually, we lose some of them. To avoid this, we have to make all changes at once, then refresh or check the actual module record view. The most frustrating part is the field labels, as we often have to rename them multiple times before the changes stick. Since we’re dealing with multiple applications and fields, this slows us down significantly. Any help or suggestions would be greatly appreciated. Best regards,

Losing changes when done in Studio

Hi everyone,

I’ll try to provide a clear explanation of the problem we’re facing.

We’re making large changes across different client applications, all within Studio. The two main issues we’re encountering are:

Changing field labels.
Modifying record layouts in a module.

I suspect the problem is related to caching, and I imagine the solution involves adjusting the cache configuration.

For example:

We change a field label and save it. The change is saved. Then, we change another label in the same module, and at some point, we lose the changes to labels we had previously saved. We have to rename the field again, only to find that another label disappears.
Another issue is with module record layouts. If we make changes, save, and deploy, the changes don’t appear on the current screen—even though they are actually saved. However, if we make changes gradually, we lose some of them. To avoid this, we have to make all changes at once, then refresh or check the actual module record view.

The most frustrating part is the field labels, as we often have to rename them multiple times before the changes stick. Since we’re dealing with multiple applications and fields, this slows us down significantly.

Any help or suggestions would be greatly appreciated.

Best regards,

Parents

0 Frédéric Rinaldi 15 days ago

Hi Raul Bethencourt Gonzalez ,

can you check your OPCACHE settings in your PHP.ini ; we got this issue on several instances and it was solve after change the settings to

opcache.revalidate_freq=0
Cancel
Vote Up +2 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Francesca Shiekh 15 days ago in reply to Frédéric Rinaldi

Thank you for this.Frédéric Rinaldi , I will try this myself, I hope it will help with my Studio changes appearing to be "undone" when they are not.

In my case I save a layout change, for example, and it goes right back to displaying what it was before the change. If I reload Studio, however, it shows correctly.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Raul Bethencourt Gonzalez 12 days ago in reply to Francesca Shiekh

Hello,Francesca.

We have same problem and Frédéric tips helps with this also.
Cancel
Vote Up +1 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Angel Magana 5 days ago in reply to Raul Bethencourt Gonzalez

Yes, that makes sense, as the revalidate setting determines how often the file in the cache will be compared to the file on the disk. You would typically not want this to be set too high as it creates situations such as those which you describe, unless the instance files are rather static.

I am mostly jumping in on this thread to also make folks aware of another scenario that may cause this same behavior.

Suppose I have multiple web servers, Web 1 and Web 2, hosting my instance and each with its own copy of the application files on its local disk. Changes made in Studio would be written to the local disk of the web server that happened to receive my request (e.g. Web 1) and the next time I access Sugar, I may be accessing it via a different web server (Web 2), creating this discrepancy. This is why you'll notice that we advice on centralizing application files on NFS volumes whenever we discuss topologies that utilize multiple web servers.
Cancel
Vote Up +1 Vote Down

Sign in to reply

Verify Answer

Cancel

Reply

0 Angel Magana 5 days ago in reply to Raul Bethencourt Gonzalez

Yes, that makes sense, as the revalidate setting determines how often the file in the cache will be compared to the file on the disk. You would typically not want this to be set too high as it creates situations such as those which you describe, unless the instance files are rather static.

I am mostly jumping in on this thread to also make folks aware of another scenario that may cause this same behavior.

Suppose I have multiple web servers, Web 1 and Web 2, hosting my instance and each with its own copy of the application files on its local disk. Changes made in Studio would be written to the local disk of the web server that happened to receive my request (e.g. Web 1) and the next time I access Sugar, I may be accessing it via a different web server (Web 2), creating this discrepancy. This is why you'll notice that we advice on centralizing application files on NFS volumes whenever we discuss topologies that utilize multiple web servers.
Cancel
Vote Up +1 Vote Down

Sign in to reply

Verify Answer

Cancel

Children

No Data