Préparez-vous pour une bizarre. Je personnalise donc la navigation du catalogue principal pour créer un comportement d'interface utilisateur complet qui gère plusieurs modèles d'interaction (menus, listes déroulantes, modaux, etc.) sur les appareils. Comme vous le faites.

Cela signifie remplacer cette classe / méthode:

app/code/core/Mage/Page/Block/Html/Topmenu.php :: _getHtml()

Pour produire une sortie HTML comme celle-ci (quelque peu simplifiée):

<ul class="nav-list">
    <li class="nav-1">
        <a data-ui-action="nav-1" href="#">Bazzow</a>
        <div class="menu"> ... </div>
    </li>

    <li class="nav-2">
        <a data-ui-action="nav-2" href="#">Bazinga</a>
        <div class="menu"> ... </div>
    </li>
</ul>

Maintenant, c'est assez ennuyeux / standard, sauf pour l' data-ui-actionattribut. C'est là que la magie JS se produit. Tout clic sur des éléments avec cet attribut met à jour l'état de l'interface utilisateur. Vous l'avez deviné, la li.nav-Xclasse (que Magento ajoute) agit comme mon crochet pour lier l'état de l'interface utilisateur à l'élément activé.

Tout va bien, non? Activez le cache EE. Tout va bien, non? Faux.

Si la page que vous consultez se trouve dans la hiérarchie de catalogue de Bazinga (aka nav-2), vous verrez soudain ceci:

data-ui-action="nav-2 active"

Qui a ajouté la activechaîne méchante ? Le fantôme est qui.

Et maintenant, votre état d'interface utilisateur échoue, car la valeur de l'attribut de données ne correspond plus à la <li>classe. Traquez le fantôme.

La chasse

1. Tout d'abord, vous vérifiez que sous EE cache la variable $child->getPositionClass()qui sort nav-2n'a pas réellement (probablement) d'autres valeurs de classe ajoutées. Ce ne est pas.

2. Vous vérifiez que l'un des nombreux scripts JS de Magento ne s'exécute pas dans la liste de navigation. Ce n'est pas.

3. C'est peut-être en fait quelque chose d'étrange /js/varien/menu.js. Mais vous avez déjà exclu ces scripts de base comme vous le faites toujours.

4. Peut-être que c'est un JS en ligne fou que vous ne sauriez jamais qu'un module rend hors de la classe PHP. Recherchez les balises activedans la source de la page <script>. Vous ne trouvez rien.

5. Peut-être que c'est un autre JS Magento fou qui nécessite mais se charge en externe. Vous désactivez JS dans le navigateur, mais le fantôme vit.

6. Vous revenez à votre Topmenu.phpclasse et supprimez l'attribut de données. Le problème s'arrête. Que se passe-t-il.

7. Vous vous demandez si un autre attribut sur le même élément n'est pas correctement fermé entre guillemets (hé, beaucoup de classes s'ajoutent là-dedans). Vous échangez donc l'ordre des attributs et les supprimez dans diverses combinaisons. Pas de dé. Si l'attribut de données est présent, le fantôme l'est aussi.

8. Vous vous demandez si ce n'est pas cette classe PHP qui fait l'acte? Il y a un page_block_html_topmenu_gethtml_afterévénement distribué que quelque chose d'autre pourrait utiliser pour pirater le balisage d'au-delà. Rien.

9. Quoi. Est. Événement. Ici.

La réponse

Expliquez tout cela aux développeurs backend. Tout le monde est confus. Jusqu'à...

Quelqu'un se fissure:

app/code/core/Enterprise/PageCache/Model/Container/Catalognavigation.php
Method: saveCache()
Line 107

Vous voyez une petite expression régulière méchante:

if (preg_match('/(?<=\s|^)nav-.+?(?=\s|$)/', $classValue, $matches)) {
    $categoryUniqueClasses .= ($categoryUniqueClasses ? ' ' : '') . $matches[0];
}

Ce qui correspond à quelque diabolique nav-dans ce domaine <li>. Juste pour que vous vous souveniez:

<li class="nav-1">
    <a data-ui-action="nav-1" href="#">Bazzow</a>
    <div class="menu"> ... </div>
</li>

Magento s'attend à ne trouver que des nav-chaînes sur les <li>éléments, mais la valeur de votre attribut de données est mise en correspondance et piratée. Ne veut pas.

Utilisez donc une classe et un attribut de données différents comme i-have-a-child-.

Un vrai homme fait sa propre chance, Billy Zane.