In 2.2.10 Helper::sanitizeMegaMenuBadge() gained HTML encoding:

// 2.2.10 - plugins/system/helixultimate/src/Platform/Helper.php:1275-1278
public static function sanitizeMegaMenuBadge($value): string
{
    return htmlspecialchars(trim(strip_tags((string) $value)), ENT_QUOTES, 'UTF-8');
}

// 2.2.8 - same method, no encoding
public static function sanitizeMegaMenuBadge($value): string
{
    return trim(strip_tags((string) $value));
}

The problem is that the method is called on both ends of the round trip:

• on save: Helper.php:1207 - $clean['badge'] = self::sanitizeMegaMenuBadge($settings['badge'] ?? ''); (inside the mega menu settings sanitiser, so the encoded value is what gets stored in the menu item params)
• on render: src/Core/Classes/HelixultimateMenu.php:737 - $badgeText = Helper::sanitizeMegaMenuBadge($layout->badge);

So a badge typed as New & hot is stored as New & hot and then rendered as New & hot, which the browser shows to the visitor as the literal text New & hot. The same applies to <, >, " and '.

In 2.2.8 this did not happen, because the stored value was raw and the encoding happened only where the HTML was assembled.

We expect - but did not measure, because we do not use badges - that each further save of the same menu item encodes the already encoded value again (&), since the settings form round-trips the stored value.

Might help:

• keep sanitizeMegaMenuBadge() as the storage sanitiser (trim(strip_tags(...))) and escape at the render site in HelixultimateMenu.php:737, or
• keep the encoding inside the method and stop calling it again on already-sanitised stored data at render time.

A migration note may be needed for sites that saved a badge under 2.2.10, since their stored values are already encoded.

We diffed the clean 2.2.8 package against the installed 2.2.10 tree, then followed both call sites. On our site nothing is visible: a check of every site menu item shows no non-empty badge value, so we could not produce a browser screenshot.

Unrelated but..., same file: getTemplateId() builds invalid SQL

plugins/system/helixultimate/src/Platform/Helper.php:73-93 - the multilanguage branch never closes the IN( list:

if (Multilanguage::isEnabled()) {
    $query->where($db->quoteName('home') . ' IN(' . $db->quote(Factory::getLanguage()->getTag()) . ', ' . $db->quote('1', false));
}

On a multilingual site this produces ... AND home IN('sr-latn-rs', '1' which MySQL rejects; we ran both forms against our database: the unclosed one returns ERROR 1064 (42000) ... syntax to use near 'LIMIT 1', the closed one returns the expected style id. The exception is swallowed by the surrounding catch, so the method silently returns 0 instead of the template id.

The method currently has no callers inside the plugin (we grepped the whole installation; the only other getTemplateId hits are unrelated PayPal SDK methods), so nothing breaks today - but the bug is waiting for the first caller. Fix is one character: append . ')' to that where() argument.

Thank you.