ModuleBuilder overriding application language files

Hi,

We are experiencing some issues with ModuleBuilder module regarding the creation of new modules and the application label files. We are wondering if it’s related with our server configuration but we can’t get reproduce a clear scenario. I explain:

Following these steps:

  • Go to ModuleBuilder in Administration.
  • Create a new package named a with key a.
  • Create a new module named b.
  • Check the label $app_list_strings['moduleList']['a_b'] = 'b'; in file custom/modulebuilder/packages/a/language/application/en_us.lang.php . The label is there as expected.
  • Create a new module named c.
  • Check the label $app_list_strings['moduleList']['a_b'] = 'b'; The label isn’t there anymore and it only appears the new label $app_list_strings['moduleList']['a_c'] = 'c';.

I’m guessing this is related with some php configuration, but not sure.

Can you reproduce this? Any advice?

Testing in 7.12.6 with PHP 7.4

Thanks

I don’t use Module Builder, but I’ve heard there is classical limitation in it - you can’t re-deploy, I believe. But maybe I am getting this wrong… try to find something online about this known issue.

Thanks for your reply.

A few more data:

  • All happens inside ModuleBuilder, just before deploying, publishing or exporting the package.
  • We detected it after updating from 7.11.20 to 7.12.4.
  • Disabling Opcache solves the issue (just tested it).
    Here is Opcache current configuration:
|Directive|Local Value|Master Value|
|---|---|---|
|opcache.blacklist_filename|no value|no value|
|opcache.consistency_checks|0|0|
|opcache.dups_fix|Off|Off|
|opcache.enable|On|On|
|opcache.enable_cli|On|On|
|opcache.enable_file_override|Off|Off|
|opcache.error_log|no value|no value|
|opcache.file_cache|no value|no value|
|opcache.file_cache_consistency_checks|On|On|
|opcache.file_cache_only|Off|Off|
|opcache.file_update_protection|2|2|
|opcache.force_restart_timeout|180|180|
|opcache.huge_code_pages|Off|Off|
|opcache.interned_strings_buffer|4|4|
|opcache.lockfile_path|/tmp|/tmp|
|opcache.log_verbosity_level|1|1|
|opcache.max_accelerated_files|2500|2500|
|opcache.max_file_size|0|0|
|opcache.max_wasted_percentage|5|5|
|opcache.memory_consumption|128|128|
|opcache.opt_debug_level|0|0|
|opcache.optimization_level|0x7FFEBFFF|0x7FFEBFFF|
|opcache.preferred_memory_model|no value|no value|
|opcache.preload|no value|no value|
|opcache.preload_user|no value|no value|
|opcache.protect_memory|Off|Off|
|opcache.restrict_api|no value|no value|
|opcache.revalidate_freq|2|2|
|opcache.revalidate_path|Off|Off|
|opcache.save_comments|On|On|
|opcache.use_cwd|On|On|
|opcache.validate_permission|Off|Off|
|opcache.validate_root|Off|Off|
|opcache.validate_timestamps|On|On|

Is there any parameter it might affect in caching/overriding files?
Cheers

Ah. That is interesting, and much more certain than my vague answer.

An interesting test would be to flush the opcache at the right moment, and determine if that is enough to fix the problem.

There are several “reloads” and “refreshes” and “cache clearings” happening when stuff gets deployed in Studio and MB and in the QR&R. Maybe we just need to add one saying “if using opcache, flush it now”…

I tried inserting opcache_reset(); just before and after writing to the file.

Also before including it’s content:

But no luck.

If anyone else can reproduce this, it will help to understand it is a general problem. Then we can open an Issue in the repo.

Thanks!

1 Like