[Barry]

Hi Steve,

It does seem that our license messaging – in the context of multisite environments – could do with some adjustment: we’re sorry for any confusion and frustration it has caused you so far.

I’ll make sure that this is flagged for further attention however, in the interim, know that you can essentially ignore those warnings and the functionality of the plugins themselves will not be impeded.

One more quibble: apparently you require that both the free version AND the paid version remain activated. I have never seen a plug-in do this before. Not a big deal, but adds another bit of confusion on set-up.

That is indeed how things work – and is a side-effect of our modular design. Not all users, for instance, will extend The Events Calendar by installing Events Calendar PRO: some may wish only to add the features offered by Community Events, still others will want the functionality of Filter Bar and others yet may wish some combination of additional features.

You’re quite right, though, that the modular nature of our plugins (and the need to have a base plugin – in this case, The Events Calendar – in place) is perhaps not immediately apparent based on the information in our product pages alone: I’ll talk this over with the team and see what we can do.

If you have any further questions or concerns – especially if they relate to your license keys or plugin functionality – I would ask that you login and post them in our premium forum (this will simply help to ensure you get prompt and appropriate assistance from the team) 🙂

Thanks again for the feedback!

[Barry]

Hi Pekka,

I’m sorry to hear you have experienced issues and would also consider that to be problematic.

However, Event Ticket Plus does not interfere in the order process, rather it watches for changes in order status and takes action according to what that status is.

theeventscalendar.com/knowledgebase/woocommerce-specific-ticket-settings

It sounds like, in your case, the major problem is this:

ticket/order status is automatically changed from “Failed” to “Completed”

If the order is automatically set to complete then that would normally be a valid indicator that tickets should be dispatched. Yet, this is not something we are in control of. I’m interested to know: can you replicate the same behaviour in terms of the order moving to a ‘completed’ status after payment failure with other, non-ticket products?

The fact is that, if you can, it may be better to reach out to the team at Woo for assistance with this.

Alternatively, you could adjust the settings described in the above link and unselect ‘completed’ as one of the trigger statuses for sending ticket emails. Of course, that might mean you need to manually dispatch them in other cases.

Does that help at all?

[Barry]

Hi Javier 🙂

You can control when tickets are sent by altering the statuses in Events → Tickets → WooCommerce Settings, as described here.

I want to be clear though that these settings have no impact on order receipt/confirmation emails dispatched by WooCommerce itself (they only impact the tickets email).

Does that help?

[Barry]

Hi Børge,

Thanks for contacting us!

Those strings are translatable, but may not yet have been translated into Norwegian. We depend on community contributors to help with this effort as we are unable to translate the plugin ourselves – for more on this, please see the following articles:

• Translating The Events Calendar
• Incomplete Translations

With regards to the Month, List and Day buttons in your screenshot: those are not generated by The Events Calendar or else that area has been customized quite extensively (perhaps by your theme). I’d like to think this would be done in a way that respects existing translations, but can’t guarantee it unfortunately.

Does that help at all? Let me know if you have any further questions.

[Barry]

In the system information you shared, Event Tickets Plus still does not appear to have been updated:

Event Tickets Plus version 4.0.5

The current version however is 4.4.2. If for any reason automated updates are not functioning within your site, could you try grabbing the latest release and upgrading manually?

theeventscalendar.com/my-account/downloads

Thanks!

[Barry]

Yes, that should be possible with something like the following snippet (once again, take the necessary precautions before running this! That is, back up and know how to restore the backup):

DELETE
FROM   wp_posts
WHERE  LENGTH( TRIM( post_title ) ) = 0
AND    post_type = 'tribe_events'

[Barry]

Hi Ken,

After giving this some further thought, it seems like the best course of action may be to simply continue using the existing cost field and express ranges by providing two space separated values, for instance (you probably already realize this):

5.95 29.95

Will result in something like $5.95 – $29.95 displaying on the frontend. Filtering, via Filter Bar’s cost filter, isn’t something we can address in the short term though we do have a bug report filed that aims to address this issue. That essentially leaves the ‘rich data’ (or JSON-LD) issue you referred to.

There are a few ways we could deal with this, but I wanted to check in with you: would you prefer to see this be modified to include the lowest value, or to include the highest value, for those events with a cost range?

Thanks!

[Barry]

Hi Bill,

Keeping your goal of avoiding the use of custom code in mind, the use of custom fields (as provided by Events Calendar PRO) is probably the best way forward here.

You could additionally hide the default price field using CSS, as you outlined. Alternatively, you could achieve a compromise by doing something like adding custom fields and using them to replace the regular cost field (in relation to single event views only). This would require a small amount of custom code, but not much, and would leave filtering and rich data uncompromised (albeit, you or your client would need to provide a nominal single value).

Let me know your thoughts!

[Barry]

Happy to help 🙂

[Barry]

No problem, I’m sorry we couldn’t take this idea further but hopefully it provides you with an avenue you can explore if needed.

Out of interest – and to inform any further decisions we make about this part of the system – was there a particular reason you wished to make this change, or did it boil down to a matter of personal preference?

[Barry]

Stripping the prefix is as challenging as modifying it, unfortunately.

With that said, you could potentially use the post ID instead of the unique ticket ID. Differences:

• The default unique ticket IDs start at ‘1’ for each event
• Post IDs for the tickets will not start at ‘1’ and may not be consecutive

In other words, if you use post IDs instead of the default unique ticket IDs, you’d have a list of ticket numbers looking something more like 1451, 1457, 1469, … rather than TE-1, TE-2, TE-3, …

This would potentially be easier to achieve but would require some reworking of the attendee list as well as the ticket email template to bring about. Right at this time, I’m afraid it is also something we’d need to leave you to explore and potentially drive forward under your own steam.

[Barry]

I’m afraid to say that’s not so easy to adjust.

• If you’d like to propose an enhancement making it easier to customize this, we’d be more than open to the idea!
• If you feel confident building your own interim solution, it may be helpful to know that the field you are interested in is stored in a piece of post meta data named _unique_id (per individual attendee record)

[Barry]

Hi Jerome,

When you say it is not working – do you mean that the event search bar isn’t showing and can you point me to a live example of the problem?

Thanks!

[Barry]

Hi Jerome,

It’s not currently possible to position the filter bar within the sidebar area, at least not without extensive customization work.

Additionally, the [tribe_events] shortcode does not support integration with Filter Bar at this time, though it is possible to enable the regular events search bar by doing something like this:

[tribe_events tribe-bar="yes"]

I hope that clarifies things 🙂

[Barry]

Hi Gabriel,

Just to be clear: you’ve added some custom attendee meta fields and wish to ‘back-fill’ data into tickets that have already been created?

If so, I’m afraid that isn’t directly supported however it would certainly be possible to do this if you feel confident working directly with the database.

The way this data is stored is as a serialized associative array in the post meta table. Each ticket with attendee data basically has a matching post meta entry using the _tribe_tickets_meta meta key – and the data can be found in the meta value field.

Since it is serialized PHP data, it may therefore be easier for you to do this from a PHP script.

I hope that provides some insights!

[Author]

Posts