Is anyone else having this issue? - Templates not displaying fields until post is published

Loops & Logic
#1

Just wondering if anyone else is having this problem… I have multiple sites that run Loops & Logic, and they are all having this issue.

Today I set some custom fields in a post and inserted a template block. When I previewed the draft, the custom fields weren’t displaying the way they should in the template. (We’ve been using this template for a while, so I know it’s not the template—unless something has changed.) All the HTML elements show up, but most/none of the tags are outputting anything.

Sometimes I can get a few fields to display, but not others. It seems like the date field and the category field tags are more likely to work, while everything else stays blank.

The only thing that works is to publish the post, and then everything works normally. But that’s not an optimal workaround.

Last week it was working. The only big change since then on the website (that I can think of right now) is that I updated certain plugins, including Loops & Logic. I looked at the 3.0.0 release notes, and it didn’t seem like there were any changes that would impact functionality for templates that I’ve already written. I’m not using Tangible Blocks.

In the past, I’ve sometimes had this happen if I open the post in editing mode and then click Preview in New Tab. But if I went back to the Posts page and clicked Preview from there, it would display correctly.

Is anyone else experiencing anything like this?

Undefined Loop not pulling results in 3.0
#2

I was just noticing this issue yesterday and wasn’t sure if it was a bug or not. Testing it a bit more now, I’ve realized that it’s not so much a bug as simply L&L being overzealous with how it displays post data by default. Here’s what I think is happening.

If you created a simple post loop (something like <Loop type=post><Field title /></Loop>) you’d probably expect that by default, L&L shouldn’t display draft posts and should only display published posts. This is by design since 99% of the time you only want to display published content on the front end of your site; you don’t want to display your draft posts. If you did want to display draft posts, you could simply add the query parameter status=publish,draft and then it would display both published and draft posts.

Where this gets weird is that if you have a draft post and add a template to it that simply includes <Field title /> on it, the current post’s title doesn’t get displayed (until you publish the post, then it gets displayed). I think that’s because L&L is thinking “this is a draft post/page and I shouldn’t display its data by default.” If you take your L&L template and wrap the whole thing in a post loop like I’ve written below (replacing the id with your current post’s id), you should see that all your fields show up as you’d expect because you’re telling L&L to display data from draft posts:

<Loop type=post id=123 status=publish,draft>
  <Field title />
</Loop>

This kinda makes sense, but I’m assuming a better way to make this work would be for L&L to display the current post’s fields even if the post is a draft. In other words, the default query of a draft page should be set to display data about posts that are in draft, but this should only affect the default query (the one that allows you to display data about the current page) and not other queries you might write in your template. I know that there were some improvements made to L&L in 3.0.0 which fixed things like the preview button in Gutenberg not displaying fields from the current post. I wonder if, in fixing how L&L gets its loop context on page builders in 3.0.0, this made it so that L&L wouldn’t display data about draft posts, even if it was the current post. I’ll pass this up the ladder to Eliot to look into addressing this in the next update but as a workaround for now, try wrapping your templates in a post/page loop as I did above. Not ideal, but it might make your work easier for now.

2 Likes
#3

Thanks @benjamin - I appreciate you and Eliot looking into it.

It seems like I got the workaround to work for now; thanks.

1 Like