We are actively thinking about a complete solution to allow you to manage and restrict access to the Cwicly block settings for your clients. Don’t hesitate to share your ideas on this solution here.
Now with the latest interface updates, we certainly need some client control in place.
For start, something to hide the additional UI added by Cwicly by post type or user would be useful. (to not confuse to much the end user)
1 Like
This is something that’s absolutely needed. It’s impossible to hand over a website built with Cwicly to the client in the hope that he/she will not break something in the process of updating a piece of information on a page or posting a new post. People always poke around to see what this and that does.
This is in my opinion a very urgent feature, otherwise client sites can be built but it’s a recipe for disaster on the long run.
Without this feature of restricting access to different user levels or certain users to Cwicly interface, I personally can’t trust to hand over a website built with it to a client.
Hi @beleancristian,
This is seeming more and more apparent everyday in the requests we get on our support, that is restricting client access.
The problem here is simple: if I/we work on proposing a coherent system of user control, then we will have to push back the Filter and Mega Menu blocks…
We can get straight to work on this and have it out next week, but it means postponing those other features. Otherwise, it will have to be another 2-3 weeks before this is launched.
Hi @Louis,
I’m sorry if maybe my previous message sounded alarming. It isn’t 
Please take your time in developing Cwicly at your best. You are the best person to prioritize and work on any feature requests we might have. You are doing a wonderful job so far and I would love you to continue like that
Thank you for taking the time to answer and confirming that this is something actually taken into consideration.
2 Likes
@Louis I like your timeframes (if you talk in weeks )
Months is not bad also.
But generally, I think as priority should be core features, for which the users don’t have an alternative, then nice to have ones. (mega menu is more on the nice to have side, as we can build one now, with a bit of work)
1 Like
In case we are talking about “next week” or “another 2-3 weeks”, let it be even a month, what is the actual difference? Can’t see the slightest issue here.
Just my general view on things.
I like the idea from Lemon Squeezy.
Users are able to plan projects more accurately in upfront. Right now, there isn’t a “real” roadmap at all.
@Marius No issue at all. That was the point. (our expected time frames are probably much longer then Louis ones)
1 Like
Hi @dranzer,
Moving this to in-progress since it isn’t yet in its final state. But definitely on the way!
This was mentioned a couple of days ago in the facebook group as a feature, maybe part of the client control, to be able to disable Cwicly for certain CPTs, same way as Oxygen or Bricks have it. If for example I have a template that takes over posts and renders them, I would like to not have Cwicly blocks available there and only Gutenberg basic blocks. If this was suggested already please disregard.
Thank you!
Incredible how fast @Louis is pushing new stuff in. This is already implemented in 1.1.8.5.4. Unbelievable.
2 Likes