[Quentin]

Hi Cliff,

Yes, my response also includes the necessary template overrides to remove the optout checkbox. I understand CSS solutions in many cases are “good enough”, but in a case where you are potentially exposing user data on a public site without their knowledge, a CSS only solution is inadequate, and irresponsible on the part of Modern Tribe. At the very least your responses should include the CSS as well as PHP solutions, and encourage the PHP ones primarily, as they are the most responsible fixes for the end user.

The whole rollout of this feature has completely ignored privacy concerns and made it more difficult than it should be to fix. Especially if you upgraded before the 4.1.2 “fix” release that turned it off by default. I have several sites using ETP, and with the upgrade to 4.1.1 we had hundreds of events automatically exposing user information on public pages without consent. That kind of oversight just isn’t ok.

[Quentin]

There are a few threads with this issue. I have provided a solution here: https://theeventscalendar.com/support/forums/topic/taking-off/#dl_post-1104882

[Quentin]

The CSS solutions being offered in these threads is a poor band-aid. In the interest of providing a better, more appropriate solution than just visually hiding these things, I am going to link to my answer on another thread that, I believe, offers a more complete and appropriate solution.

https://theeventscalendar.com/support/forums/topic/taking-off/#dl_post-1104882

[Quentin]

The CSS solution offered in this, and other threads, is a poor solution to the problem. It may hide the field, but it doesn’t actually change the option, so, now the user unknowingly gives permission to have their information listed on the front end if the attendee list option in the backend is set incorrectly.

Honestly, this whole front-end attendee list “feature” has been embarrassingly poorly rolled out. It should have NEVER been on by default, and if the option is not checked in the event editor, the checkbox shouldn’t even be on the page. Hiding it by CSS is a really embarrassing solution to continue to put out as well.

The real solution requires adding a filter, and editing a template file.

To hide the attendee list on all events, add the following line to your functions.php file:

add_filter('tribe_tickets_plus_hide_attendees_list', '__return_true');

To hide the checkbox on the tickets form, you will need to copy the relevant template files to your theme, depending on which ecommerce plugin you use (eddtickets, shopptickets, wootickets, wpectickets):

Copy from: wp-content/plugins/events-tickets-plus/src/views/{your_ecommerce_plugin}/tickets.php
Copy to: wp-content/themes/{your_theme}/tribe-events/{your_ecommerce_plugin}/tickets.php

Then edit the following block (line numbers vary, depending on your plugin)

Remove the following lines:

					echo
					'<tr class="tribe-tickets-attendees-list-optout">' .
						'<td colspan="4">' .
							'<input type="checkbox" name="optout_'  . esc_attr( $ticket->ID ) . '" id="tribe-tickets-attendees-list-optout-edd">' .
							'<label for="tribe-tickets-attendees-list-optout-edd">' .
								esc_html__( 'Don\'t list me on the public attendee list', 'event-tickets' ) .
							'</label>' .
						'</td>' .
					'</tr>';

					include dirname( __FILE__ ) . '/../meta.php';

If you are using the option to collect user information at registration, you will need to change the following line:

include dirname( __FILE__ ) . '/../meta.php';

to
include get_template_directory() . '/tribe-events/meta.php';

if you use a child theme, it will be:
include get_stylesheet_directory() . '/tribe-events/meta.php';

You will also need to copy the wp-content/plugins/events-tickets-plus/src/views/meta.php file to wp-content/themes/{your_theme}/tribe-events/meta.php to load the event attendee fields. Alternatively, you could remove the include line altogether, and just copy/paste the contents of meta.php into that place in the tickets.php template file.

I think the very best solution is to offer a global “Enable/Disable front-end attendee list” not only a per event option.

I hate to be harsh, but The Events Calendar team should really be embarrassed for how they have handled this, and how many site owners were unexpectedly exposing their users publicly for event registrations.

[Quentin]

Actually, after a bit more digging in that same query. I was able to simply change the priority of our pre_get_posts action to add our meta_query after your built-in pre_get_posts filter (priority 50) and after adding back in some date and order settings to the query seems to have solved our issue.

Thanks.

[Quentin]

Hi Brian, thanks for the response.

I’ve tried doing a pre_get_posts modification and custom meta_query, using a custom query_var we have registered in our theme.

So, a category url (domain.com/events/category/category-name/) can have a new query_var attached (?class_location=mexico) and then the meta_query is adjusted as follows:

/*
 * Set filters for Country Taxonomy
 */
$country_filter = get_query_var('class_location', false);

if ($country_filter && $country_filter != '') {
	
	$country_name = ucwords( str_replace('-', ' ', $country_filter) );
	$venue_args = array(
		'post_type' => 'tribe_venue',
		'meta_key' => '_VenueCountry',
		'meta_value' => $country_name,
		'fields' => 'ids',
		'orderby' => 'ID',
		'order' => 'ASC',
		'posts_per_page' => -1
	);

	$venue_ids = get_posts($venue_args);

	$meta_query = array(
		'relation' => 'OR',
		array(
			'key' => '_EventVenueID',
			'value' => $venue_ids,
			'compare' => 'IN',
		)
	);
	
	$query->set( 'meta_query', $meta_query );
}			
			

When I run the appropriate SQL that this query results in, I do receive the appropriate events matching the query, but when I run this on an events page, I receive the following error:

Unknown column ‘EventStartDate’ in ‘order clause’

On a category view without the custom meta_query added, the EventStartDate is never used in the SQL query. I have compared the WP_Query passed with and without the query_var added, and they are identical, except for the meta_query addition. But the SQL queries differ.

Without query_var:

