I’ve worked a lot with cwicly lately, and I feel like it is one of the most powerful builder out there. Specially the ability to easily integrate my own custom Gutenberg Blocks whenever I need some functionality and/or layout which isn’t possible in Cwicly yet.
Most of the time this functionality relies on some kind of API-Data which is consumed from a custom WP-Rest API Endpoint. Lately I’ve developed a small Event-Plugin which uses such an API Endpoint.
All the complexity of that plugin is handled in php and also the WP-Query for data, but I needed to duplicate some events if they are recurring events and so my rest api now outputs a list of dates with events (also recurring events). My GB-Block (or more precisely in that case it is a shortcode) consumes that Data from REST-API and shows a list with events. That part could easily be handled within cwicly in my opinion if the fields coming from REST API would be registered inside the dynamic field values of cwicly (only in that specific query block I’m using Data from a REST-API). So it would basically just loop through the Array of Entries (whatever entries it is) and registers all the fields and make them possible for use later.
I hope it’s understandable what I mean, if not feel free to ask me for further explanations :-D. I think that would extend Cwicly’s dynamic features to almost endless possibilites!
+1. It will be a game changer. Builderius is doing some work in this direction.
Hi there @Wolfgang,
I’ve been experiencing the need to use the Repeater on custom data (although not through an API) as we’re reworking our cwicly.com user dashboard, but this would follow the exact same lines.
Might I ask if you are consuming the API REST while server rendering or once the page is rendered?
Hey @Louis ,
in that particular case I’m consuming it after rendering, there is no real need of SEO and since it’s consuming data from its own WP installation i don’t have to worry about that the events itself don’t get listed in Google
For me personally I don’t see that huge use case in consuming data server side as I’m using it now. Normally that stuff results in a bit more complex layouts which i don’t want to do in PHP anyway (personal opinion of someone who’s also doing a lot of frontend applications) but ofc if cwiclys repeater/query blocks would be able to work with that data a lot of stuff could be rendered server side which would probably result in better SEO Scores.
Hey @nadim ,
veryy cool and smart solution. I find it very interesting. It doesn’t solve the problem in it’s core and especially when working with data that changes very often it may be also a bit of work to setup a cron job or a rest api endpoint to update that acf fields…but all in all it solves the problem with not being able to style data inside of cwicly.
Again, very cool solution → thanks for sharing!