Improve how we load the CSS/JS for magic login.

[andrewlimaza]

• BUG FIX: Fixes an issue where the login widget would not display the magic button in the correct place.

Resolves: #1

[flintfromthebasement]

PR: #2 — Improve how we load the CSS/JS for magic login.
andrewlimaza → dev | 1 file, +4 -7
#2

---

Summary
This PR fixes a real bug — the magic login button not appearing on PMPro's frontend login form — by moving the enqueue call directly into pmpro_ml_add_login_button(). The intent is sound, but the implementation introduces a timing regression: both hooks pmpro_ml_add_login_button() is registered to (login_form, login_form_middle) fire after wp_head() has already been called. That makes the wp_enqueue_style call a no-op — CSS won't appear on either wp-login.php or the frontend form. Not ready to merge as-is.

---

Issues

• Major includes/functions.php:18-20 — The login_enqueue_scripts hook was removed along with the two add_action calls at the bottom of the old pmpro_ml_enqueue_scripts(). The replacement call lives inside pmpro_ml_add_login_button(), which is hooked to login_form and login_form_middle — both fire inside the rendered form HTML, after wp_head() has printed the style queue. wp_enqueue_style( 'pmpro-magic-login', ... ) called at this point is silently dropped. The magic login button will render without its stylesheet on both wp-login.php and any PMPro frontend login page.

  The JS (in_footer: true) will survive because login_footer() calls wp_print_footer_scripts() — but the CSS has no equivalent late-print mechanism.

  Fix: Restore add_action( 'login_enqueue_scripts', 'pmpro_ml_enqueue_scripts' ) for wp-login.php. For the frontend, either drop the pmpro_is_login_page() guard entirely (enqueue is cheap, and missing it is the original bug), or hook to wp_enqueue_scripts unconditionally. The direct call from pmpro_ml_add_login_button() can stay as a fallback but cannot be the sole enqueue path.

---

Looks Good

The docblock update accurately describes the new behavior (login_form action context). That's a good change regardless.

---

Questions

1. What specifically was causing pmpro_is_login_page() to return false in the widget context? Understanding that might surface a cleaner fix — e.g., a hook timing issue on PMPro's side that's solvable without dropping wp_enqueue_scripts entirely.