Answers.Body: <p>I updated my template to conditionally set the <code>{{ entry }}</code> variable depending on if the request is a live preview or not.</p>
  
  <pre><code>{% if not craft.app.request.isLivePreview() %}
      {% set entry = craft.entries({
          section: 'Events',
          slug: craft.app.request.segment(2),
          status: ['live','pending','expired']
      }).one %}
  {% endif %}
  
  
  &lt;h1&gt;{{ entry.title }}&lt;/h1&gt;
  {{ entry.body }}
  </code></pre>
  
  <p>So if it's a Live Preview request, tell Craft to use its native dynamic <code>{{ entry }}</code> variable, which will work in Live Preview no matter what the entry's status is.</p>
  
  <p>But if the request is not a live preview, we need to explicitly tell the template what entry we're trying to access, so we set the <code>craft.entries</code> variable.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-01-10T23:51:32.967Z
Answers.LastActivityDate: 2019-01-10T23:51:32.967Z
Answers.UserDisplayName: kmgdev
Answers.Body: <p>If your “event” Entry's Section settings define a URI and a template path, Craft will take care of defining <code>entry</code> in the template. No need to look it up by segment!</p>
  
  <p>Generally speaking, this will “just work” for Live Preview, as well.</p>
  
  <p> I'd recommend setting the Event Section's <code>Template</code> to <code>_events/event</code>, and creating <code>templates/_events/event.twig</code> in your project folder. Then, <code>entry</code> will be automatically available when the template is rendered, either from a front-end request, or via Live Preview.</p>
  
  <p>I can't speak exactly to the internals of Live Preview—but I can say that it side-steps the normal routing by laterally <code>POST</code>ing the updated content to a <a href="https://docs.craftcms.com/api/v3/craft-controllers-entriescontroller.html#public-methods" rel="nofollow noreferrer">Craft Controller</a> that independently resolves and renders the template. That said, once it starts rendering the template, it's almost exactly the same context you'll get when the Entry is live, and requested via its normal URL.</p>
  
  <blockquote>
    <p> Using an underscore in the template's path will make sure the template is not directly accessible, and is only rendered during a request that Craft has determined matches an Element (in your case, the event Entry), or via the Live Preview controller. Read more about how Craft routes requests, <a href="https://docs.craftcms.com/v3/routing.html" rel="nofollow noreferrer">here</a>.</p>
  </blockquote>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-01-05T22:01:10.217Z
