Module Builder Not Saving Fields

bchow · 5 August 2015 17:11

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

jansiero · 8 August 2015 16:57

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;

bchow · 10 August 2015 19:44

This solved my problem. Thank you for the patch!

tristangemus · 13 August 2015 12:25

Thanks,

This did the trick.

Hector_Bulgarini · 31 August 2015 01:49

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

jansiero · 31 August 2015 03:18

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.

Hector_Bulgarini · 31 August 2015 04:18

Great ! I see… well i need get involved more with the code! I’m glad to help

Cheers,

rmint · 28 June 2021 06:06

Thanks for the fix @jansiero ! It´s 2021 and apparently this still hasn´t been implemented/fixed by default…

p.konetskiy · 28 June 2021 08:20

@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.

rmint · 28 June 2021 08:36

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.

p.konetskiy · 28 June 2021 08:42

@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.

jansiero · 28 June 2021 10:01

Hi @rmint,

This has been fixed since 7.11.19 / 7.10.30

What version are you on?

rmint · 28 June 2021 10:18

@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…

jansiero · 28 June 2021 10:21

Hi @rmint,

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

p.konetskiy · 28 June 2021 10:31

@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.

jansiero · 28 June 2021 10:32

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

p.konetskiy · 28 June 2021 11:02

@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)

jansiero · 28 June 2021 12:30

@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.

p.konetskiy · 28 June 2021 14:48

@jansiero

I wrote the file for exmple only. I saw the problem for the fields too but it wasn’t so critical for me. Perhapts you fixed it for fields but for relationships this is present yet.

Look at my method buildNewRelationship in file: custom/modules/DynamicFields/ConfigCollection.php
and analyze system

method load in file:
modules/ModuleBuilder/parsers/relationships/DeployedRelationships.php
method install_relationships in file:
ModuleInstall/ModuleInstaller.php

The problem in next situation.

SuiteCRM read the file for analyze current relationships.
When the new relationship build the file is rebuilded from files of directiory (custom/Extension/application/Ext/TableDictionary).
The last step is creaing new table in database but the file has been loaded into the memory alrady and after that the new table is’t created.

jansiero · 15 July 2021 16:52

Hi @rmint,

I checked the upgrade packages to version 7.11.20: the required changes are in there, so a fresh install won’t help you.

I’m puzzled why this issue still emerges on your installation with version 7.11.20.

Can you confirm again that when you disable opcache on SuiteCRM 7.11.20 the saving fields problem is solved and when you enable it, the saving fields problem emerges again?

Can you also give the specs of your PHP version? (output of phpinfo() would be helpful)