[Barry]

Hi Ferry!

The first thing I want to highlight is that you should not modify core plugin code – please instead refer to our Themer’s Guide which covers the correct (and safest) way to override and customize our views (of course, if you are already doing that – great!).

To the problem at hand, I’m afraid I am unfamiliar with BFI Thumb. If the problem only occurs on ajax requests, though, perhaps the issue is that it relies on a browser event – such as document.ready or window.onload – to trigger its particular behaviours and that only happens once per page load.

Perhaps you could contact the author (of BFI Thumb) to ask if that might be the case and, if so, check if there is some other way of triggering it at a later stage.

[Barry]

Great question – we actually need to bolster our docs in that area but yes, it does indeed respect most or all of the arguments accepted by get_posts().

In addition, you can pass a number of event-specific arguments:

• start_date yyyy-mm-dd hh:mm format (year-month-day hours:minutes, ie 2015-01-20 13:20)
• end_date in yyyy-mm-dd hh:mm format as above
• eventDisplay which may be one of:
  • custom (generally recommended for custom work like this)
  • list
  • past
  • month
  • week
  • photo
  • map

So here I’d suggest setting eventDisplay to custom and programmatically determining the correct start_date and end_date for the range of events you wish to fetch 🙂

[Barry]

Hi!

So if Eventbrite Tickets is installed and activated you will not see a cost field when you edit events.

This is by design and avoids confusion since generally an Eventbrite Tickets user will define ticket prices via the Eventbrite Tickets settings themselves.

So, in summary, without Eventbrite Tickets (or any other ticketing plugins) activated you should be able to see and edit the following field when you edit and create events:

With Eventbrite Tickets you simply define the ticket price for each ticket you create – please see our Eventbrite new user primer for details of this 🙂

Does that help?

[Barry]

Hi!

Could you point me to more complete documentation on your “Loop”? I like the idea of adding an additional loop only for the past events, so I don’t want to modify the default loop.

Where we use a regular loop it is not really any different to the WordPress loop itself (except, of course, it is concerned with events and event times rather than blog posts and publication times) and actually it is driven by the very same mechanisms – so we don’t really have any specific documentation of our own on that count.

What I’d note here, though, is that if you use tribe_get_events() to pull in those events, even from within the loop, it should not impact on the main/outer loop at all.

2) I think modifying the template is the best way to proceed; however, I’ve got a pretty big problem.

We’re using WP MultiSite, I’ve shut off all Caching, but no modifications I make to the “views” templates make any effect on how the pages render on the website.

I can even DELETE the entire Views folder from both the events-calendar-pro and the the-events-calendar folders and the /events/ page is still rendered correctly…?!

We do try hard to stick to one issue per topic, so if you are experiencing problems in setting up template overrides I’d respectfully ask you post them in a fresh topic – one of the team will be only too happy to help.

A couple of pointers that might help before you do that, though:

• You can review the correct process for setting up template overrides here – the key thing is to place them in a tribe-events subdirectory within your theme
• If you have no template overrides and have also deleted the views directory from within each of our plugins (incidentally, we recommend you never modify core plugin code) and the event views continue to work it is likely you are still seeing cached content
• Deactivating a caching plugin does not always stop cached content from being served: please refer to the instructions provided by the caching plugin author or seek their help in terms of completely removing caching as you may additionally need to tidy up various other files and directories to stop cached content from being served to visitors
• Remember that some web hosts provide an additional caching layer, above and beyond what is provided by any caching plugin you install
• Once the effects of caching have been fully eliminated, you will have a clear picture of what’s happening, can make your changes and then can carefully re-enable caching when you’re ready

I hope that helps 🙂

[Barry]

Hi Bernhard,

I seem unable to login using those credentials, but in any case it would be easiest to get a couple of examples of Facebook URLs where the events share a common venue, organizer or both but have resulted in the creation of duplicate venue/organizer entries locally.

Would it be possible to send some links?

Thanks!

[Barry]

None built in that specifically do just that, but you could potentially use a custom function like this one (modify to suit your needs!):

/**
 * Returns true if the current page is the main events page, else returns
 * false.
 *
 * Criteria for the "main events page" here means:
 *
 *     - We're on an events page
 *     - It is the same view as the default events view
 *     - No particular date has been specified
 * 
 * @return bool
 */
function is_main_events_page() {
	global $wp_query;

	// We needn't worry about non-event requests
	if ( ! tribe_is_event_query() ) return false;

	// Get the default view and currently requested view
	$default = TribeEvents::instance()->default_view();
	$current = $wp_query->get( 'eventDisplay' );

	// Was a date specifically set? If so, it isn't truly the "main" events page
	$date_set = $wp_query->get( 'eventDate' ) . isset( $_REQUEST['tribe-bar-date'] ) ? 1 : 0;

	// Compare and contrast!
	return ( $default === $current && ! $date_set );
}

[Barry]

Definitely, glad to be of some help even if it isn’t the perfect solution.

I think to drive this forward – at least without impacting on the live site – we’d really need to follow the test site steps described in my second reply. I realize you’re not too keen on doing that just yet but, if and when you’re ready, that would be my next recommendation 🙂

[Barry]

No problem, I hope it helps to pin down the cause (though it’s always a pain to hit on conflicts, of course).

In terms of why WPML would impact on event pages, even if it isn’t used there directly, I think the problem may essentially be that it can modify request/query variables for any given request – which can trigger some routing issues.

[Barry]

Hi Benjamin,

