<p>I know Lindsey's answer is the accepted answer from like 4 years ago, but it's worth pointing out that it only applies if your events use <code>postDate</code> for when each event starts/ends.  But you don't need to do all that! Just use a custom datetime field for setting event start/end dates.</p>

<p>Create custom <a href="https://craftcms.com/docs/date-time-fields" rel="nofollow noreferrer">date/time fields</a> in your entries. Then you grab your event entries on the listing page like normal but you order by your custom field:</p>

<p><code>{% set upcomingEvents = craft.entries.section('mySection').order('customStartDate')</code></p>

<p>Then control them in the loop:</p>

<pre><code>{% for event in upcomingEvents if event.customStartDateField &gt;= now %}
    // event html
{% else %}
    &lt;p&gt;There are currently no upcoming events at this time.&lt;/p&gt;
{% endfor %}
</code></pre>

<p>Then on the details <code>_entry</code> page, you go about it like normal; the <code>entry</code> variable is auto populated for you.</p>

<p>There's also a more complex example on <a href="https://craftcookbook.net/recipes/better-events-listings" rel="nofollow noreferrer">Craft Cookbook</a> if you need something more complicated.</p>

<hr>

<p>There are multiple reasons and benefits for using custom date fields rather than going with <code>postDate</code>:</p>

<ol>
<li>You don't need to uncheck the box that says "Entries in this section have their own URLs". Instead, let Craft generate the entries' urls as usual.</li>
<li>No wonky custom routing for what is really just a straight up typical channel of entries.</li>
<li>You don't have to deal with the status; just leave it on the default "live" status and control the entry's visibility in the template based on if its start/end date is in the future or past related to the current date.</li>
<li>The UX of having a custom date/time field in the entry's tab (when editing the entry) rather than off to the side is arguably far better for the user/client.</li>
</ol>

<p>I get that the accepted answer answers the question in the title, but I found myself rethinking my approach to listing out events on a project I'm doing and realized the better way is to avoid using <code>postDate</code> altogether for this instead of trying to force it. Hope it helps someone else too.</p>

CC BY-SA 3.0
2017-12-05T15:57:23.140Z
You are absolutely right! Using custom dates is the way to go!
outline4
CC BY-SA 3.0
2017-12-05T15:58:27.610Z
I still leave the other answer as correct, since the answer is correct. But when dealing with future dates, or custom dates in general, I'd suggest you go down that route.
outline4
CC BY-SA 3.0
2017-12-04T03:33:02.860Z
2017-12-04T03:33:02.860Z
Ryan
<p>I'm assuming that when you defined your section, you checked the box which says this:</p>

<blockquote>
  <p>Entries in this section have their own URLs</p>
</blockquote>

<p>... and then filled out the relevant <strong>Entry URL Format</strong> and <strong>Entry Template</strong> values. The great thing about this technique is that it automatically populates the <code>entry</code> variable in your target template. Typically, this is the best way to go!</p>

<p>But there are occasions where this isn't the suitable solution. There are certain circumstances in Craft which, by default, can prevent non-active entries from being included. I suspect this is one of those situations.</p>

<p><strong>Here is what I would suggest instead...</strong></p>

<ol>
<li>Uncheck the box which says "Entries in this section have their own URLs", and save.</li>
<li>Setup a <a href="http://buildwithcraft.com/docs/routing#dynamic-routes">dynamic route</a>. This is basically what the aforementioned checkbox was doing for you.</li>
<li>Declare your route using the same pattern that you had previously setup in your section definition.</li>
<li><p>Within your template, manually set the <code>entry</code> value, based on the parameters passed through in the URL.</p>

<pre><code>{% set slug = craft.request.getSegment(2) %}
{% set entry = craft.entries.slug(slug).status(null).first %}
</code></pre></li>
</ol>

<p>Here's where this manual method differs from the automatic method... Specifying <code>null</code> as the status will return that entry <em>regardless</em> of what its status is. Otherwise, only an active entry could be returned.</p>

<p>Because you are now <strong>manually</strong> setting the <code>entry</code> value, you have enough control to specify that you <strong>really do want this entry</strong>, despite the fact that it's not currently active.</p>

CC BY-SA 3.0
2014-08-06T07:32:18.813Z
Lindsey, can't you leave out steps 1-3 and only overwrite the automatically set entry var with step 4?
carlcs
CC BY-SA 3.0
2014-08-06T07:39:28.197Z
OK, you probably suggest 1-3 because of performance reasons, so that there's no DB queries for an entry model not used at all, right?
carlcs
CC BY-SA 3.0
2014-08-06T07:40:52.673Z
@carlcs Yeah, no need to confuse Craft. If you're going to manually set the route, you should turn off the automated route settings.
Lindsey D
CC BY-SA 3.0
2014-08-06T10:08:55.237Z
wow - this was more than I expected and very easy to do so!  It works perfectly! thanks a lot!!!
outline4
CC BY-SA 3.0
2014-08-06T18:30:36.463Z
@outline4 Great, glad to help!
Lindsey D
CC BY-SA 3.0
2014-08-06T04:28:02.177Z
2014-08-06T04:28:02.177Z
Lindsey D
<p>I have an event site with dates in the future and past.  </p>

<p>I know how to display future entries as a listing: </p>

<pre><code>{% set entries = craft.entries.section('mySection').status('pending') %}
</code></pre>

<p>But how do you display an entry with status "pending" on the "_entry" template?<br>
In my case nothing displays?</p>

<date><postdate>
How can I display a "pending" entry in my "_entry" template?
# How can I display a "pending" entry in my "_entry" template?

(Asked by: username_0 on 2014-08-05)

I have an event site with dates in the future and past.  
I know how to display future entries as a listing: 
{% set entries = craft.entries.section('mySection').status('pending') %}

But how do you display an entry with status "pending" on the "_entry" template?
In my case nothing displays?

**Tags:** date, postdate


---

## 2 answers

### Answer by username_2 on 2014-08-06. Score: 13 | Accepted answer

I'm assuming that when you defined your section, you checked the box which says this:

Entries in this section have their own URLs

... and then filled out the relevant Entry URL Format and Entry Template values. The great thing about this technique is that it automatically populates the entry variable in your target template. Typically, this is the best way to go!
But there are occasions where this isn't the suitable solution. There are certain circumstances in Craft which, by default, can prevent non-active entries from being included. I suspect this is one of those situations.
Here is what I would suggest instead...

Uncheck the box which says "Entries in this section have their own URLs", and save.
Setup a dynamic route. This is basically what the aforementioned checkbox was doing for you.
Declare your route using the same pattern that you had previously setup in your section definition.
Within your template, manually set the entry value, based on the parameters passed through in the URL.
{% set slug = craft.request.getSegment(2) %}
{% set entry = craft.entries.slug(slug).status(null).first %}


Here's where this manual method differs from the automatic method... Specifying null as the status will return that entry regardless of what its status is. Otherwise, only an active entry could be returned.
Because you are now manually setting the entry value, you have enough control to specify that you really do want this entry, despite the fact that it's not currently active.

> **Comments:**
> **username_3**: Lindsey, can't you leave out steps 1-3 and only overwrite the automatically set entry var with step 4?  
> **username_3**: OK, you probably suggest 1-3 because of performance reasons, so that there's no DB queries for an entry model not used at all, right?  
> **username_2**: @username_3 Yeah, no need to confuse Craft. If you're going to manually set the route, you should turn off the automated route settings.  
> **username_0**: wow - this was more than I expected and very easy to do so!  It works perfectly! thanks a lot!!!  
> **username_2**: @username_0 Great, glad to help!  

---

### Answer by username_1 on 2017-12-04. Score: 1

I know Lindsey's answer is the accepted answer from like 4 years ago, but it's worth pointing out that it only applies if your events use postDate for when each event starts/ends.  But you don't need to do all that! Just use a custom datetime field for setting event start/end dates.
Create custom date/time fields in your entries. Then you grab your event entries on the listing page like normal but you order by your custom field:
{% set upcomingEvents = craft.entries.section('mySection').order('customStartDate')
Then control them in the loop:
{% for event in upcomingEvents if event.customStartDateField >= now %}
    // event html
{% else %}
    There are currently no upcoming events at this time.
{% endfor %}

Then on the details _entry page, you go about it like normal; the entry variable is auto populated for you.
There's also a more complex example on Craft Cookbook if you need something more complicated.

There are multiple reasons and benefits for using custom date fields rather than going with postDate:

You don't need to uncheck the box that says "Entries in this section have their own URLs". Instead, let Craft generate the entries' urls as usual.
No wonky custom routing for what is really just a straight up typical channel of entries.
You don't have to deal with the status; just leave it on the default "live" status and control the entry's visibility in the template based on if its start/end date is in the future or past related to the current date.
The UX of having a custom date/time field in the entry's tab (when editing the entry) rather than off to the side is arguably far better for the user/client.

I get that the accepted answer answers the question in the title, but I found myself rethinking my approach to listing out events on a project I'm doing and realized the better way is to avoid using postDate altogether for this instead of trying to force it. Hope it helps someone else too.

> **Comments:**
> **username_0**: You are absolutely right! Using custom dates is the way to go!  
> **username_0**: I still leave the other answer as correct, since the answer is correct. But when dealing with future dates, or custom dates in general, I'd suggest you go down that route.  

---

