[Barry]

Hi!

Sorry for the inconvenience. For the moment the old docs site is unavailable and redirects unfortunately seem not to be working in relation to it.

What I’d recommend in the meantime is making use of our current support resources:

• Knowledgebase
• Technical Docs

Does that help?

[Barry]

Hi Rich,

That sounds odd.

Would it be possible to view a live example in case any obvious clues present themselves (I visited the URL provided when you opened this thread, but it does not seem to be a site that uses The Events Calendar)?

You also noted having run through our standard troubleshooting steps, which is great, and your screenshot suggests that you are using something other than a default theme.

With that in mind, can I ask you to confirm if the problem only occurs with this particular theme (which theme is it?) or have you found anything else that’s needed to cause this issue?

Thanks!

[Barry]

… I’m going to eat my own words here. Looks like the random ordering is overridden by a different system within the plugin.

The following snippet – which you could add to your theme’s functions.php file, for example – should ensure randomness is maintained so you could give it a try:

add_filter( 'tribe_related_posts_args', 'ensure_random_related_event_ordering' );

function ensure_random_related_event_ordering( $args ) {
	add_filter( 'tribe_events_query_posts_orderby', 'restore_random_ordering' );
	return $args;
}

function restore_random_ordering() {
	remove_filter( 'tribe_events_query_posts_orderby', 'restore_random_ordering' );
	return 'RAND()';
}

That aside, again the level of appararent randomness will still depend on the total number of related events available. I hope that works for you!

[Barry]

Hi leviticus,

The relationship is based on having shared categories and tags and the result set should indeed be ordered randomly — but of course how random it will appear in practice does rather depend on the number of events you have available that have a relationship with the source event.

If you want to tweak the query used to build the list of related events you can do so quite safely via the tribe_related_posts_args filter (a working knowledge of the arguments used when forming a WP_Query would be useful here 🙂 ).

Alternatively, you could use the tribe_get_related_posts hook to substitute your own array of event posts and could build that list anyway you like.

Additionally, if you aren’t happy with the above approaches, you could override the pro/related-events.php template and build a custom solution in there.

Last but not least, if you feel there’s a good case for modifying the way this feature works out of the box in a future release (or if you want to see more options to help control it) we’re all ears – please don’t hesitate to post one or more feature requests over on our UserVoice page.

Thanks – and I hope that helps 🙂

[Barry]

Hi Aimee,

I’m sorry that none of those approaches worked for you – but thanks for persevering and giving them a try. The difficulty here is that themes (and plugins) have a great deal of power and all work in different ways, making each situation potentially unique.

Perhaps the solution here is to customize the theme. The best way to do this will of course vary depending on how the theme has been put together: perhaps they have a suitable hook allowing this kind of change to be made cleanly, or perhaps creating a child theme and overriding the header.php template would be easiest.

I think the first step is to figure that out and settle on whatever approach you are most comfortable with, but let’s assume you go for customizing the header.php template (assuming that is how the theme is structured).

Somewhere within it, there is this sort of structure:

<div id="container">
    <header id="header">
        <!-- ... we're not interested in this header -->
    </heaader>
    <header id="title=area">
        <div class="inner">
            <!-- here's the part we're interested in: -->
            <h2 class="entry-title"> ... </h2>
        </div>
    </header>
...

If you can find whatever controls and sets h2.entry-title you can modify it! You probably want it to behave as normal in all situations except for event views, so let’s assume it takes this sort of form:

<h2 class="entry-title">
    <?php echo custom_theme_title_function() ?>
</h2>

You could revise that to something along these lines:

<h2 class="entry-title">
    <?php 
    // For non-single event views, display something suitable
    if ( !is_single() && ! is_singular() && tribe_is_event_query() ) {
        echo 'Custom calendar title';
    }
    // Otherwise, let the theme do its usual thing
    else {
        echo custom_theme_title_function() 
    }
    ?>
</h2>

That is a simplified example that probably will need some tweaking rather than being something you can just drop in place, but I hope it gives you an angle to explore here.

Good luck!

