Module Builder Not Saving Fields

šŸ’¬ General Discussion
1

Hello,

I have a clean installation of SuiteCRM on my vagrant virtual machine.

When I save a field in the module builder, I am redirected back to the field list and my field is not added.

Iā€™ve installed this many times, and had zero issues.

Any suggestions?

Thanks!

Tristan.

2

Set your file permissions of the SuiteCRM directory to the user of web server eg. www-data, httpd etcā€¦ Make sure you set the permissions so that SuiteCRM has write access. Sometimes this is caused by the permissions set in the config.php file:

'default_permissions' => 
  array (
    'dir_mode' => 1517,
    'file_mode' => 420,
    'user' => 'www-data',
    'group' => 'www-data',
  ),

so if youā€™re using different permissions on your instance you can change how SuiteCRM sets permissions.

3

Iā€™m having the exact same problem. My permissions are set as suggested, my php error report is: error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT. This is on Ubuntu 14.04 w/ php5.5

4

Hi,

the problem is not permission related but has to do with the Zend op-cache.

When saving a field, SuiteCRM saves the vardef info to file en then rereads this PHP data. The Zend op-cache however supplies the cached version of the file instead of the newly written version.

See this PHP bug:
https://bugs.php.net/bug.php?id=65559
And especially the last comment on this page.

I fixed this issue with this commit:
https://github.com/JanSiero/SuiteCRM/commit/8833fae04cf9cc7fd2de9718446d56dba82bce77

You can fix this by pulling the diff from github or by editing the file:

include/utils/file_utils.php

around line 133 (function write_array_to_file) replace


    return sugar_file_put_contents($the_file, $the_string, LOCK_EX) !== false;

with


    $result = sugar_file_put_contents($the_file, $the_string, LOCK_EX) !== false;

    if (function_exists('opcache_invalidate')) {
        opcache_invalidate($the_file, true);
    }

    return $result;
3 Likes
5

This solved my problem. Thank you for the patch!

6

Thanks,

This did the trick.

7

Hey guys, one question regarding this topic:

I see that this workaround solves the issue very nice on the module builder, but not on the studio for the modules already deployed on the system. Relations and fields management works really unstable on the studio actually.
I donā€™t know the code yet but doing a little research i found that there is a similar file to the file_utils.php which is called sugar_file_utils.php.
I saw on this file that there is the same function called sugar_file_put_contents, my question is if we should apply the same workaround on this file too.

I was wondering to apply something like that on the file_utils.php ( again, i donā€™t know the code yet and this come from the common sense ). By the way the sugar_file_utils.php is required_once on the file_utils.php , but anyway iā€™m suspecting that for the studio the application might call directly the sugar_file_utils.php instead of the file_utils.php.

What do you think?

Hope it helps

Cheers

8

Hi, youā€™re absolutely right that this issue manifests itself in more places, like

  • editing dropdowns
  • editing layouts
  • installing modules (SQL not executed)

Adding the fix the the method you proposed would alleviate some of these issues. However, from an architecture viewpoint, the fix should be implemented in SugarCache::cleanFile (include/SugarCache/SugarCache.php), where there is already a fix for APC caching.

SugarCache however should not be called in file_utils.php, because thatā€™s too low level, instead it should be called in those classes that write vardef data (and subsequently call ā€œwrite_array_to_fileā€ or ā€œsugar_file_put_contentsā€ )

I havenā€™t got to this yet.

9

Great ! I seeā€¦ well i need get involved more with the code! Iā€™m glad to help

Cheers,

10

Thanks for the fix @jansiero ! ItĀ“s 2021 and apparently this still hasnĀ“t been implemented/fixed by defaultā€¦ :thinking:

11

@rmint

As a variant you can switch off cache for PHP.
Set opcache.enable=0 in php.ini
I hope that it will help you.

12

Thanks for your reply ā€“ I realized that the issue would probably persist throughout other modules, so IĀ“ve turned off the cache. ItĀ“s a shame though, as the cache does improve performance.

13

@rmint

The problem present in some functions of ModuleBuilder and Studio only. You can switch off it on test server and switch on on production server.

14

Hi @rmint,

This has been fixed since 7.11.19 / 7.10.30

What version are you on?

15

@jansiero : ThatĀ“s weired, as my version is 7.11.20ā€¦I might have updated though, so maybe it wasnĀ“t included there? As this is a development instance only, I could try a fresh installā€¦

16

Hi @rmint,

Update should definitely have fixed this issue. Can you describe the exact steps to reproduce?

17

@jansiero and @rmint

The upgrade can not fixed this issue because there is main problem in file structure of SuiteCRM has . Some files is reading several times for one script cycle.

1 Like
18

@p.konetskiy can you give an example of this file structure issue?

19

@jansiero
Please. One of place is the file: custom/application/Ext/TableDictionary/tabledictionary.ext.php
I discovered that when I was making the decision: (Solution for support three new fields types in Studio)

20

@p.konetskiy, the tabledictionary contains references to metadata which describe relations between modules. This tabledirectory should not affect normal fields (maybe however relate fields) as this field information are not saved in the tabledictionary.

The extra database repair and rebuild that you included in your module post_install.php should not be necessary anymore in 7.11.19 / 7.10.30 and later, but Iā€™ll try it out to make sure.