Thanks David – not sure how this slipped past, but it wasn’t intended that way.
Since 3.2 was in development for almost a year, I’m not sure exactly what was being done there without going back and finding the specific commit. But basically, both the login form builder (which handles the login, password reset, password change, and forgot username forms) and the register form builder (which does the register and profile update forms) all are now applying a form ID by default.
The default value is the “wpmem_” stem followed by the action. This doesn’t cause a problem for the password/username forms, and the register/profile form value is hard-coded. So it seems that it’s only an issue in the case of the login form (where that process ends up with “wpmem_login” which is already in use by the div wrapper).
The legacy div ID needs to remain – I’m quite certain changing that would wreak havoc on a lot of custom CSS for users. Since applying a default form ID is new in just this release and I’m pretty sure no one knows about it yet except you, I will change the new form ID process so that this gets addressed. I think adding a suffix of “_form” to the value so that it is ‘wpmem_’ . $arr[‘action’] . ‘_form’ (thus rendering wpmem_login_form in the case of the login form) will resolve it.
I’m working on a 3.2.1 release now with a few other things that have come up, so this will be included in that set of fixes. If you want to resolve it in the meantime, you use wpmem_login_form_args to filter the value:
add_filter( 'wpmem_login_form_args', function( $args, $action ) {
$args['form_id'] = "wpmem_" . $action . "_form";
return $args;
}, 10, 2);