/** * Card #1520 — collapsible sections (Account, and any other menu item with * children) in the shared jkit nav-menu drawer/bar. * * The vendor widget (jeg-elementor-kit) ships its own "dropdown-open" * toggle class, but every CSS rule for it in the plugin's own stylesheet is * scoped under `body[data-elementor-device-mode=...]` — the Elementor * EDITOR's responsive-preview selector — so it has zero effect on the real * frontend a visitor sees. That's why Account's seven children previously * had no controllable collapsed state at all. This file owns show/hide * state independently via its own .bb-menu-expanded class instead of * depending on the vendor's dead one, and applies to any * `li.menu-item-has-children` inside `.jkit-menu` generically (not just * the item literally titled "Account") so future submenus collapse the * same way without another card. * * `.bb-cd-shared-menu`, `.bb-ad-shared-menu` and `.bb-id-shared-menu` are * included alongside `.jkit-menu` throughout this file because Coach, * Admin and Instructor Dashboards' own page templates bypass the sitewide * Elementor header entirely — each re-renders the exact same * main-navigation-menu itself via wp_nav_menu() under its own class * instead (coach-dashboard.php Card #1512, gm-dashboard.php Card #1521, * instructor-dashboard.php Card #1529). Same underlying WP nav-menu markup * (`li.menu-item-has-children` > `a` + `.sub-menu`), just a different * container class, so all four need the same rules. Card #1521 * deliberately left `.bb-ad-shared-menu` out of this file ("making Account * collapsible is out of scope for this card"); Card #1528 folded it in so * GM Dashboard's Account section behaves identically to Member and * Coach Dashboard's instead of always rendering fully expanded. Card #1529 * adds `.bb-id-shared-menu` for the same reason — Instructor Dashboard had * no Account content to collapse at all until that card gave it the * shared-menu render. */ /* Card #1643 — `.jkit-menu` (the sitewide widget that renders as the DESKTOP top nav bar at >=768px and as the mobile off-canvas drawer below that — same DOM, CSS-repositioned, see site-header-mobile.css) is deliberately NOT in this "closed at rest" selector any more. It used to be, unconditionally, and that was the bug: this rule's `display:none !important` always won over the vendor's own native hover reveal for the top nav (jeg-elementor-kit/assets/css/elements/main.css, confirmed live: `.jkit-menu li.menu-item-has-children:hover>.sub-menu {opacity:1;visibility:visible}`) — a `display:none` element can't be revealed by a sibling opacity/visibility rule, so hovering ACCOUNT could never show anything, and the only way to reveal it at all was the `.bb-menu-expanded` class from the drawer's click JS below. Whenever that class was left set from an earlier click/localStorage state, the panel rendered open with no way for :hover to intervene at all — the reported bug. On desktop this rest state is now left entirely to the vendor's own rule (opacity:0;visibility:hidden by default, already correctly closed there), restoring native hover. Below 767px — where `.jkit-menu` renders as the off-canvas drawer instead of the horizontal bar — it still needs this file's own display:none default in the media-scoped copy below: the vendor's real collapsed state only exists inside `body[data-elementor-device-mode=...]`, the Elementor editor's own responsive-preview selector, so it has zero effect on an actual mobile browser (Card #1520's original finding). `.bb-cd-shared-menu` / `.bb-ad-shared-menu` / `.bb-id-shared-menu` are the Coach/Admin/Instructor Dashboards' own custom drawers, not this vendor hover widget, at any width — unaffected, unscoped exactly as before. */ .bb-cd-shared-menu > li.menu-item-has-children > .sub-menu, .bb-ad-shared-menu > li.menu-item-has-children > .sub-menu, .bb-id-shared-menu > li.menu-item-has-children > .sub-menu { display: none !important; opacity: 0 !important; visibility: hidden !important; } @media (max-width: 767px) { .jkit-menu > li.menu-item-has-children > .sub-menu { display: none !important; opacity: 0 !important; visibility: hidden !important; } } /* The "expanded" reveal. Card #2755: for `.jkit-menu` it is scoped to the mobile drawer (<=767px) only — on the desktop top nav (>=768px) the toggle that sets `.bb-menu-expanded` is no longer shown (see the Card #2755 block at the end of this file), so a stale class left over from a phone-width session or old localStorage must not be able to pin the dropdown open with no control to close it; the vendor's own hover reveal owns that case. The three dashboard drawers (`.bb-cd/.bb-ad/.bb-id-shared-menu`) are drawers at every width and keep the unscoped reveal. Unlike the rest-state rule above, this one doesn't fight hover: hover is only ever consulted while `.bb-menu-expanded` is ABSENT. */ .bb-cd-shared-menu > li.menu-item-has-children.bb-menu-expanded > .sub-menu, .bb-ad-shared-menu > li.menu-item-has-children.bb-menu-expanded > .sub-menu, .bb-id-shared-menu > li.menu-item-has-children.bb-menu-expanded > .sub-menu { display: block !important; opacity: 1 !important; visibility: visible !important; } @media (max-width: 767px) { .jkit-menu > li.menu-item-has-children.bb-menu-expanded > .sub-menu { display: block !important; opacity: 1 !important; visibility: visible !important; } } /* Below the mobile drawer breakpoint (matches tests/_helpers/account-menu.js's MOBILE_SUBMENU_BREAKPOINT), an expanded section lays out in normal flow — pushing later drawer items down — rather than floating as an absolutely positioned dropdown, so it reads as a true collapsible section over its children instead of an overlay. */ @media (max-width: 767px) { .jkit-menu > li.menu-item-has-children.bb-menu-expanded > .sub-menu, .bb-cd-shared-menu > li.menu-item-has-children.bb-menu-expanded > .sub-menu, .bb-ad-shared-menu > li.menu-item-has-children.bb-menu-expanded > .sub-menu, .bb-id-shared-menu > li.menu-item-has-children.bb-menu-expanded > .sub-menu { position: static !important; box-shadow: none !important; } } /* The vendor auto-appends its own decorative (non-functional) indicator icon inside the label link. In the mobile drawer (<=767px) it is hidden so only the one working chevron below shows. Card #2768: at >=768px (the desktop top nav) there is no chevron button at all, so the vendor icon is left visible and is the ONE caret next to Account; hiding it there (as this rule used to, at every width) left no indicator once #2755 removed the button. Jkit-widget-only — the wp_nav_menu() drawers never get this vendor markup in the first place. */ @media (max-width: 767px) { .jkit-menu > li.menu-item-has-children > a > i, .jkit-menu > li.menu-item-has-children > a > svg { display: none !important; } } /* ============================================================ Card #1528 — Account row layout: label + toggle on one line ============================================================ 2nd attempt within this card. The 1st attempt kept flexbox but tried to stop the li's own `flex-wrap:wrap` from ever dropping the toggle onto a second line purely via `!important` width/flex-basis overrides on the anchor (countering jeg-elementor-kit's `.jkit-menu-wrapper .jkit-menu li>a{width:100%}`) — Ted's Phase 3 run still measured the toggle 90px below the label after that fix deployed live, meaning some other part of the vendor cascade this file hasn't identified was still winning that flex-basis/width race. Rather than keep guessing at the exact vendor rule responsible, this switches the li to CSS Grid, which has no "wrap" failure mode to race against in the first place: the label and the toggle are explicitly placed into named grid cells on the same row regardless of their own width/flex-basis, and the vendor's `width:100%` on the anchor now just fills its own "label" column (the intended result) instead of being able to push the toggle anywhere. The label and the toggle