coachtest

Thanks for the reply. This is sort of what I figured would be the case. For now I’ll just avoid template parts and try and stick with patterns where there is a bit more wiggle room.

I’ll also look into the filters you mentioned. Thanks again.

I’m not going to claim this is right way; but, I find you should base your media queries on what the component your working on needs. If you have a complex testimonial block and it looks awkward, or crowded at 1200px I would define my breakpoint for that component at that size.

I would also look into whether the component your working on needs a media query. You can also use techniques like the one found here.

If you do want a set a breakpoint I’ve found breakpoints on Tailwind CSS to be useful.

Thanks for the reply. My javascript is already enqueued and is working in the browser it just breaks in the edit view.

From what you are saying it sounds like a library like alpine.js [https://alpinejs.dev/] which is primarily relies on inlining into the html is not going to work in the editor view. Is there no way to encapsulate the x-data or any other code I would like the editor to ignore so it will show properly in both the front-end and edit view?

• This reply was modified 1 year, 10 months ago by coachtest.
• This reply was modified 1 year, 10 months ago by coachtest.

Did you ever find a solution to your issue?

Hello @swetakumari

There is nothing I can show in a screenshot. It’s just when I added a background color and inspected the code the background-color was not applied to the wrapper element, instead it was applied to a separate Div that was absolutely positioned to the wrapper element.

• This reply was modified 3 years, 1 month ago by coachtest.

Thanks I’ll use that.

Figured it out with php. using <?php echo do_shortcode(“[wpv-user field=’user_firstname’]”); ?>

Is there a better way? or is it possible with handlebars?

• This reply was modified 3 years, 1 month ago by coachtest.
• This reply was modified 3 years, 1 month ago by coachtest.