Open now – “nothing found”
I’ve set hours for my listings however, when I use the filter for “open now” it keeps saying “Nothing Found” in the search menu. Any idea what I am doing wrong?
Fixed it myself! Needed to set my word press settings “site timezone”. Thank you!serhii 6 months, 1 week ago developer
Thanks for posting the solution!
@Serhil – I am having trouble with listings where the closing time is 12am.
For example, time in my current time-zone is 7:41pm. One of my listings is open from 5am and closes at 12am local time.
When I set the hours from 5am-12am and I select “open now” nothing shows up. However, when I set the hours from 5am – 1159pm, the listing appears. This appears to be a bug. Thoughts?
Closing past midnight
I’m having problems for any listing whose closing time is midnight or later, which is typical for bars, for instance. In such case, the closing time is usually in the early morning the next day, causing closing time to be lower than opening time.
Turns out such problem is a little more complex than it seems at first hand. I’m not sure how exactly the logic is implemented within HivePress Listing Hours, but this is how I understand resolving the problem.
Let’s say we have:
yesterday.open = yesterday's opening hour yesterday.close = yesterday's closing hour today.open = current day's opening hour today.close = current day's closing hour time = current time is_open = current opening state we need to determine
Then we can figure out current opening state with the following pseudo-code:
IF ( ( yesterday.close < yesterday.open ) // closes after (or at) midnight the day before AND ( time < yesterday.close ) // venue is still open ) OR ( ( time >= today.open ) // venue is already open AND ( ( today.close < today.open ) // closes today after (or at) midnight OR ( time < today.close ) // venue is still open ) ) THEN is_open = TRUE // the venue is currently open
Some limit cases (although pretty uncommon) could not be represented with the actual data structure, eg. a venue that would open at 2 am and close at 4 am (the next morning) could only be correctly represented in the current structure if it doesn’t re-open again the next day.
I know of some restaurants that present opening hours for lunch and dinner, with a gap in between them during which they are closed. That would imply being able to add multiple ranges for the same day. That would also allow solving the limit case exposed above. But I don’t think these are very important cases overall, and simply implementing the logic I suggest above would already be enough to fix the problem of closing time past (or at) midnight, without any change to the data structure.
Thanks for reporting this issue, I added it to the bug tracker. If you have the Opening Hours extension. The current condition is:
if($current_time>$opening_time and $current_time<$closing_time)
So this may require some extra logic to detect the time after midnight.
Thanks @ihor for the quick follow-up, this is really appreciated. I looked up the plugin code, and you are right, this will need some extra logic, since
WP_Meta_Querydoesn’t yet allow comparing two meta fields, which is needed to establish whether
<day>.close < <day>.open.
A workaround would be to pre-establish this condition, ie. at the moment the data is written to the database. The plugin could simply add a meta field (eg.
1) when closing time is lower than opening time, and remove it otherwise. Then the filter logic could be updated to reflect the suggested pseudo-code (in
includes/components/class-opening-hours.phpat line 143):
// Get day and time. $timezone = wp_timezone(); $date = new DateTime( 'now', $timezone ); $today = strtolower( $date->format( 'l' ) ); $date->sub( new DateInterval('P1D') ); $yesterday = strtolower( $date->format( 'l' ) ); $time = current_time( 'G' ) * 60 + (int) current_time( 'i' ); // Get meta query. $meta_query = array_filter( (array) $query->get( 'meta_query' ) ); // Add meta clause. $meta_query = [ 'relation' => 'OR', [ 'relation' => 'AND', [ 'key' => hp\prefix( $yesterday . '_night' ), 'compare' => 'EXISTS', ], [ 'key' => hp\prefix( $yesterday . '_to' ), 'value' => $time, 'compare' => '>', 'type' => 'NUMERIC', ], ], [ 'relation' => 'AND', [ 'key' => hp\prefix( $today . '_from' ), 'value' => $time, 'compare' => '<=', 'type' => 'NUMERIC', ], [ 'relation' => 'OR', [ 'key' => hp\prefix( $today . '_night' ), 'compare' => 'EXISTS', ], [ 'key' => hp\prefix( $today . '_to' ), 'value' => $time, 'compare' => '>', 'type' => 'NUMERIC', ] ] ] ]; // Set meta query. $query->set( 'meta_query', $meta_query );
$yesterdayare based on WP's
current_time(), which was originally used, so their internal calculation remains coherent to the original implementation. I tested this part of the code.
I'll get looking at where the meta fields are defined in the plugin and follow up here.
The only downside of this workaround would be that the opening hours for an affected listing will need to be resaved to be taken into account. Yet, it's better than not working at all.
Thinking through the issue again, I guess there would be a simpler — and more efficient — solution!
That is, instead of creating a new meta field, the issue could be solved by either allowing closing hours 24:00 and above (which would certainly look strange, eg. a bar closing at 27:00) or — more elegant — internally adding 24 hours to the closing time on save when it is below opening time, and substracting 24 hours back on display/edit.
That would still require an imbricated conditional with a lookup at yesterday’s closing time, but would drop 2 query conditionals on 2 distinct meta fields, compared to the one I just suggested — resulting in a less complex one. But that would also require a few modifications throughout the plugin code to take these extra 24 hours into account.
Thanks for your suggestions, I also was thinking about checking if the closing time is < than the opening one and then consider it “after midnight”, this will be implemented in the next Opening Hours update.
Thanks @ihor! In my research, I have found this pretty savvy hack that would allow comparing two meta fields in a single query, that might also be a quick and efficient alternative:
Thanks for sharing, saved it 🙂
You must be logged in to reply to this topic.