Answers.Text: If the entry has a `pending` or `expired` status, as my upcoming and passed events entries do, then Craft will not recognize the native `entry` variable in the template.
Answers.UserDisplayName: kmgdev
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-01-06T02:24:10.593Z
Answers.Text: I've just tested this with an Entry in the `pending` state, and Live Preview works as expected… can you confirm your `Template` path and `Entry URI Format`, as they appear your Section's settings, and post the contents of the template you expect to render the Entry?
Answers.UserDisplayName: August Miller
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-01-06T02:24:44.690Z
Answers.Text: Also worth noting—pending and expired entries are not accessible via the front-end, when using Craft's normal routing system—but Live Preview will work just fine (as will a URL created with the "Share" button at the top of the Entry edit page)…
Answers.UserDisplayName: August Miller
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-01-06T21:02:24.230Z
Answers.Text: Yes, I know pending and expired entries aren't accessible via the front-end, that's the whole reason I'm asking this question. Having Live Preview working doesn't do me any good if the front-end template does't also work. I need BOTH live preview AND the front-end to work for pending and expired entries.
Answers.UserDisplayName: kmgdev
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-01-06T22:19:57.487Z
Answers.Text: It sounds like the Pending and Expired fields are being used for something they're not well-suited for… if you just need your Events to have dates, I'd recommend using a custom field—you can still sort and filter based on custom date fields (like you can with `postDate` and `expiryDate`, and you won't have to subvert the automatic behaviors.
Answers.UserDisplayName: August Miller
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-01-05T06:43:00.460Z
Answers.LastActivityDate: 2019-01-05T06:43:00.460Z
Answers.UserDisplayName: August Miller
Body: <p>I have an Events section on my site, and to display upcoming and passed events (entries with a status of <code>pending</code> or <code>expired</code>) I manually set the entry in the template:</p>
  
  <p>Where the URL is <code>/events/my-event-title</code></p>
  
  <pre><code>{% set entry = craft.entries({
      section: 'Events',
      slug: craft.app.request.segment(2),
      status: ['live','pending','expired']
  }).one %}
  
  &lt;h1&gt;{{ entry.title }}&lt;/h1&gt;
  
  {{ entry.body }}
  </code></pre>
  
  <p>This works great except when I go to publish a new Event and use the Live Preview. Since the new entry doesn't have a slug yet, the <code>craft.app.request.segment(2)</code> variable returns null, and so <code>entry</code> returns the last-published Event entry instead. So all of my template variables are pre-populated with a different entry's content.</p>
  
  <p>How do I set this up so my Live Preview displays blank until I enter content?</p>
  
Tags: <templating><events><live-preview>
Title: Live Preview for Upcoming Entries
ThreadText: # Live Preview for Upcoming Entries
  
  (Asked by: username_0 on 2019-01-05)
  
  I have an Events section on my site, and to display upcoming and passed events (entries with a status of `pending` or `expired`) I manually set the entry in the template:
  
  Where the URL is `/events/my-event-title`
  
  ```
  {% set entry = craft.entries({
      section: 'Events',
      slug: craft.app.request.segment(2),
      status: ['live','pending','expired']
  }).one %}
  
  <h1>{{ entry.title }}</h1>
  
  {{ entry.body }}
  
  ```
  
  This works great except when I go to publish a new Event and use the Live Preview. Since the new entry doesn't have a slug yet, the `craft.app.request.segment(2)` variable returns null, and so `entry` returns the last-published Event entry instead. So all of my template variables are pre-populated with a different entry's content.
  
  How do I set this up so my Live Preview displays blank until I enter content?
  
  **Tags:** templating, events, live-preview
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_0 on 2019-01-10. Score: 1 | Accepted answer
  
  I updated my template to conditionally set the `{{ entry }}` variable depending on if the request is a live preview or not.
  
  ```
  {% if not craft.app.request.isLivePreview() %}
      {% set entry = craft.entries({
          section: 'Events',
          slug: craft.app.request.segment(2),
          status: ['live','pending','expired']
      }).one %}
  {% endif %}
  
  <h1>{{ entry.title }}</h1>
  {{ entry.body }}
  
  ```
  
  So if it's a Live Preview request, tell Craft to use its native dynamic `{{ entry }}` variable, which will work in Live Preview no matter what the entry's status is.
  
  But if the request is not a live preview, we need to explicitly tell the template what entry we're trying to access, so we set the `craft.entries` variable.
  
  
  ---
  
  ### Answer by username_1 on 2019-01-05. Score: 1
  
  If your “event” Entry's Section settings define a URI and a template path, Craft will take care of defining `entry` in the template. No need to look it up by segment!
  
  Generally speaking, this will “just work” for Live Preview, as well.
  
  I'd recommend setting the Event Section's `Template` to `_events/event`, and creating `templates/_events/event.twig` in your project folder. Then, `entry` will be automatically available when the template is rendered, either from a front-end request, or via Live Preview.
  
  I can't speak exactly to the internals of Live Preview—but I can say that it side-steps the normal routing by laterally `POST`ing the updated content to a [Craft Controller](https://docs.craftcms.com/api/v3/craft-controllers-entriescontroller.html#public-methods) that independently resolves and renders the template. That said, once it starts rendering the template, it's almost exactly the same context you'll get when the Entry is live, and requested via its normal URL.
  
  > Using an underscore in the template's path will make sure the template is not directly accessible, and is only rendered during a request that Craft has determined matches an Element (in your case, the event Entry), or via the Live Preview controller. Read more about how Craft routes requests, [here](https://docs.craftcms.com/v3/routing.html).
  
  > **Comments:**
  > **username_0**: If the entry has a `pending` or `expired` status, as my upcoming and passed events entries do, then Craft will not recognize the native `entry` variable in the template.  
  > **username_1**: I've just tested this with an Entry in the `pending` state, and Live Preview works as expected… can you confirm your `Template` path and `Entry URI Format`, as they appear your Section's settings, and post the contents of the template you expect to render the Entry?  
  > **username_1**: Also worth noting—pending and expired entries are not accessible via the front-end, when using Craft's normal routing system—but Live Preview will work just fine (as will a URL created with the "Share" button at the top of the Entry edit page)…  
  > **username_0**: Yes, I know pending and expired entries aren't accessible via the front-end, that's the whole reason I'm asking this question. Having Live Preview working doesn't do me any good if the front-end template does't also work. I need BOTH live preview AND the front-end to work for pending and expired entries.  
  > **username_1**: It sounds like the Pending and Expired fields are being used for something they're not well-suited for… if you just need your Events to have dates, I'd recommend using a custom field—you can still sort and filter based on custom date fields (like you can with `postDate` and `expiryDate`, and you won't have to subvert the automatic behaviors.  
  
  ---
  
  