Home Forums General Issues List posts by date picker with pagination Reply To: List posts by date picker with pagination

  • I am working on similar situation. Sorry, this got long. I thought that explaining it would lead me to a simpler solution but I’m still not seeing one.

    There is no easy way that I know of to have a url like and have a query the sorts all of the events in order and then jumps into the middle of the list somewhere where the current and future events are listed and then paginate both into the future and into the past.

    Sorry, I don’t really have any simple code that I can share.

    One option is to have a pre_get_posts filter. In this filter if the “page” query argument is not set then you attempt to find the page where the first current or future event is listed. Basically you have to do a query to get one post with a date >= today. Then you do a second query to get all of the posts sorted in the right order but return only an array of post IDs 'fields' => 'ids'. Then you get the index of this post in the array and set “page” query argument based on the results.

    $index = array_search($post_id, $query->posts);
    $page = intval($index/$posts_per_page)+1;

    I thought about this and discarded it. The reason why is that this only gives the page to show. The actual event that is current or future might be at the top, bottom or anywhere in between on this page depending on how many events there are and how many you are showing per page. Knowing the client I am working for this would not be acceptable. Not to mention that all of this additional querying will cause a performance issue if there are many events, which is likely to happen.

    Another option is the direction that I am going in, which is even more complicated.
    The first page is only going to show current and future events. I am adding a rewrite tag and rewrite rules for past events, in addition to all the date rewrite rules that I still need to work out because there will be date archive pages. In essence this will create two different urls for future vs past.

    add_rewrite_tag('%past%', '([^/]+)', 'past-events=');
    $rules = array(
        'rule' => 'event/past/?$',
        'rewrite' => 'index.php?post_type=event&past-events=1'
        'rule' => 'event/past/page/?([0-9]{1,})/?$',
        'rewrite' => 'index.php?post_type=event&past-events=1&paged=$matches[1]'
    foreach ($rules as $rule) {
      add_rewrite_rule($rule['rule'], $rule['rewrite'], 'top');

    Then I am going to have a pre_get_posts filter that looks for this argument and causes WP to do a different query based on if this is set or not. Future events will be shown in ASC order and past events will be shown in DESC order.

    Then I’m going to build a custom pagination function where if you are on the first page of the upcoming events then “Older Events” will be a link to /event/past/ and if you are on the first page of past events “Newer Events” will be a link to /event/ (the main archive) to show upcoming events.

    I’m still in the middle of this and my client is complicating things further because they want a flag so they can decide what events actually show in the past. For example they have webinars so they want these to appear to make it easy for visitors to find old webinars. They also want a month (year) select field so this needs to be able to search all events past and future by date (year/month/day), but only showing past events that are flagged in the past while showing all future events. In addition to this they will have events that span multiple months so if say an event goes from March to May and they choose April, then this event also needs to appear in the results. And on top of this they want to be able to search by keyword, which should also show past and future events but past events must be limited to those that are flagged while all current and future events should be shown. I’m still in the process of working out all of these different queries and it’s making my head hurt.

    Luckily I already had all the other framework for events built for another client, only in that case they never wanted to show past events so I didn’t need to figure this out.