How do I fix Memberstack after switching from test mode to live mode with a custom domain?

Post author
John Doe

Hi, Test mode was working. Then, I subscribed to memberstack and switched to live mode after adding my live domain. Now nothing is working

Comments

3 comments

  • Comment author
    A J

    Can you check if the profile page that the user is being redirected to has the live domain / test mode domain?

    i.e. Is it redirecting to https://www.distripharm.ca/profile for example or is it redirecting to webflow.io/profile domain instead?

    it seems there is a styling enabled on the body element to keep it's visibility hidden.

    Can you check the visibility settings of the body element in the right side bar or check the Conditional visibility settings of the /profil page in the Webflow designer right side tab?

    0
  • Comment author
    Chukwudi

    Thanks for reaching out. I’m sorry to hear you’re having trouble after switching to Live Mode.

    Could you please share a bit more detail so we can look into this? For example:

    • What specifically isn’t working — is it logins, signups, gated content, or something else?
    • Are you seeing any error messages or unexpected behavior?
    • Can you confirm your live domain URL?

    Once I have that information, I’ll be able to guide you more accurately.

    You can use data-ms-content attribute to gate the body and add this data-ms-bind:style="display:block" custom attribute to it.

    So essentially, the crucial elements are hidden already and when Memberstack loads, it checks whether the user definitely has permission to access the page content and then displays it.

    Here's a guide on the use of the attribute.

    0
  • Comment author
    A J

    +1 to what Chukwudi said.

    You can have the content's display set to none via Webflow styling and add the relevant attributes as suggested above and it should work for you.

    Here's a guide on the data-ms-bind:style attribute as well. (edited) 

    John Doe, there are multiple ways you can solve this.

    The attribute way:

    • Set the body or the page wrapper element's display property to none in Webflow styling
    • Add the custom attribute data-ms-content=members for the element and add another attribute data-ms-bind:style="display:block"
    • This should ideally hide the entire element when the page loads even for a split second before redirecting to the access denied page

    The code way:

    <style>
      body {
        visibility: hidden;
        opacity: 0;
      }
    </style>
    
    <script>
      window.$memberstackDom.getCurrentMember().then(({ data }) => {
        if (data) {
          document.body.style.visibility = 'visible';
          document.body.style.opacity = '1';
        }
      });
    </script>
    

    You can try the modified version as above and it should work as well.

    The attribute way is just simpler and easier to handle in future.

    Hope this helps.  

    In case you want to go with the code option, you can place the style code in head tag and have the script in the body tag of custom code.

    If it doesn't work, can you share the read-only link of the site, I will test signing up again to check the results.

    I tested the code on my personal dummy site and it works as expected on my end.  

    Let's try something  

    What happens when you place the following lines at line number 19 inside the memberscript #143?

     document.body.style.visibility = 'visible';
     document.body.style.opacity = '1';
    

    i.e. place the above 2 lines after the following line of code:

    if (!data) return console.log("No member data (logged out)");
    

    Remove the additional script above the #143 and let me know what happens.

    Yes no changes on that.

    Doesn't seem to happen on my end

    Can you try signing up or filling the profile and testing it out?

    I tried accessing the profile page on incognito mode and seems like it shows blank (and does not show the profile form / heading) and redirects to the access denied page.

    Hope this solves your use-case. 

    Yes, that comes from the scroll interaction you have set up on the unauthorized page's container-large element (as shown in the right sidebar in the screenshot).

    0

Please sign in to leave a comment.