Promokit Helpdesk Alysum

Hi Promokit / WebshopWorks team,

I’m reporting a reproducible multilingual bug in the Creative Elements
[in-stock] 2.5.0 build that ships with Alysum 9.2.4, and asking whether
the fix can be shipped in the in-stock build bundled with the theme (or
confirming the Premium upgrade path).

Environment

- PrestaShop 9.0.2, multilingual (LT default + EN)
- Alysum 9.2.4 (config/theme.yml)
- Creative Elements [in-stock] 2.5.0
(modules/creativeelements/config.xml)
- Friendly URLs: ON; PS_DEFAULT_LANGUAGE_URL_PREFIX = 1; Smarty cache:
ON

Problem

On valid pages (home, CMS pages, e.g. /lt/content/6-apie-mus), the
header Language Selector intermittently renders links pointing to the
404 page instead of the translated URL:

expected: https://nunu.lt/en/content/6-about-us actual: https://nunu.lt/en/Puslapis-nerastas ← 404 page (”Page not
found”)

It happens on every page that shares the colliding cache key, and
clearing the cache fixes it only until the next 404 request re-poisons
it.

Steps to reproduce

1. Clear the CE/Smarty cache.
2. Visit a non-existent URL (any 404), e.g.
https://nunu.lt/lt/nonexistent-page.
3. Visit a valid CMS page or the homepage and inspect the Language
Selector href — it now points to …/<lang>/Puslapis-nerastas.

Root cause

The element render cache key does not include the current controller:

modules/creativeelements/includes/base/element-base.php (~line 707):
$categoryId = Tools::getValue(’id_category’, 0);
$productId = Tools::getValue(’id_product’, 0);
$cache_id = Cache::getCacheId([$this→getId(), $productId,
$categoryId]);
pklib Cache::getCacheId() adds customer/currency/language/shop but not
the controller.

As a result, index, CMS pages, and pagenotfound (all product=0,
category=0) collide on the same cache entry for the Language Selector
widget. A 404 request renders the selector with controller =
pagenotfound, so {url entity=’language’} bakes …/<lang>/<404-slug> into
the shared entry (TTL = 1 week). Every valid page that shares the key
then serves the poisoned link.

This is the same class of issue tracked upstream as PrestaShop #17111
(getCacheId() does not use all variables that affect output).

Evidence (production)

A poisoned cache artifact was captured on the production server:
file: promokit-7fad2e5bafd115bd1098bbd4ac924af3.ce
contents: [timestamp, … href=”https://nunu.lt/en/Puslapis-nerastas” …]

This was already fixed in CE

The language-selector 404 case appears to be addressed in CE 2.5.8:

▎ “v2.5.8 (2022-01-21): Fixed — Language Selector redirects to error 404
▎ on home page when URL rewrite isn’t empty”

and the cache architecture was properly redesigned in CE 2.11.0 (2024,
“Element Cache”, opt-in, with per-element keys), with further cache
fixes in 2.11.1 / 2.13.0 / 2.14.0.

References:
- CE changelog (2.5.8 + 2.11.0 redesign): https://docs.webshopworks.com/ creative-elements/74-first-steps/338-changelog
- CE 2.13 / PrestaShop 9 release notes:
https://pagebuilder.webshopworks.com/news/creative-elements-213-prestash op-9-support-new-page-builders-and-more
- PrestaShop issue #17111 (cache id omits output-affecting vars):
https://github.com/PrestaShop/PrestaShop/issues/17111

Request

The in-stock build bundled with Alysum is frozen at 2.5.0 (its own
upgrade scripts cap at 2.5.5, below the 2.5.8 fix), so updating the
theme alone does not resolve it. Could you please:

1. Ship the fix in the in-stock build bundled with Alysum — either
include the controller in getCacheId(), or exclude the Language Selector
widget from the element cache; or
2. Provide a patched in-stock build (≥ 2.5.8) for current Alysum 9.x
users; or
3. Confirm that upgrading to Premium CE 2.14.0 is compatible with
Alysum’s pkelements / pkthemesettings widget layer, so we can take that
path safely.

Happy to provide server access, additional cache dumps, or run any
reproduction you need.

Thank you,
Alex