[Josh]

Hey Benjamin,

Thanks for reaching out to us!

This is a bug which we recently discovered as well. A fix is already under development and should be released still this month if all goes according to plan.

To get it working until the fix arrives here is what you can do:

Open the wp-content\plugins\events-calendar-pro\lang\tribe-events-calendar-pro-xx_XX.po translation file with an appropriate app (e.g. Poedit) and change the translation of the English source string ‘all’ to ‘all’ (or remove it) instead of having it translated to your language. Save and upload.

Again sorry for this, a fix is on the way.

Let me know if the above fixes it for you.

Thanks!

[Josh]

Hey Jeff,

No problem, happy to help!

I’ll go ahead and close this thread for now. If you have any further questions, please don’t hesitate to open a new one.

Thanks!

[Josh]

This reply is private.

[Josh]

Hey Jeff,

Thanks for reaching out to us!

I took a look at your site and it appears that there is a javascript error generated when switching months (was also able to replicate in the other views when trying to click through multiple months or loading directly onto a different view).

The error given is a 500 Internal Server Error when requesting the admin-ajax file used for process the request.

As a starting point here, have you tried following the Testing for Conflicts procedures to see if there is another plugin that could be causing a conflict here with general requests to admin-ajax?

Let me know if you find any conflict and that can help get us pointed in the right direction here.

Thanks!

 

[Josh]

Hey David,

Thanks for reaching out to us!

Unfortunately, this is a limitation between Tickets and the recurring events feature in Pro. As stated on our Event Tickets Plus product page:

Please note that at this time, Event Tickets Plus will NOT support tickets for recurring events. Please keep this in mind before making your purchase.

The tickets created on a recurring event will apply to all instances of the event. So rather than each event having their own pool of tickets, the entire series of events will have a single, shared pool of tickets.

We are currently working on expanding this support, you can vote for the feature on our UserVoice page which will allow you to stay up-to-date with when we’ll have that feature available in our plugins.

I apologize for the inconvenience but let me know if this helps.

Thank!

[Josh]

Hey Mogul,

Thanks for following up.

It sounds like the “eventDisplay =>’past'” is overriding the original year based approach we came up with here:

https://gist.github.com/BeardedGinger/0f1b5aa69df8479876f1fbbe963cdd47

As an alternative, you could further extend the above snippet to check if the provided “tribe-bar-date” is the current year. If so, you could use a different end date of the date() so it won’t include events all the way up to the end of the current year.

Let me know if this helps.

Thanks!

[Josh]

Hey Chris,

Thanks for reaching out to us!

We are limited in the amount of support we can provide for theme specific conflicts such as these but I’m happy to take a look.

Would you mind either allowing anonymous submissions for your calendar on staging or providing me with a temporary subscriber login (not admin credentials) so I can see the submission form page on the site?

Thanks!

[Josh]

Hey Daniel,

Thanks for reaching out to us!

We do have a suggestion for something like this on our UserVoice page and we’d love to get your votes on that feature there.

There is a suggestion there for a possible solution. However, the simplest approach that I would take would be to just have a text field that just asks “Do you have any food allergies? If so, please describe below”

Let me know if this helps.

Thanks!

[Josh]

Hey Eloi,

Thanks for reaching out to us!

I apologize for the inconvenience of this particular warning for your site. Another alternative that has been suggested by one of our developers has been to filter the location for the logging files. For example, you could use our “tribe_file_logger_directory” filter and change the location like:

add_filter( 'tribe_file_logger_directory', function() { return '/my/custom/logging/location'; } );

Let me know if this helps.

Thanks!

[Josh]

Hey Alex,

Thanks for following up here and clarifying what you’re looking for.

This is an interesting need here. This is something that would definitely be beyond what we are able to provide support for here in our forums.

However, you could accomplish this with some customization and digging through the source code for our plugins (as well as WooCommerce) to review the access of ticket attendee data within the context of an order and registering new users on checkout.

I’m sorry I’m not able to give you a complete solution here but hopefully this can get you pointed in the right direction for the customization that you’re looking for.

Thanks!

[Josh]

Hey Anna,

Looks like there could be a general conflict between WordPress and another plugin on your site. Based on the error, I would assume it were one of the SEO plugins, possibly the “Basic SEO Pack” plugin. You can try deactivating that plugin to see if the javascript errors persist on your site.

If that doesn’t work, you can try following the full Testing for Conflicts procedures to see what other plugin may be causing the issue here.

Let me know if this reveals anything.

Thanks!

[Josh]

Hey Mogul,

The snippet:

https://gist.github.com/BeardedGinger/0f1b5aa69df8479876f1fbbe963cdd47

Assumes a tribe-bar-date of just the year “2016” or “2017”, try modifying the URL for that and see if it helps.

Thanks!

[Josh]

Hey Mogul,

Sure thing!

When doing the “$query->set()” arguments, you can set the eventDisplay argument to past:

$query->set( 'eventDisplay', 'past' );

And that should just pull in past events into the results.

Let me know if this helps.

Thanks!

[Josh]

Hey Alex,

Ah! I get what you’re saying now.

You are looking to have:

1. Using Ticket Fieldset, have a field to collect the actual student name for the ticket
2. Upon checkout completion, create a new user (in addition to the purchaser) for each ticket sold using the above field for the username.
3. Have that user assigned to the WooCommerce Customer role

The above would be possible with a good bit of customization. You could hook a function to WooCommerce order completion to check the associated ticket product a create new users using the ticket meta associated with the products for the order.

Unfortunately, something like that would be well beyond what we’re able to provide in support here. Additionally, I would be curious as to why you were wanting to pursue this route? There may be a simpler approach since this process requires creating new users for roles that they would typically be appropriate for.

Thanks!

[Josh]

Hey Bridget,

No problem, happy to help! 🙂

I’ll go ahead and close this thread for now. If you have any further questions, please don’t hesitate to open a new one.

Thanks!

[Author]

Posts