6

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?

12

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...

  1. Uncheck the box which says "Entries in this section have their own URLs", and save.
  2. Setup a dynamic route. This is basically what the aforementioned checkbox was doing for you.
  3. Declare your route using the same pattern that you had previously setup in your section definition.
  4. 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.

  • Lindsey, can't you leave out steps 1-3 and only overwrite the automatically set entry var with step 4? – carlcs Aug 6 '14 at 7:32
  • 1
    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 Aug 6 '14 at 7:39
  • @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 Aug 6 '14 at 7:40
  • wow - this was more than I expected and very easy to do so! It works perfectly! thanks a lot!!! – outline4 Aug 6 '14 at 10:08
  • @outline4 Great, glad to help! – Lindsey D Aug 6 '14 at 18:30
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 %}
    <p>There are currently no upcoming events at this time.</p>
{% 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:

  1. 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.
  2. No wonky custom routing for what is really just a straight up typical channel of entries.
  3. 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.
  4. 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.

  • 1
    You are absolutely right! Using custom dates is the way to go! – outline4 Dec 5 '17 at 15:57
  • 1
    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 Dec 5 '17 at 15:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.