Add the custom attribute and value specified in the documentation to the element in which you want that user data to appear (e.g. for ‘email’ add wfu-bind = $user.email).
Set up complete
But this alone doesn’t work. You also need to add this code just after the code from the first step:
<script>
window.sa5 = window.sa5 || [];
// Insert some kind of config change here, e.g. access groups - as seen in the cloneable]
window.sa5.push(['userInfoChanged',
(user) => {
console.log("USER INFO CHANGED", user);
}]);
</script>
The documentation implies that this extra code is only required if you want to access the user data using Javascript. But without it the custom attributes approach doesn’t work, even if you just want to display the user’s email address (not any custom fields). It’s even more confusing as the above two step process is exactly how SA4 Memberships worked - ‘Copy and paste this script, then add custom attributes where you want the data to appear.’
An example of a complete code block that works from the very beginning can be found at the bottom of this page. If you add that code and then add a custom attribute to an element, it will work.
This took me an entire day to figure out. It was very frustrating. But please let me know if I’ve misinterpreted something in the documentation.
Thank you very much for this post. I spent some time trying to figure out why the Step 1 and 2 alone would not work for simply pulling in user email into prepopulated input field in a form. I have taken the full code you pointed to and it has worked.
I have access groups enabled (although I am not pulling any access group data at present, only standard user email). Could that be why it only works using the full membership BETA code?
Add the appropriate custom attribute to the element in which you want user data to appear, e.g. to show their email, under that element’s customer attributes, add the name wfu-bind and the value $user.email
Hey Nathaniel. That sounds like a reasonable deduction. Although I can’t remember specifically “activating” access groups. That just happens when you activate Memberships… I think? I thought there might be something in there that I don’t understand, but I’ll wait to hear from the developers.
That shouldn’t be necessary- if you look at the code you can see it doesn’t do anything except a console log. However I’ve recently built SA5 Core and its centralized eventing system. I’ll check this out to see if there’s some type of accidental dependency on the existence of a userInfoChanged handler.
The documentation is definitely correct for the designed behavior. You read it right. This is why I put out the call for BETA testers, we always use the libraries with most of the features in use and wouldn’t have seen this configuration. Thanks for posting, that’s exactly what we need.
Tip for the future, go back to the cloneable, It’s tested and demonstrates a working setup for all features. Just clone, publish, and play. From there, you can easily adjust and test the configuration you’re trying to achieve.
5.3.4 includes access groups, which was merged in from BETA as the community has not reported any issues.
However, one key difference in access groups is the addition of the getMembershipConfig handler, which there appears to be a dependency on. I’ve updated the docs accordingly;
Access groups doesn’t need to be “activated”, as it’s fundamental to Webflow User Accounts. As of 5.3.4, SA5 also support access groups in the main production lib.
However to make use of that feature, you need to do a bit of special setup;
I’m implementing SA5 at a time when I’m learning Javascript by trial, error, and googling. It’s good to know that I’m getting far enough along that I can be helpful!
