M2 "Sign up" button (/memberships page) goes nowhere

Clicking the Signup buttons on the Memberships sign-up page simply go nowhere (the Memberships page simply reloads), but I can't see any relevant errors in wp-content/debug.log (WP_DEBUG etc are set true) or figure out what's going on, what should happen next or how to diagnose the problem any further.

Relevant additional information:
• M2P v1.0.0.7 on network activated on WPMS 4.2.2.
• Network-wide protection is enabled (ie MS_PROTECT_NETWORK defined true)
• Multiple memberships add-on is enabled (makes no difference if this is switched off)
• Logged in as a basic user WordPress user
• PayPal Standard gateway in sandbox mode enabled (as only payment gateway)
• This is after an upgrade from M1P that was working okay (more or less, though upgrading a membership was a bit broken, but mainly because of PayPal API restrictions not because of a bug in M1P)

We have SSL, but it doesn't seem to make any difference whether the page is accessed over https:// or not.

Nothing obviously relevant appears in the browser's dev console, and I can see the POST request in the network activity log with form data that looks sane (nonce, membership_id, action=membership_signup, step=payment_table). It just doesn't do anything but reload the same page.

The Membership in question is set up for recurring payments and PayPal is enabled for this membership type, also set for public (or I guess it wouldn't show up), the level is set active and it is set as a paid membership level. I've not set up any protection rules yet (nor had I before I upgraded from M1P).

It's also worth noting that I have customised the Register and Memberships pages somewhat to force the user to log in (or create accounts) via the traditional login mechanism, mainly because I don't want users bypassing the security mechanisms that the stock login and signup pages have enabled, but also because I want users to have confirmed their email address before they sign up for any memberships.

This is on our staging site, on which I have just enabled Support Staff access.

  • Adam Czajczyk

    Hey David,

    I hope you're well today and thank you for your question!

    This seems like WP or just a plugin isn't getting the value of the form that's being send upon "signup" click. I've tested it on your setup also with a "[ms-membership-buy]" shortcode that isn't sending a from data but just opening a link instead. This means that we've tested both POST and GET requests and none of these is being received properly or isn't being routed to the plugin. Therefore plugin treats a user as a non-member.

    That said, have you tried disabling all other plugins and reverting to a default Twenty Fifteen theme just to check if the issue still occurs? On my "clean" test setup it does, so if it would also work for you we'd be a step closer to finding a potential source of this issue.

    Please advise!

    Cheers,
    Adam

  • David King

    Not much further forward, I'm sorry to say.

    I instrumented several places including wp-config.php and MS_Controller_Shortcode::membership_signup() in ./app/controller/class-ms-controller-shortcode.php and can confirm that the form data are present (at least, in $_POST[]). I can also say that the test $member->is_valid() on line class-ms-controller-shortcode.php:293 returns true.

    Yet, the call to MS_Factory::create( 'MS_View_Shortcode_MembershipSignup' ) (or perhaps apply_filters( 'ms_view_shortcode_membershipsignup_data', ... ) appears to be returning the wrong thing, but I can't identify (via grep) where those calls end up that might be relevant.

    I then tried disabling all the plugins I could and reverting to 2015 theme, closing the incognito session to flush cookies, logged back in in a new incognito session, but no difference.

    I will try a fresh install of M2P in another instance of our staging platform and see when/where/if it breaks.

  • David King

    Okay, a fresh install seemed to work, and I think I've identified the problem. It's partially my fault, but also partially failure of M2P to validate some of the constants it assumes exist.

    I noticed that in the fresh install, the M2P pages had flare to indicate their special status on the reference site's "All pages" page, but this flare was missing from the staging site. I managed to find the M2P config in table wp_sitemeta, and I noticed the following difference in meta key ms_model_pages-network (excerpted, because serialised PHP strings are ugly):

    s:8:"settings";a:6:{s:7:"site_id";s:20:"BLOG_ID_CURRENT_SITE";

    where in the fresh install, it looked like:

    s:8:"settings";a:6:{s:7:"site_id";i:1;

    When I first installed M2P, the constant BLOG_ID_CURRENT_SITE was not defined. I fixed that as soon as I saw the error in the log but, by then, the damage had already been done. By manually fixing this from the mysql shell, suddenly page flare showed up in the Pages view, and suddenly the 'subscribe' button does what it should.

    So, closing this ticket now. If I may recommend to the M2P developers, check that BLOG_ID_CURRENT_SITE is defined and refuse to configure until this is fixed, or otherwise do something "sensible" (eg perhaps assume an integer value of 1, since that's the only value it ever seems to get).

    (As to why this symbol wasn't defined, if memory serves, the WPMS documentation suggested (at the time that I set this WPMS instance up) that that and certain other constants were optional and therefore I commented out that and a few other constants, notably DOMAIN_CURRENT_SITE because I wanted to keep synchronisation of our production site with our staging site as simple as possible.)

  • Adam Czajczyk

    Hello David,

    Thank you for this information!

    I've run some more tests on my sandbox but I wasn't able to replicate this behavior, in consequence I'm not quite able to trace the place in the code that's causing it. However, it would be great if you could setup a clean install on the very same server and grant me an access to it so I could safely play with this.

    Let me know please when you're ready and I'll jump into it immediately.

    Cheers,
    Adam

  • David King

    Hi Adam,

    Looks like a case of ships passing in the night; see my last post in this thread. Sorry to put you to wasted work.

    In short, the cause seemed to be bad configuration, a bad value for ['settings']['site_id'] in table wp_sitemeta WHERE meta_key = 'ms_model_pages-network'. Fixing that seemed to fix the problem.

    The only bug, as far as M2P is concerned, is to fail to check that symbol BLOG_ID_CURRENT_SITE is defined before that key is inserted into wp_sitemeta.

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.