I’m no expert but it looks like this is the issue….
<!--<pre>Array
(
[meta_key] => end_date
[meta_compare] => >
[meta_value] => 2010-06-08
[orderby] => sac_posts.post_date DESC
[order] => DESC
[showposts] => 99
[page_id] => 7
[posts_per_page] => 5
[comments_per_page] => 50
)
</pre>-->
Thinking out loud here, but shouldn’t the query be setting the orderby to meta_value, so it’s ordered by the date set there..
There’s clearly some issue with that start date value anyhow, it’s got an extra DESC in it..
I can’t do anything to get rid of that. I have tried all sorts of different params going into it: ‘date’, ‘meta_value’, etc also tried deleting it. But nothing changes the value. When I delete it is comes in to the bottom of the list so I assume this means it is being picked up from WordPress and not from anything in the page.
The other strange thing is that it doesn’t matter if I change ‘order’ to ‘ASC’ it still reads ‘DESC’. So it would appear that I can’t amend order or orderby for these args in this page. I can change these on the get_posts queries on the homepage. Perhaps it is just because this is running from index.php?
As a work around I guess that I could use the query posts to filter the events according to their end date and then run a get_posts to sort them.
this is what I have on the homepage (static page) to show the coming events
?php
$now = strtotime('now');
$str_today = date('m/d/Y');
$my_now = date('Y-m-d');
$start = $end ='';
$end = $my_date = get('end_date');
$args = array(
'meta_key' => 'end_date',
'meta_compare' => '>',
'meta_value' => $my_now,
'orderby' => 'start_date',
'category_name' => 'Events',
'order' => 'ASC'
);
$events = get_posts($args);
print '<!--<pre>';
print_r( $args );
print '</pre>-->';
if(is_array($events) && count($events) > 0) :?>
<?php foreach ($events as $post) :
setup_postdata($post);
$start = $my_date = get('start_date');
$end = $my_date = get('end_date');
$cost = get_post_meta($post->ID,'price',true);
if ($end > $str_today ) {
?>
and this is the result of the print:
<!--<pre>Array
(
[meta_key] => end_date
[meta_compare] => >
[meta_value] => 2010-06-09
[orderby] => start_date
[category_name] => Events
[order] => ASC
)
</pre>-->
exactly what I want for the query_posts arguement on the what’s on pages (index.php)except that ‘category_name’ should be passed into the query from the page.
Ok have been running some simple tests and i think you were right, there is an issue with the array merge..
Can you tell me what a typical URL will look like that queries that events page, ie. what parameters are being passed into the URL.. or if you can show me the code that deals with setting up the queries to that page even better (ie. do you have some form of search that submits to the event’s page? if so, can i see the code associated so i have a good idea of the query variables you’re passing around).
Once i know that, i can test for it and write something more appropriate for you..
At the moment it is simply geared around categories (no site search at the moment…). So the main what’s on page is set as the site’s blog page (http://www.sidcotartscentre.com/?page_id=7) and then any of the categories under that just pass in the cat id (http://www.sidcotartscentre.com/?cat=3). But I do plan to build a search feature in using drop downs and free text (?s=) I guess – I need more time to be able to play with that!!
…is that what you mean?
Aren’t both the above two URLs handled by different template files though, presumably the page is handled by page.php and the categories by category.php or index.php depending which exists for your theme?
As far as i can currently test, the code works without merging the array, which is why i asked about what kind of query variables will be coming into the page, if any… i can write something else for the page, but if there’s other variables coming into the page, then i’d rather account for them now than have to re-write the code again.
So is this page set as your posts page? Or as a front page?
Just trying to get a little more clarity of how you have things configured..
Sorry, I should have explained better. They are both handled by the index.php. Page_id=7 is the what’s on page that is set as the posts page in wordpress settings.
Which file are you placing all the aforementioned code into?
It is going into index.php
Right i think understand how you’re using the code, and where, etc.
Just one more question…
So you’re using a page both as the posts page and as an events page, would it not be easier to have two seperate pages (one for regular posts, one for events)?
Or are you not using posts in the traditional sense? (ie. you have no need for regular posts)
At the moments the only posts are events (although I have now been asked to included press information which will probably form their own category of posts). So yes at the moment only posts are events.
Perhaps a conditional statement to check if the events page has been queried would be sufficient.
if( is_page('7') ) {
// YOUR CODE
}
The index.php should then only run that query when viewing the events page.
You’d then not have to worry about preserving query vars for other views, ?cat=x, ?tag=x etc..
Again, sorry, it doesn’t look like I’ve explained it well at all!
The what’s on page shows all of the events (currently the only posts). These event post are in a category called ‘events’. Underneath this there are subcategories or ‘exhibitions’, ‘classes’, ‘family activities’, etc. The menu shows this second layer of category so that the user can click to find specifically music events. In the same way the posts are tagged so that a user could find similar events. This was why I used the main index.php to filter according to the end_date > now so that for all of these types of navigation I only showed events that hadn’t finished.
I think the ordering problem is due to this..
'orderby' => 'start_date',
Where is start_date coming from? It’s not a valid value for orderby.
You should use this to sort by meta(custom field) value..
'orderby' => 'meta_value',
Else you’ll need to explain how start_date works, because i can’t see how that will operate unless you’ve modified the wp_query class(via a posts_where filter, or similar) to accept a new orderby parameter..
