[Barry]

Hi Tomas,

If you could share the translation corrections in our translations forum that would be awesome and would help to ensure those changes are all integrated as quickly as possible 🙂

With regards to the user permissions issue, I’m not quite sure I understand.

Do you mean that some users are not permitted to use organizers created by other users? Do you know that this is the result of changes you made via WPFront User Role Editor?

[Barry]

Hi Nick,

We don’t have any specific recommendations but certainly if you choose to use WooCommerce along with our WooCommerce Tickets plugin you can potentially benefit from the raft of extensions that exist for that ecommerce solution 🙂

That said, I’m pretty sure most of the ecommerce engines supported by our ticketing plugins will have similar capabilities (whether built in or made available by adding a further plugin) and so the best thing to do is settle on the ecommerce engine that best fits your needs, whether that is WP E-Commerce, WooCommerce or something else and see what’s available in terms of marketing addons.

Does that help?

[Barry]

Hi Alexander,

I’m sorry for the inconvenience, but there is currently a compatibility issue with WooCommerce 2.3.x.

You can find a temporary fix over in this topic and of course we hope to release a substantive fix as quickly as we can 🙂

I hope that helps.

[Barry]

Hi JG,

Great question!

Our ticket emails are sent out through WooCommerce, which in turn uses functionality baked into WordPress.

Both of these provide opportunities to customize what is sent – not only in terms of the actual content but the recipient and any BCCs, etc.

WooCommerce for instance provide the woocommerce_email_headers filter hook which lets you modify the email headers (thus you could add one or more BCCs). To target the ticket email specifically, you could first listen out for the wootickets-send-tickets-email action being fired, so the code would take this sort of shape:

add_action( 'wootickets-send-tickets-email', 'listen_for_ticket_emails' );

function listen_for_ticket_emails() {
    add_filter( 'woocommerce_email_headers', 'add_ticket_bcc' );
}

function add_ticket_bcc( $headers ) {
    // We don't want to impact on other emails,
    // so remove the callback immediately
    remove_filter( 'woocommerce_email_headers', 'add_ticket_bcc' );

    // (...insert your code to add a BCC here...)

    return $headers;
}

That’s not going to anything by itself – you’ll need to expand it a little to actually add the BCC addresses, but it hopefully gives you a general outline you can build on 🙂

[Barry]

Hi dilyon,

So two settings in particular are relevant here:

• Clean up recurring events after
• Create recurring events in advance for

Can you tell me what each of those are set to? If for instance the second of those is set to 1 month, that might explain what you are seeing.

I’m wondering if it is possible to achieve a recurring event without as many instances on the backend. Currently I get a duplicate event for each of the days selected of the week.

Our current recurrence model works by generating a post table entry for each instance of the recurring event.

I can see why that may not be ideal in a few cases and there are probably alternative models that could be explored – and even implemented as a customization (a “virtual event” that shows on all event views but doesn’t depend on lots of post objects being generated, for instance) – but it’s rather beyond the level of support we can offer here on the forums to guide you through that.

That said, we’re always open to new ideas and feature requests and if you’d like to post some suggestions you can do so on our UserVoice page: that way, other users can show their support for your idea by “up-voting” it 🙂

 

[Barry]

Hi newburghrestoration,

I’m sorry you’ve been experiencing difficulties.

I think what we’ve got here are two different problems – one relating to recurring events and one to the presentation of maps on single event pages. Let’s deal with the recurrence problem here, but I would ask that you create a new support topic for the map issue as we try hard to stick to one issue per topic 🙂

#1- Recurring events link to an old blog post instead of the event page
#2- Recurring events change times, making future events spanning overnight, making the event appear 2 days. I have gone in manually trying to fix this, it never works.

Every now and again some peculiar issue like this crops up – and it has almost always been the result of a theme or plugin conflict.

Running through our standard troubleshooting steps in the regular fashion doesn’t always uncover anything useful in this situation because, in a sense, the damage may already have been done and so turning off all other plugins/switching to a default theme might result in no difference.

