[Barry]

Hi Benny,

Glad to hear that (for the most part) it’s working great 🙂

I’ve also shared your notes about this feature being something you’d expect to be included as standard with the rest of the team; I can’t guarantee this will change but we’re always open to this sort of feedback and it may well spark further discussion internally.

With regards to your specific problem:

However, if I filter in month view, and then change to the list view, the query is lost and all the events show up.

This is actually a known bug – we’ve got it on the tracker and will try to fix it as quickly as we can. I’ve linked this topic to the bug report so that – as soon as we’ve got something substantive to report – we can post an update in here.

Thanks again and our apologies for any inconvenience in the meantime.

[Barry]

Hi Ivan,

There’s a limit to how much support we can provide for this sort of thing – as it’s basically a custom development task – but I can certainly see others wanting something very similar.

With that in mind, here’s an example plugin that should provide a basic framework for you to build on and tweak as needed:

Sample Post Category Integration (plugin zip)

I hope that helps 🙂

[Barry]

Hi Jill,

I appreciate the extra information – I did indeed initially miss your point about creating the event in an older release.

That said, I still seem unable to replicate. Going back to 3.12, when arbitrary recurrence (and exclusions) were first made available in a public release, I don’t find that time information is recorded – it does not appear visually nor in the database. Fast forwarding to our current release doesn’t change this and I do not encounter the same difficulties you have described.

So, I’m a little perplexed – especially as I don’t know of other users detailing exactly this scenario. If you delete those exceptions (the problematic ones that include times) and recreate them does the problem resolve itself?

[Barry]

Hi Dave,

I can see something very similar to what you have described (the problem is a little bit wider in my own testing, but it’s still clearly a problem with iCal imports running in a multisite context).

This bug has been logged and we’ll address it as quickly as we can, however I should be upfront about the fact it’s unlikely to ship in the very next upcoming release simply owing to how far along we are in that release cycle.

Of course, we’ll try to update this support topic once we’ve got something substantive to report so as to keep you in the loop.

Thanks again for reporting this and our apologies for the inconvenience.

[Barry]

Hi Ivan,

Some others have successfully done just this – though it does require a little custom code to be implemented.

Here’s a relevant forum post which covers a couple of angles of this problem 🙂

I hope that helps!

[Barry]

Hi Wendy,

That sounds a little odd :-/

To the best of my knowledge, though, this isn’t a known bug impacting lots of users, so it’s quite possible there is some sort of local conflict or configuration issue.

You didn’t provide your system information when you initially created this support topic: can I ask you to do so now? That would provide some further insights about your installation which we can scan for problems – but please mark your reply as ‘private’ so that this information isn’t publicly shared.

Beyond that, can you confirm the role of the user (or users) who are attempting to add events – are they administrators, editors, etc? Could you also confirm if you or perhaps someone working on your behalf might have edited your site’s roles and capabilities? Sometimes users are granted extra permissions or permissions are taken away from them and that can cause this sort of problem.

Last but not least, did you have an opportunity to run through our standard conflict testing steps?

Thanks!

[Barry]

Hi Jill,

I’m sorry to hear you have been experiencing difficulties.

The initial screenshot you shared is a little hard to read so I’m not sure quite how precisely my attempt to replicate was but, using a weekly recurring event with two date-based exclusions, I found everything worked as expected.

To better illustrate, here’s what I tried initially:

• Created an event beginning 2016-01-09
• Recurring weekly for 6 weeks
• Added an exclusion for 2016-01-23
• Added an exclusion for 2016-02-06

The expected set of events, with two “gaps”, was generated. Further changes such as moving the initial date back (and adjusting the exception dates accordingly), or increasing the number of event instances, did not result in any other anomalies.

Even so, there could be a subtle but important difference in what we’re both doing here. Are you able to break down into concrete steps a ‘test pattern’ that would let me replicate this?

Could you also provide your system information (by private reply) so I can look at your settings and see what other plugins are running in parallel to our own?

Thanks!

[Barry]

Hi Lisa,

The approach we take for setting up the necessary assets is as follows:

Tribe__Events__Template_Factory::asset_package( 'jquery-placeholder' );
Tribe__Events__Template_Factory::asset_package( 'bootstrap-datepicker' );
Tribe__Events__Template_Factory::asset_package( 'tribe-events-bar' );
do_action( 'tribe-events-bar-enqueue-scripts' );

Of course, if you use that in your own code be sure that Tribe__Events__Template_Factory exists first of all (in other words, don’t try to do this too early in the request)!

