/** * Vanshap Capital — the PMPro login form. * * The sibling of forms.css, and written to the same brief: one page carries a * vendor-drawn form, and the form has to read as part of this site rather than * as the plugin's default skin sitting inside it. Everything here is scoped to * `.vc-login-grid`, which the login pattern puts on the two-panel wrapper, so * nothing reaches a PMPro component rendered anywhere else. * * Kept out of sections.css because that file owns LAYOUT — where the two * panels sit, how they stack, what the aside's rule looks like. This one owns * a vendor's markup, which is a different kind of thing with a different * failure mode: it breaks when PMPro reshuffles its classes, not when the * design changes. Enqueued by vanshap_view_has_pmpro_login() in inc/enqueue.php * on the `[pmpro_login]` shortcode, exactly as forms.css is gated on * `[fluentform]` — the rest of the site must not download this. * * ── Why the selectors are so long ────────────────────────────────────── * * ⚠️ Read this before shortening anything. PMPro's variation_1.css is written * with CSS NESTING: the whole file is one `.pmpro { … }` block, and every rule * inside it is an implicitly-`&`-prefixed child. `& .pmpro_card` desugars to * `:is(.pmpro) .pmpro_card`, so EVERY vendor selector silently carries one * more class than it appears to. `.pmpro_section #loginform .login-submit * .button` reads as (1,3,0) and is actually (1,4,0). * * That is why the note this file replaced claimed the winning declaration * "could not be located by walking document.styleSheets" — it is there, but a * nested rule's selectorText is `& .pmpro_btn`, which el.matches() rejects, so * a CSSOM walk skips the entire vendor sheet in silence. It is not missing and * it does not use !important. It is simply one class more specific than it * looks. Verified 20 Sep 2026 by toggling sheet.disabled one at a time, which * is the diagnostic to reach for when a rule here stops winning. * * So the rule below each vendor rule mirrors its ancestor chain and adds * `.vc-login-grid .pmpro` in front, which buys two classes against the * vendor's one. Dropping a link from a chain does not tidy the selector, it * loses it. * * ── TWO markups, not one ─────────────────────────────────────────────── * * The shortcode renders a different form per action and they share almost no * class names: * * /partner-login/ core's wp_login_form() * .pmpro_card.pmpro_login_wrap * .pmpro_card_content > form#loginform * p.login-username > label + input.input * p.login-password > label + input.input + the toggle (moved in by * PMPro's own script after load) * p.login-remember > label > input#rememberme * p.login-submit > input#wp-submit.button * .pmpro_card_actions > .pmpro_actions_nav > a "Lost Password?" * * /partner-login/?action=reset_pass PMPro's own form * .pmpro_card.pmpro_lost_password_wrap * .pmpro_card_content * p.pmpro_lost_password-instructions * form#lostpasswordform.pmpro_form * .pmpro_form_field > label.pmpro_form_label + input.pmpro_form_input * .pmpro_form_submit > input.pmpro_btn * .pmpro_card_actions > .pmpro_actions_nav > a "Log In" * * Every rule below names both, and a change made for one must be checked * against the other. Styling only the first is the easy mistake here and it is * invisible until someone forgets their password. * * @package Vanshap */ /* ════ The vendor's own variables ═══════════════════════════════════════ */ /* PMPro paints its form from these, which is the extension point it intends themes to use — overriding them restyles every PMPro component here at once and survives an update that reshuffles selectors. Chasing the individual rules instead means a specificity war against markup we do not own, and the sections.css block this replaced had already lost one. Declared on .vc-login-grid rather than :root deliberately: the plugin prints its own `pmpro_colors`