Component-ized Query Template renders on back end, but not on front

General
1

Firstly, again, thank you Cwicly team for this innovative software. Nothing else like it in WP.

I’m checking if this is the expected behavior.

I have a component, in which I have nested an Inner Blocks block, so that I can nest a unique Query block per each instance. Inside that goes the Query Template.

I have attempted to Component-ize this Query Template. In the builder, the Query Template component renders just fine. On the front-end, it does not render at all. The only work-around seems to be to select “Detach Blocks” for the Query Template component. Once static-ized, the loop renders on the front end.

Thank you again.

2

Hi @james,

Thank you for the kind words, we really appreciate it :slight_smile:

I believe this isn’t currently possible.
There is a question of context at play here, that makes it harder to component-ize.

I’ll be sure to pass this along to the dev team, to further investigate this possibility.

Thank you for your understanding.

1 Like
3

Thank you @Araminta!

1 Like
4

Hello again @Araminta,

I have a question unrelated to this thread, and have searched the forums for an answer.

Sadly, I’m working with a non-block theme on a project; and while Cwicly remains the absolute best option for building out the content area on standard pages, I’m wondering about the recommended flow for CPTs.

Cwicly is unable to create a custom template for CPTs in a non-block-based-theme environment, is that correct? The only workaround seems to be to create a component, and then manually insert that component in every page in the CPT. Is this approach “Cwicly correct” given the constrained environment I’m working in?

Thank you for your time!

5

A few months ago we migrated a site using a non block-based theme to using the Cwicly theme. The site was not extremely large in terms of pages but did have a lot of features and functionality, including a WordPress shop and LearnDash courses.

The entire process took between 2-3 days (with a bit of planning and preparation) and was relatively seamless.

Depending on the complexity of the site/theme and the time/resources available, it may be worth considering transitioning to a block-based theme to future proof the site at some point as the amount of time working around the limitations of a legacy theme may end up taking more time than simply moving to using FSE.

6

In the long term, there is no denying you are right in what you say. I will have to port this over eventually; and I plan to. In the near term, however, there are simply too many things the theme is handling right now, and porting all that over to custom code via Cwicly would be very time consuming.

For context, I’m using the Shoptimizer theme by CommerceGurus, which integrates with their CommerceKit. There are dozens of complex UX / UI components that are dependent upon the theme (and CommerceKit); and custom porting all that over is not feasible given present time constraints.

Whereas, it’ll take me a day to whip up a Cwicly component to insert per each CPT (which is a new CPT for this project, and has zero pages). Then upon each page creation, we insert the component and enter the data.

While porting the project entirely over to Cwicly would eliminate the aforementioned “insert the component” step (saving a literal mouse click), the alternate of porting the entire site over would take weeks of dev time (at least for me).