Again, building custom extensions is something we can provide only very limited support for – digging into the code is the best way to develop a good understanding of what you need here 🙂

[Barry]

That’s odd :-/

Can you share your system information? I’m particularly keen to learn which version of Event Tickets Plus is installed and active (it looks like you have up-to-date versions of The Events Calendar and Event Tickets, but I can’t detect Event Tickets Plus – your system info would be a more reliable way to test for this, however).

Thanks!

[Barry]

Hi Andy,

I was looking at the filter you mentioned, mostly with the thought of trying to alter the output, but as the CSS isn’t passed no joy there.

Not quite sure what you were experiencing here … do you mean your filter function received an empty string (was your priority high enough if so)?

I like the idea of using wp_add_inline_style() as you should be able to add the Customizer CSS to whichever tribe stylesheet is used and this would then be able to be overwritten without changing our current practice.

Agreed! We’re going to review things and look at this approach.

The only other concerning thing is that if the user ever adjusts something in The Events Calendar via the Customizer, there is no simple method for undoing this. Perhaps some other setting in the Customizer to revert all changes. Just thinking out loud.

That’s a very valid point – I’ll be sure to log that!

[Barry]

Hi Lisa,

We can’t offer too much help when it comes to custom code, but I’d be happy to steer you in the right direction if I can 🙂

In our own plugin and in our own views, the modules/bar.php template is included when we wish to display the event bar, whereas it looks like you are echoing out a (possibly modified?) version of the resulting HTML. Might it work for you to simply include the existing template?

If not, please bear in mind that there could be some complications stemming from any elements that are missing from your own version of the event bar or from other changes you have made.

On the CSS side you should probably also enqueue our resources/css/tribe-events-full.css file. On the JS side, you probably need at least resources/js/tribe-events.js and resources/js/tribe-events-bar.js (or the minified versions) to be enqueued and available.

Does that help at all?

[Barry]

Hi @schlauchius,

I’m sorry to hear you’ve experienced difficulties of this kind 🙁

Just to clarify, does this problem only relate to tickets/events originally set up with WooCommerce Tickets (as opposed to Event Tickets Plus), or are you also seeing this with new tickets that you recently set up with Event Tickets Plus?

If you haven’t had an opportunity to identify this, that’s totally ok, just let me know.

Thanks!

[Barry]

Hi Paul,

This looks like a bug and I have filed a report so we can address it in an upcoming release.

In the meantime, if you’re comfortable doing so, you could try adding the following snippet to your theme’s functions.php file or else to a custom plugin:

function temp_fix_42765( $date ) {
	global $wp_query;

	if ( ! empty( $wp_query->get( 'eventDate' ) ) )
		return $date;

	if ( defined( 'DOING_AJAX' ) && DOING_AJAX )
		return $date;

	try {
		$week_start = new DateTime( current_time( 'Y-m-d' ) );
		$offset = 7 - get_option( 'start_of_week', 0 );
		$week_start->modify( - ( ( $week_start->format( 'w' ) + $offset ) % 7 ) . 'days' );
	}
	catch ( Exception $e ) {
		return $date;
	}

	return $week_start->format( 'Y-m-d' );
}

add_filter( 'tribe_get_first_week_day', 'temp_fix_42765' );

That should provide temporary relief … if not, we can always wait out on a substantive fix in a future release (and of course we’ll do our best to post an update here in this forum topic when that is available) 🙂

Thanks for reporting this and our apologies for any inconvenience it has caused.

[Barry]

Hi Nicky,

Actually that’s not unexpected.

Orders and tickets are not one and the same entity. Also, because an order can be placed for multiple tickets, it wouldn’t make sense for all of those tickets to have the same order number as their own unique number, just because they would no longer be unique 🙂

Does the current numbering scheme cause a specific problem for you/your team? I’d love to hear more if so so that we can think about how this might be addressed and so we can look out for similar problems with other users.

Thanks!

[Barry]

Hey Andy!

It’s possible to override it with a filter. For example, this code (if added to your theme’s functions.php file, or a custom plugin, etc) would essentially remove the customizer CSS:

add_filter( 'tribe_events_pro_customizer_css_template', '__return_empty_string', 20 );

Of course, you could do something a little more fine grained depending on the exact result you are after.

With that said, I take your broader point and – setting transient based caching aside for the moment – possibly what we should really be doing here is leveraging wp_add_inline_style() when we inject the customizer styles. I’ll be sure to talk this through with the team and see if we can make a change along these lines 🙂

[Author]

Posts