SELECT SQL_CALC_FOUND_ROWS DISTINCT mat_posts.*, MIN(mat_postmeta.meta_value) as EventStartDate, MIN(tribe_event_end_date.meta_value) as EventEndDate FROM mat_posts INNER JOIN mat_term_relationships ON (mat_posts.ID = mat_term_relationships.object_id) INNER JOIN mat_term_relationships AS tt1 ON (mat_posts.ID = tt1.object_id) INNER JOIN mat_postmeta ON ( mat_posts.ID = mat_postmeta.post_id ) LEFT JOIN mat_postmeta as tribe_event_end_date ON ( mat_posts.ID = tribe_event_end_date.post_id AND tribe_event_end_date.meta_key = '_EventEndDate' ) WHERE 1=1 AND mat_posts.ID NOT IN (203,9268,9270,9272,9274,10526,11124,12148,12637,12980,14692,15666,15671,15618,15973,16023,12388,16370,16604,16607) AND ( mat_term_relationships.term_taxonomy_id IN (6) AND tt1.term_taxonomy_id IN (6) ) AND ( mat_postmeta.meta_key = '_EventStartDate' ) AND mat_posts.post_type = 'tribe_events' AND (mat_posts.post_status = 'publish' OR mat_posts.post_status = 'private') AND (mat_postmeta.meta_value >= '2016-01-08 12:26:23' OR (mat_postmeta.meta_value <= '2016-01-08 12:26:23' AND tribe_event_end_date.meta_value >= '2016-01-08 12:26:23' )) GROUP BY mat_posts.ID ORDER BY EventStartDate ASC, mat_posts.post_date ASC LIMIT 0, 10

With query_var:
SELECT SQL_CALC_FOUND_ROWS mat_posts.ID FROM mat_posts INNER JOIN mat_term_relationships ON (mat_posts.ID = mat_term_relationships.object_id) INNER JOIN mat_postmeta ON ( mat_posts.ID = mat_postmeta.post_id ) WHERE 1=1 AND ( mat_term_relationships.term_taxonomy_id IN (6) ) AND ( ( mat_postmeta.meta_key = '_EventVenueID' AND CAST(mat_postmeta.meta_value AS CHAR) IN ('12972','15992') ) ) AND mat_posts.post_type = 'tribe_events' AND (mat_posts.post_status = 'publish' OR mat_posts.post_status = 'private') GROUP BY mat_posts.ID ORDER BY EventStartDate DESC, mat_posts.post_date DESC LIMIT 0, 20

You’ll see in the default Query that there is a definition of the EventStartDate field, but not in the second, and within the passed WP_Query, the meta_query is the the only thing that has changed. I’m wondering if this is something that you have an action or filter linked to that we can leverage to get the correct SQL query passed as necessary in order to be able to make custom meta_query additions to the WP_Query on event pages.

I have dug around a bit in the source code of the plugin, and have, I believe, determined where these are being added in the SQL Query (Tribe__Events__Query line 406) but I want to make sure that this is the appropriate filter (tribe_events_query_posts_fields) to utilize to try and get this meta_query injected as necessary.

[Quentin]

Hi George,

Yes, my setup matches those instructions. I believe this may be specific to having Woocommerce Products translatable, but not tickets. We don’t need to have both translatable, just Products, but it looks like the Tickets are relying on that Product attachment when querying the DB for display. Not 100% sure where, but I may have time to dig further over the next couple of weeks.

[Quentin]

After some deep digging in the queries that are being used to load the attendees table, I have actually determined that this is a separate issue related to WPML.

I will open a new, more appropriate, thread.

[Quentin]

This is a significant bug that is actually affecting the Preview capability of other custom post types as well. I definitely would like to request that this bug be fixed a lot sooner than the scheduled November release, especially given the apparent simplicity of the fix.

[Quentin]

Thanks for the response Barry. It does already work correctly with manually edited orders, and it does show cancelled orders, but I think where our case is unique is that we could have one person pay for 3 tickets in one order, but we can’t selectively cancel a subset of that order (by changing the quantity in the completed order), and have it appropriately reflected in the attendee list.

It’s certainly something we can do as a customization, to save some digging time, any chance there is a hook or action that we can tie into to add/update attendee list information (name/email/user id)?

[Quentin]

Barry, we have this same need, for some event/training registrations. Would you have any direction on how to appropriately update the attendees table with the appropriate information based on just using additional checkout fields? Adding the fields to get the additional name/email/contact info at checkout is relatively trivial, but having it appropriately populate the attendee table is pretty integral to this working in any useful manner.

Alternatively, is there any way to possibly set an option in the ticket creation screen to limit tickets to single purchase only, so only one ticket could be purchased, in order to better control the appropriate attendee information.

[Quentin]

Casey, thanks for the follow up. I am sorry I didn’t respond with a resolution sooner, yes the 3.5.1 hot fix did fix my issue. Thanks again.

[Quentin]

Mike, you can add that +1 to the suggestion here: http://tribe.uservoice.com/forums/195723-feature-ideas/suggestions/5575496-specific-roles-capabilities-defined-for-events-cal

Thanks for your responses Barry. Appreciated.

[Quentin]

Sorry for the lack of a reply, I guess I didn’t check the notification checkbox to know of a reply to this thread.

Is there any plan to separate out the Attendees Table capabilities to allow us to have an events only role without giving deeper access to other posts?

[Quentin]

Thanks for the update Leah. The project I was working on for this actually brings up a related question, hopefully it’s not too bad to post it here; is it at all possible to set up multiple ticket email templates? So that different ticket types or different event categories can have different templates? I have poked around, and it looks like it would only be possible with some hefty hacking of core files, unless I’m missing something somewhere.

If it’s not possible is there somewhere to make feature requests?

[Author]

Posts