[Barry]

Thanks for sharing the information – I do now see we actually have a note of WP Statistics causing a different set of problems besides what you hit up against here.

In any case, I will now go ahead and close out this topic – but if anything else crops up please don’t hesitate to create a new topic and one of the team will be only too happy to help.

Thanks again!

[Barry]

Apologies first of all Chris – I posted my last reply only a few minutes after your own follow up question (on Jan 27) and as I already had the editor open I didn’t actually see what you had written before replying.

Should I be adding this to the extended class, I haven’t had luck with that.

I would recommend doing so, simply because you can then easily access object properties and so on in order to set the taxonomy query up.

The basic approach you outlined though is essentially going to result in the very same problem we want to avoid: that is, you’re setting the tax_query without first checking to see if one already exists/what terms might already be being queried.

Help getting this last piece setup would be great. Seems this would also put an end to all the questions everyone is asking on the same issue.

I’d love to help more but we’re very much in customization territory here – and so it’s really something that you will need to drive forward under your own steam 🙂

In short, though:

• Setting the tax_query without checking to see what might already be set up is not going to work if you want this to play nicely with other taxonomy-based filters
• You need to use $query->get( ‘tax_query’ ), inspect the result and merge it with your new query

I’m sorry I can’t do more to help with this one, but I hope that at least gives you a steer in the right direction.

When are the additional fields going to be added to the filter bar add-on? I see this was mentioned almost a year ago but there hasn’t been any news. The same goes for adding documentation for the custom taxonomy filter development.

Right at this moment we can’t offer an ETA for custom/additional field support in Filter Bar and realistically I’d suggest it will not be available in the space of the next couple of releases – though it’s always possible we might be able to squeeze it in.

In terms of documentation for custom taxonomy filter development, I’m not actually aware of plans for such a specific resource – but we are always aiming to improve our documentation and you’re more than welcome to post feature requests for things like this.

We do have an issue logged to consider revising the way taxonomy filtering is handled, though, so any very specific learning resources about this aspect of development would probably wait upon completion of further work in that area.

I hope that helps and I wish you luck with the customization – as I don’t think we’re going to be able to help further on this specific item though I’ll go ahead and close out the topic but please don’t hesitate to create new topics as needed if any other issues crop up 🙂

[Barry]

That’s odd.

So you have no tickets selling for that cost (that perhaps are currently invisible on the frontend due to start/end sale date restrictions)?

If not, I wonder if the event cost field has, for some reason, been set to $1 and is stuck there despite the presence of the tickets. To explore this idea, can I ask you to add the following snippet to your theme’s functions.php file or some other suitable place:

add_filter( 'tribe_events_admin_show_cost_field', '__return_true' );

Now edit the event and look for the actual event cost field – what is it set to? If it is $1 can you delete the cost, update the event then remove the above snippet – does that get us any closer to a fix?

 

[Barry]

Hi! It’s been a while so I’m going to go ahead and close this thread. If we can help with anything else, though, please don’t hesitate to create new threads as needed. Thanks!

[Barry]

Hi! It’s been a while so I’m going to go ahead and close this thread. If we can help with anything else, though, please don’t hesitate to create new threads as needed. Thanks!

[Barry]

Hi! It’s been a while so I’m going to go ahead and close this thread. If we can help with anything else, though, please don’t hesitate to create new threads as needed. Thanks!

[Barry]

Hi! It’s been a while so I’m going to go ahead and close this thread. If we can help with anything else, though, please don’t hesitate to create new threads as needed. Thanks!

[Barry]

Hi! It’s been a while so I’m going to go ahead and close this thread. If we can help with anything else, though, please don’t hesitate to create new threads as needed. Thanks!

[Barry]

Hi! It’s been a while so I’m going to go ahead and close this thread. If we can help with anything else, though, please don’t hesitate to create new threads as needed. Thanks!

[Barry]

Hi! It’s been a while so I’m going to go ahead and close this thread. If we can help with anything else, though, please don’t hesitate to create new threads as needed. Thanks!

[Author]

Posts