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!