It’s hard to guide you exactly since there’s no way to know how your theme works under the hood, but potentially a snippet like this will fix things by detecting if the title is an empty string (and checking to see if it is an event-related request) and replacing it with something else:

add_filter( 'wp_title', 'events_title_fix', 1000 );

function events_title_fix( $title ) {
	$trimmed_title = trim( $title );
	if ( ! empty( $trimmed_title ) || ! tribe_is_event_query() ) return $title;
	return 'Main events page!';
}

You could for instance try adding that to your theme’s functions.php file.

Does that help at all?

[Barry]

Hi Benjamin,

You generally ought to wrap the conditional in parentheses:

if ( is_page('events') || tribe_is_event() ) { /*...*/ }

Please also note that event views are not actually pages in the traditional WordPress sense (they are not editable posts stored in the database) so if that first test – is_page(‘events’) – is trying to detect requests for the main events page it won’t work (though if you happen to have an actual WordPress page called events and that is one of the things you are looking for then of course it’s completely fine).

I hope that helps 🙂

[Barry]

Hi Bernhard,

The importer will always try to re-use previously imported venue and organizers, however this hinges on them truly being the same entity on Facebook (and not merely sharing some/most of the same details).

Can you point me to a couple of the different Facebook events you have imported from so I can try to evaluate if each venue is actually the same entity?

Upon making a quick test (where I know the venues for a series of different events are genuinely one and the same) I don’t see the problem occuring – but I can certainly look into it and checkout the actual events used in your scenario.

(I also note your license for Facebook Events seems to have expired, so though we’re always interested in bug reports there may be a limit to how much help we can extend here.)

Thanks!

[Barry]

Hi mlivesay,

I have to note immediately that this is very much a customization task and the amount of assistance we can provide you with is therefore fairly limited – even so I’d be happy to moot a few ideas that might help 🙂

We want to show events up to 7 days prior to the current date.

So if today is 1-14-2015 then we would like to show events at the top of the homepage which occurred as long ago as 1-7-2015.

So is this only to occur on the main events page rather than all event views?

People usually come to our site to see the results links from a previous race up to 7 days after it occurred.

Given that, am I right in thinking that you may indeed wish to style things differently in order to highlight that these are past results? If so, perhaps and easier and more suitable avenue is to customize the relevant template and add a snippet or two to pull the past week’s results in there – using our tribe_get_events() function perhaps – and you can then format them however you would like.

Would that sort of approach work for you?

Someone mentioned modifying the tribe_pre_post_query

There is no such thing as tribe_pre_get_posts.
There is tribe_events_pre_get_posts and simply pre_get_posts

I see 3 cases in the pre_get_posts function for week, photo and all.

I do not see anything in there where I would modify the date…?

So I think that was just a typo and tribe_events_pre_get_posts is indeed the action that was being referred to. This can be viewed as a more specialized form of WordPress’s own pre_get_posts action – in that you know it will only fires for queries that relate to events.

You can use this action to modify the date range by following this sort of pattern:

add_action( 'tribe_events_pre_get_posts', 'alter_event_date_range' );

function alter_event_date_range() {
    $one_week_ago = date( 'Y-m-d', strtotime( '-1 week' ) );
    $query->set( 'start_date', date( 'Y-m-d', $one_week_ago );
}

That’s not a complete example, of course, because you will not always want to modify the date in that way – but it shows the basic form.

[Barry]

Apologies, Massound, I do see what you mean now and did indeed misunderstand first time around.

This is in fact a known bug – and we’ll progress it as quickly as we can. Though not a perfect solution, you may find the workaround detailed here gives you some temporary relief until we release a substantive fix 🙂

[Barry]

OK, so on taking another look at your site I see the month and list views still function as expected (ie, if you navigate directly to …/calendar/month/ or …/calendar/list/ and/or if you switch between those views using the view selector).

So everything except the default main events URL of /calendar/ seems to be working.

I guess that means one short and easy fix is simply to change the menu so that the calendar link takes visitors directly to either month or list view, though it isn’t ideal as any links to view all events will return them to the site of the problem.

Could it be you or someone else has created an actual WordPress page that also has the slug “calendar”? If so, could that be deleted (and the trash emptied), a further flush of permalinks be conducted and see if the problem has been resolved?

Failing that, can you review Events → Settings → Display – just make sure everything is shipshape and that the default view and so on is what you want, and re-save the page.

Does that get us any further?

[Barry]

Definitely do feel free to install and activate PRO on your test site, there’s no problem with that whatsoever.

Given what you’ve described about the problem existing only on the live site even before you installed PRO there, though, I guess that may not be too helpful with this particular problem – but nonetheless it will give you something closer to an identical environment.

I checked your site again this morning and this time I was able to see the problem. I’ve got a few more questions:

• Besides being on a different server, you noted trying to replicate this problem with all of the same plugins that run on your live site: just for the avoidance of any doubt, did you also have the same theme in place?
• What version of WordPress are you running and has it been modified at all (I noticed a remark indicating it had been “patched” when I viewed the page source)
• It looks like you may also have WPML installed which is a known source of conflicts: when you tried to replicate this issue on the test site, was WPML setup and configured as per the live site or merely installed and activated?

On my final point, though I can appreciate it looks like you are making active use of WPML, I wonder if you could even find a quiet time to try deactivating it and see if it is indeed the source of the problem (I suggest this only because we know that the way it works behind the scenes has, historically, triggered some unusual issues and I’m now wondering if this could be one of them).

[Author]

Posts