0

I'm currently building a site where I need to filter/order/query a custom post type by date data. I can't use the post published date for this, but can't decide what would be the most efficient way to attach this to a post for further querying/filtering on the front-end of the site.

As far as I can see my options are either:

1 - Store as custom field (probably in UNIX timestamp format) I can see that this would work, but I have concerns about scalability with this as the number of posts grows (into thousands potentially) - as all posts would have to be queried to search/filter by custom field... this doesn't seem like it would be too efficient.

2 - Store as a taxonomy (Year->month->day) I have a custom plugin I've written to pre-populate terms of a taxonomy, so have no problems modifying this a-little to setup the terms ready for Year (parent) -> month (child) -> day (grand-child) for a few years to come! In my mind this seems like it would build more efficient queries in the future? At face-value this feels a-little strange to do it like this, but I think it would produce much more efficient queires and filtering of posts on the front-end of the site, as it would be the taxonomy tables that are queried rather than custom fields in ALL of the posts.

Is this overkill? I'd very much appreciate opinions on what would work best. I should mention that from an admin point of view I have a custom post creation/editing process, so this doesn't effect my decision. I'm really just trying to figure out the best way to attach custom date data to custom post type and query against it (with certainly hundreds, if not thousands of posts!!)

2
  • Have you already seen date_query?
    – kaiser
    Commented Jan 14, 2014 at 10:31
  • WP_Query is a powerful beast that's for sure sir! I'm pretty sure that date_query is just for published/edited - I'm using this for something else and need to attach a seperate date entry sadly.
    – Jonnyauk
    Commented Jan 14, 2014 at 10:40

2 Answers 2

0

I would store as a custom field, like you say as a timestamp or ISO 8601 (YYYY-MM-DD). That way you can leverage WP_Query's Custom Field Parameters for queries within your theme files.

For instance:

// Get posts where the custom field is less than the current time

$foo = new WP_Query(array(
  // other query vars...
  'meta_query' => array(
    array(
      'key' => 'date_custom_field',
      'value' => time(),
      'compare' => '<'
    )
  )
));
3
  • That's for the tip - WP_Query is getting really powerful with these extra query parameters, it's great ;) However, I wonder if storing as a taxonomy might be more efficient rather than querying against 100/1000's of posts (due to the way that taxonomies/relationships are stored in separate tables away from the posts table?)
    – Jonnyauk
    Commented Jan 14, 2014 at 10:42
  • Using a taxonomy could work however the query for this would result in a few joins, so I'm not sure what would be the best for performance without benchmarking. "Semantically" post meta seems favourable to me over taxonomies, and if you're truly concerned over performance then implementing things like caching or even moving away from WordPress/PHP might be worth looking into.
    – Mike F
    Commented Jan 14, 2014 at 12:17
  • After thinking this over I think you are right on this - marked as correct answer cheers - I think with the extra query parameters along with some server caching this will work out best compared to a taxonomy ;)
    – Jonnyauk
    Commented Jan 14, 2014 at 12:52
0

If you have them saved as custom meta fields you could add this into your query:

'meta_key'       => 'field_name',
'orderby'        => 'field_name'
1
  • Thanks for the answer - your right, building the queries is no problem, my concerns are around performance... I believe that taxonomy based queries are much more efficient than custom field queries due to the WordPress database structure (and taxonomy tables/data storage/structure)... I could be wrong though!
    – Jonnyauk
    Commented Jan 14, 2014 at 10:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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