Storefront Registry cache keeps an active add-on disabled until the file cache is manually removed

Bug tracker
,
1

Hello,

I found a possible storefront Registry cache invalidation issue related to
add-on status.

Environment

Edition: CS-Cart Ultimate
Version: [Multi-Vendorv4.20.1]
PHP: 8.2
Cache backend: file
Web server: Nginx

Affected add-on

Required Products

Observed behavior

The Required Products add-on was active in the database and in the
administration panel:

cscart_addons.addon = required_products
cscart_addons.status = A

However, in the customer area, after CS-Cart initialization, the runtime
values were:

ADDON_STATUS=‘D’
FUNC_EXISTS=N
ADDONS_INITIATED=true
INIT_ADDONS=‘’
SNAPSHOT_OK=Y
INIT_DISABLED=N

The add-on’s init.php file was loaded in the administration area, but it was
not loaded in the customer area.

As a result, the pre_add_to_cart hook was not registered in the storefront,
and required products were not automatically added to the cart.

Troubleshooting performed

  1. Confirmed that the add-on status in cscart_addons was A.
  2. Confirmed that fn_check_addon_snapshot(‘required_products’) returned true.
  3. Confirmed that fn_is_addon_init_disabled(‘required_products’) returned false.
  4. Restarted PHP-FPM.
  5. Cleared the cache through the administration URL using ?cc&ctpl.

The problem remained after these steps.

Resolution

The application was using the file cache backend.

I moved the existing cache directory:

var/cache

and created a new empty cache directory with the correct www-data ownership.

After the cache was rebuilt, the storefront runtime values became:

ADDON_STATUS=‘A’
FUNC_EXISTS=Y
ADDONS_INITIATED=true
SNAPSHOT_OK=Y
INIT_DISABLED=N

The Required Products add-on then loaded correctly in the customer area, and
the main product and its required product were both added to the cart.

Expected behavior

When an add-on is enabled, disabled, or its status changes, all Registry cache
variants that contain the add-on status should be invalidated, including
static, storefront, and company-level cache variants.

The administration cache-clear operation should also clear any stale
storefront add-on status cache.

Actual behavior

The database and administration area reported the add-on as active, while the
storefront Registry continued to use a cached disabled status.

Could you please check whether add-on status changes correctly invalidate all
storefront-specific Registry cache entries?

Best regards,
Emre

2

Hello

fn_rm() deletes with @unlink(), aborts on the first failure and reports nothing, so the panel says “cache cleared” even when nothing was removed. That happens when cache files belong to another user than php-fmp, usually cron or CLI run as root.

To avoid this class of issue entirely, move the cache off the filesystem in config.local.php (requires redis):

$config[‘cache_backend’] = ‘redis’;
$config[‘cache_redis_server’] = ‘localhost’;

Have a nice day

Best regards
Robert