For that reason, I’d suggest repeating the troubleshooting steps but with a slight twist:

• Deactivate all other plugins except for The Events Calendar and Events Calendar PRO
• Switch to a default theme such as Twenty Fifteen
• Now create a new train of recurring events
• Do you see the same problem with those newly-created events?

Doing this on a live site may not be ideal, so you could alternatively do this on a test site (which could be as simple as a fresh WordPress installation in a sub-directory) – and start by adding only The Events Calendar and Events Calendar PRO and nothing else, then see if you can replicate there.

Does the yield any more information?

[Barry]

Hi!

The feed should still respect the setting in WP’s Settings → Reading screen – but please note it is the syndication feed setting that counts here, not the blog page count.

Does that help?

[Barry]

Hi saibotny,

When a view has no events to display it will indeed return a 404 Not Found status and this is intentional – because nothing has been found that we can show to the user.

That said, by itself our plugin does not add “Page not found” to the title tag or “Error 404 Page” as a title within the page itself – these are things that, in all likelihood, your theme is doing.

It’s possible to stop list views from returning 404s, though – just add this short snippet to your theme’s functions.php file:

add_action( 'tribe_events_parse_query', 'no_event_list_404s' );

function no_event_list_404s( $query ) {
	if ( $query->is_main_query() && $query->get( 'eventDisplay' ) == 'list' && ! $query->is_tax && ! $query->tribe_is_event_category ) {
		$query->is_post_type_archive = true;
		$query->queried_object       = get_post_type_object( TribeEvents::POSTTYPE );
		$query->queried_object_id    = 0;
	}
}

Does that help?

[Barry]

I’m glad it helped – and our apologies once again for the disruption.

[Barry]

Remember also you’re more than welcome to share the UserVoice link to your feature request (if either of you post one – it might allow others to find and up-vote the request 🙂 ).

[Barry]

Hi Chris,

Please note first of all we’re always open to new ideas and if you’d like to propose some new functionality you are welcome to do so over on our UserVoice channel – which has the added benefit of letting others show their support for your idea 🙂

OR next best would be to have it not show times when we select all day events (and then we’d put the times in the event details area).

You should be able to do this right now: ordinarily, if you mark an event as daking place all day, the times aren’t displayed anywhere.

Are you finding that isn’t the case (and can you link me to an example if so)?

Thanks!

[Barry]

Glad you got it working, hmendez.

You’re absolutely right, though, not everyone will be comfortable editing their theme’s functions.php file and in such a case you can download this plugin version of the fix instead. You only need the fix in plugin form or theme functions.php file form – not both!

Simply upload it through the usual WordPress plugin upload screen and activate: once our next WooCommerce Tickets release is rolled out, you can then deactivate and delete it.

[Barry]

Rolling back to an older version of WooCommerce is definitely a valid approach – and if you prefer to do that that’s absolutely fine.

We’re going to try and release a substantive fix for this problem as quickly as we can, but in the meantime if you prefer not to downgrade/cannot downgrade WooCommerce this short snippet – which is intended to be added, temporarily, to your theme’s functions.php file – should help:

// Compatibility fix to help run WooCommerce Tickets 3.9 with WooCommerce 2.3.x
if ( class_exists( 'TribeWooTickets' ) ) {
   // Form reference to ticket processing callback
   $wootickets = TribeWooTickets::get_instance();
   $callback = array( $wootickets, 'process_front_end_tickets_form' );

   // Switch to a later action
   remove_action( 'init', $callback );
   add_action( 'wp_loaded', $callback );
}

Please let me know if that doesn’t help and, again, rest assured that we’ll roll out a fix that doesn’t require a snippet to be added as quickly as we can.

[Barry]

Hi everyone,

I’m sorry you’ve had such a rough ride.

We’re actively investigating and I’ll do my best to keep you informed as we progress this issue: thanks so much for your support and patience in the meantime.

[Barry]

Hi Byron,

I seem able to set up multiple widgets filtering events by separate categories and it works as expected: can you point me to a live example of the issue and drop a note of how each is configured in here?

Thanks!

[Author]

Posts