Webflow's announcement & and element-level conditional vis by access group

Yesterday, Webflow announced that they will be halting further development on Memberships and Logic, and that these subsystems will be released to production soon ( to all users, with no more BETA label ) with the current feature set.

This news means that we likely won’t see a few key features the community has been eagerly awaiting, most notably-

Element-level conditional visibility, by access-group.

Internally, Sygnal has been using a makeshift solution that provides this capability, but we’ve avoided adding it into the Sygnal Attributes library because it looked likely that Webflow’s element-level access group functionality would drop any day.

Also, our makeshift solution is a total hack.

Even with Webflow’s declaration that they have halted feature development on Memberships, I’m hesitant to add this feature to our library for two main reasons;

  1. It’s slow, meaning it adds a second or two for us to compile access group data after login. This is on top of the current performance costs of obtaining custom user fields, so I’m not enthusiastic about potentially adding seconds to that login-time delay.

  2. It’s insecure. Gated elements will be shown and hidden using script, rather than server-side the way Webflow gates elements in its login-state conditional visibility feature. Client-side gating is insecure, and although it is the way other platforms like Memberstack work on top of Webflow, it’s simply not suitable for secure content.

and of course…

  1. It requires polishing, testing, and setup docs which will cost a couple days of dev / test time.

So, I thought the best way to decide this is to open the discussion to our awesome users.

  • Do you need this?
  • Are you going to stick with Memberships?
  • What are your use cases?
  • Will the performance delay ( just after login ) and the lack of element-content security be workable for your use cases?

Let me know.

And, if you vote yes, please consider contributing something to help cover our dev costs.

1 Like

yes! this would be great!! even with the additional performance cost in some low data sensitivity instances its worth it.

Yes I need this and I’m willing to accept the performance and security limitation.
I’m creating an online school. Free members will have full access to a few of the courses and “preview” access to the rest of the courses. By preview access I mean the they can take the first two or three lessons of the course. And they can see the rest of the lessons listed in the course navigation. If the click one of the “locked” lessons the will be informed that they can access it if they pay for a subscription. So even if Webflow implement hiding elements based on logged in AND access group it would not suffice for my case. I need the logged in users access groups so I can implement the custom access behavior i’ve described. A short delay after login before I have the needed info is acceptable.

We’re actually about to revisit this soon for a side project.

I want to note though that the setup you’re describing will require quite a bit of custom code even with access group information in SA5’s user object. If you’re ok with that, I can involve you in the BETA once we’re there.

Membership Access Groups has been released to BETA!
Details are here-

Yep, I’ve already implemented the code for locking content and features and test it with some dummy user data and access groups. I see you released the access group stuff. Thanks, I’ll give it a try. :slight_smile:

1 Like

A demo of access groups is now part of the cloneable.

A post was split to a new topic: UserID and custom fields