[Adam]

Found the issue!

It was in a template override after all, but it was my code at fault not yours.

I do some weird stuff re categories, and co-incidentally around the time of the 4.6 beta, I had added a new category that needed referencing in the override – which I forgot to add. Adding it fixed the problem.

So I assumed (I know, I know) that the 4.6 beta (and RC) was the likely cause as that (in my head) was what had changed.

However, it would still be good if you can tell me if any of my listed templates should be updated following 4.6?

Thanks

[Adam]

Hi Cliff

I understand that providing the snippet was more than you guys would usually do, and I was grateful for it. And I’m sure the update is fundamentally sound.

I don’t use easy digital downloads. I’m a developer myself (though PHP is not my forte) and I am quite happy to troubleshoot this myself.

I appreciate there are a multitude of plugins / themes out there, and any of them could cause a conflict, and I’ll definitely look further into that.

However, I think the more likely cause is probably related to one or more overrides I have in place. So all I’m really after from you guys is guidance or a pointer in terms of that. Basically, if your snippet needed updating after 4.6, are there any of your plugin php files (that I have overridden) that have a newer 4.6 version that I need to use instead for my overrides?

I’ve looked at one and there’s no version number in the template, so bar manually doing a compare, I was hoping you could simply tell me what files, if any (from those I listed in my previous reply), were updated in 4.6? That way I know which overrides need the newer base version copied to my child theme?

If there aren’t any that were updated as part of 4.6, then it looks like I’ll need to go down the plugin / theme conflict route…

Thanks

[Adam]

Hi Cliff,

1) Thanks for pointing out there was an updated script – how would I know in the future to check if scripts have been updated?

2) Ok – so I replaced those 2 functions with the updated ones – same result I’m afraid, the Attendees back-end screen is blank. If I comment out the 2nd of the 2 functions, as below:

// add_filter( 'the_title', 'cliff_filter_wooticket_titles_in_shop_and_search', 10, 2 );

Then the Attendees screen appears correctly – so am I missing something? I do have a few tribe overrides here and there, but when we were figuring this stuff out (resulting in using this script), you didn’t think those overrides were an issue at the time. Just mentioning them again for completeness – they are:

/bb-theme-child/tribe-events/modules/meta/details.php

/bb-theme-child/tribe-events/month/mobile.php
/bb-theme-child/tribe-events/month/single-event.php
/bb-theme-child/tribe-events/month/tooltip.php

/bb-theme-child/tribe-events/tickets/email.php

/bb-theme-child/tribe-events/widgets/list-widget.php

/bb-theme-child/tribe-events/wootickets/tickets.php

Thanks

[Adam]

Hi

Yes it works fine if I use the parent theme. So I went back to the child theme and started off by commenting out the code I had from Cliff recently (2 functions). Commenting out one of them fixes the issue.

The code in question worked prior to 4.6 – and is below…

/**
 * Event Tickets Plus - WooCommerce Tickets: Filter Visible tickets to have a
 * post title of "Tickets for {Event_Name}" while in Shop or Search.
 *
 * We filter the ticket name in Shop and Search so that an event with 2 tickets
 * (e.g. Lower-Level and Balcony) but only 1 Visible (e.g. Balcony) does not
 * appear simply as "Balcony" in the Shop and then customers are looking around
 * within the Shop for a different type of ticket for the event (e.g. Lower-
 * Level).
 *
 * @see  cliff_one_wooticket_visible_per_event
 *
 * @param $title
 * @param $id
 *
 * @return string
 */
add_filter( 'the_title', 'cliff_filter_wooticket_titles_in_shop_and_search', 10, 2 );
function cliff_filter_wooticket_titles_in_shop_and_search( $title, $id ) {
	if (
		! is_admin()
		&& function_exists( 'is_shop' )
		&& function_exists( 'wc_get_product' )
		&& (
			is_shop()
			|| is_search()
		)
		&& wc_get_product( $id )
		&& class_exists( 'Tribe__Tickets_Plus__Commerce__WooCommerce__Main' )
	) {
		// Search for the non-deprecated custom field.
		$event_id = (int) get_post_meta( $id, Tribe__Tickets_Plus__Commerce__WooCommerce__Main::ATTENDEE_EVENT_KEY, true );
		if ( ! tribe_is_event( $event_id ) ) {
			// Search for the deprecated custom field, from Tribe__Tickets_Plus__Commerce__WooCommerce__Main::$event_key
			$event_id = (int) get_post_meta( $id, '_tribe_wooticket_for_event', true );
		}

		if ( tribe_is_event( $event_id ) ) {
			$title = esc_html( get_the_title( $event_id ) ); 
		}
	}

	return $title;
}

So I guess it calls upon something that has changed in 4.6?

Thanks

[Adam]

Hi Courtney

I disabled all the plugins, it wasn’t that. However if I change theme to twentyseventeen it works, so it looks theme related? It’s a Beaver Builder child theme. Any ideas?

All was working fine until went to 4.6 beta and then 4.6

Thanks

[Adam]

Yep, wasn’t looking for support as I know it’s beta. Just reporting it is
all.

🙂

[Adam]

Oh sorry – and re issue 1 I see the same applies to View Orders – i.e. shows blank screen.

[Adam]

This reply is private.

[Adam]

Thanks Cliff

That’s all good. ?

I’ll leave you alone now. Thanks!

(You can close this)

[Adam]

Apologies for the delay Cliff – I was waiting for your reply but must have missed the notification (sorry). It was only logging in that I realised you had replied (blush).

Ok that all makes sense…. except:

our plugin does this (only for tickets, not all Virtual products)

That also makes sense, but just wondering

1) Why you make tickets hidden by default (the snippet aside)? Would be nice to allow settings somewhere to toggle that option on/off (if I wasn’t using your snippet).

2) And to confirm, this snippet effectively switches that “hidden by default” off for all tickets and events (even if the event only has one ticket type)?

If yes, that’s fine – just confirming the snippet’s scope really.

Thanks again for all your help – it’s really been appreciated.

[Adam]

Ok thanks Cliff

That all makes sense bar the virtual bit. Why is that as it should be? Or
is that a woo setting that says don’t display virtual products in the shop
that I can turn off?

[Adam]

Hi Cliff,

Ok, I did all that and it made no difference.

So I looked at the code a bit deeper and realised that the hook used is an “after ticket saved” hook. I was testing on existing events and tickets – realised with a Eureka! that it’s only fired on new event tickets – which makes sense – d’oh!

So yes, that works – apologies for not realising sooner (blush). That really helped, thanks!

So – a couple of cheeky questions…

1) I guess for already set up events I just need to hide their older tickets manually (leaving just one as visible) in each case?
2) All tickets that are created are set as being “virtual” product in Woo, making them non-displayable in the shop. Unticking fixes it, but presumably I can add something to that code we just added to ensure “Virtual” is not set too at creation time?
3) In Woo we have the same categories defined as we have defined for events. Any simple way of when a ticket is created to set the ticket categories to match the event categories?

Thanks again Cliff!

[Adam]

This reply is private.

[Adam]

This reply is private.

[Adam]

Ok – finally got some time to have a play. I can see where you’re coming from Cliff.

One issue – In my case the event has 2 ticket types (for men and women) – but both ticket types still display in the shop? The differentiation you’re using is to only show the cheapest – and they both are. So I’m guessing that may be the cause?

The rest re title changing all looks clear enough.

[Author]

Posts