[Philip]

I’m replying to this ticket

A client raised this with us today, so I’ve spent the afternoon working out what was going on and have come up with the following:

The Ticket_Object::date_in_range($datetime) method, when given a GMT/UTC timestamp will, correctly, convert the timestamp to a DateTime object with the timezone of the event being checked.

The code that calls the date_in_range method however passes in a timestamp that is adjusted to the current WordPress timezone setting. For example if you have a WordPress timezone setting of GMT+0100, then 3600 will be added to the return value of current_time(‘timestamp’). This means the date_in_range method is checking against the wrong time and so tickets won’t show/hide at the correct times.

See https://developer.wordpress.org/reference/functions/current_time/ for details on the current_time function.

The fix is to simply pass a proper timestamp (i.e. “in GMT”), to do this can you pass a second parameter to current_timestamp. Alternatively, since date_in_range defaults to checking against the current time, you can pass ‘now’ or no value for $datetime.

events-tickets-plus/src/Tribe/Commerce/WooCommerce/Main.php:1283

-if ( ! $ticket->date_in_range( current_time( 'timestamp' ) ) ) {
+if ( ! $ticket->date_in_range( 'now' ) ) {

events-tickets-plus/src/views/wootickets/tickets.php:75

-if ( $ticket->date_in_range( current_time( 'timestamp' ) ) ) {
+if ( $ticket->date_in_range( 'now' ) ) {

I haven’t checked but I am guessing there are other parts of the codebase that incorrectly call this date_in_range method.

Please note: I don’t work for Tribe and have only tested the above changes in my own environment (where the WordPress timezone and Event timezone are always the same).

[Philip]

As of WooCommerce 3.0; visibility is stored as a taxonomy term instead of post meta. Try this instead.

function tribe_events_woo_change_visibility( $ticket_ID ) {
	if ($product = wc_get_product($ticket_ID)) {
		$product->set_catalog_visibility('hidden');
		$product->save();
	}	
}

Note: I am not affiliated with Modern Tribe/The Events Calendar.

[Philip]

We are having the same problem.

The order form shows once for each ticket on the page plus once for the page as a whole.

@Andras In your case I’m assuming there is only one ticket purchased – try purchasing more and see if the order form shows up more times.

The form is added via a the_content filter in the Tribe__Tickets__Tickets class:
src/Tribe/Tickets.php#L368

The problem occurs in event-tickets-plus/src/views/tickets-plus/orders-tickets.php#L77
For each ticket/attendee, that line of code is creating a new instance of $attendee[‘provider’] (in this case Tribe__Tickets_Plus__Commerce__WooCommerce__Main) which is a subclass of the Tribe__Tickets__Tickets class above.

This causes a new hook to be registered for each ticket/attendee and thus an extra order form each.

Tribe__Tickets_Plus__Commerce__WooCommerce__Main/Tribe__Tickets__Tickets are supposed to be Singletons so I’m not sure why they even have public constructors – but the fix is to load the singleton rather than a new instance.

If you copy event-tickets-plus/src/views/tickets-plus/orders-tickets.php to yourtheme/tribe-events/tickets-plus/orders-tickets.php and replace lines #76-79 with the following it should fix it:

if ( class_exists( $attendee['provider'] ) && is_callable( array( $attendee['provider'], 'get_instance' ) ) ) {
	$provider = call_user_func( array( $attendee['provider'], 'get_instance' ) );
	$price = $provider->get_price_html( $attendee['product_id'], $attendee );
}

It seems to work for me – but I would appreciate some input from Tribe regarding whether this has any unforeseen consequences and a fix in the next version.

This will leave you with the one form – as for removing that one also on the ‘My tickets’ page I haven’t found a way yet, but you should definitely be able to hide it with css, maybe something like this:

body.page-template-your-template  #tribe-events-content.tribe-events-single + .cart {
    display: none;
}

That should work as the cart form follows directly after the list of tickets/attendees.

• This reply was modified 9 years ago by Philip.

[Philip]

Thanks Trisha.

I think my original suggestion of only calling check-in for the relevant module is probably the better approach (assuming there are no side effects) – no point of the RSVP module doing anything if it is a WooTicket event.

[Philip]

Nope I just wanted this fixed.

[Philip]

This reply is private.

[Philip]

This reply is private.

[Philip]

Hi that’s great but you’ve also removed the non Events Calendar Pro ones that we were planning on renewing…
e.g. Event Tickets Plus

We only wanted the empty Events Calendar Pro ones removed.

[Philip]

We are having the same problem. 2 sites with Events Calendar Pro. One with iCal Importer attempting to import from the other.

I believe I have narrowed down the problem to the following.

Events Calendar outputs DTSTART/DTEND with a timezone e.g.

DTSTART;TZID="UTC+0":20160301T020000
DTEND;TZID="UTC+0":20160301T150000

However the iCal parsing library in iCal Importer (iCalcreator) does not support this format.

The values are passed in to iCalDATEproperty::__construct('DTSTART', ';TZID="UTC+0":20160301T020000')
Which eventually calls iCalPropertyFactory::manageTheDATE_str(';TZID="UTC+0":20160301T150000'), which doesn’t know how to handle a date of that format so simply calls strtotime().

This results in events with dates such as 19700101T010000Z and so do not pass the start date search giving you the aforementioned error message.

• This reply was modified 10 years ago by Philip. Reason: Formatting

[Author]

Posts