[Barry]

Hi Nicola,

So to call a function you need to follow the function name with parentheses – so instead of just:

tribe_event_is_all_day

Ensure you follow up with ():

tribe_event_is_all_day()

You might also want to modify the second part of the if clause — in PHP a single equals sign by itself is used to assign a value rather than to compare it (comparison can be done with a double == or treble === equals signs).

I definitely appreciate this sort of work can be tricky when you don’t know PHP, but please bear in mind if you decide to make customizations like this it is really your responsibility to understand what’s happening so you can maintain your work going forward – though of course we’re always happy to give you a pointer in the right direction if we can 🙂

Thanks again and I hope that helps!

[Barry]

docs.tri.be is unavailable at the moment, our apologies on that count (though it’s likely it will in any case ultimately be replaced completely by the new documentation available here at a future date) … and yes – we do indeed have a tribe_get_events_title() function 🙂

So if you want to target single event pages in particular, how about adding in a conditional like this:

if ( tribe_is_event_query() && is_singular() ) {
    echo tribe_get_events_title(); // and/or other code to suit
} elseif {
    /** Other conditions, ... */
}

Does that get you closer?

[Barry]

That is odd.

Am I right in thinking you have not yet had an opportunity to run through our standard troubleshooting steps – and would it be possible to do so now?

It appears the problems started on the 25th of January.

Did that happen to coincide with any events such as an update to WordPress or one or more plugins/themes (or even the addition of new plugins/a new theme)?

[Barry]

Hi Nicola: you can use tribe_event_is_all_day() to detect if it is an all day event – and show or hide the time information appropriately 🙂

[Barry]

Hi Paul,

Thanks for your interest!

Our ticketing solutions are designed to integrate tightly with one of four well-established WordPress ecommerce engines.

Some of those may indeed offer something close to point-of-sale capabilities (possibly they will themselves require you to purchase an additional addon for this) and so what I’d suggest is researching those options and settling on the ecommerce solution that comes closest to meeting your needs in that regard.

In terms of printing tickets, the default setup is to email these to the customer. However, if your project scope allows you could build a customization to let you print them on demand or else you could tweak things so a copy of each dispatched email is also sent to you – then you could keep an email client open as you work and print them off in near realtime.

All that to say, this sort of thing isn’t what the product is geared to out-of-the-box but it would certainly be achievable with some imagination and possibly some customization work 🙂

I hope that helps!

[Barry]

Hi Jeroen,

I’m sorry you’re hitting difficulties.

Can you confirm in the first instance that the orders in question were marked as complete?

 

[Barry]

This reply is private.

[Barry]

Hi Christopher,

By default you only have access to older versions that your licenses would have entitled you to. So, if you had a license for a year, but failed to renew, there would be a gap in the available downloads covering that period.

The last release we have that is marked compatible with WordPress 3.6 was the 3.5 release: you can grab old versions of The Events Calendar itself from this page and I’ll happily provide you with a link to the matching Events Calendar PRO release in a follow up post.

Please understand though that we cannot provide technical support for such old releases, nor can we guarantee you won’t be introducing problems that were subsequently fixed.

[Barry]

Hi Dominik,

I do indeed see the problem and can see how it’s impacting your menu. I can also appreciate this is a frustrating situation for you and we want to help as best we can – all I’m highlighting is that there are, reasonably enough, limits to the level of support we can provide.

Bear in mind also that the reason you approached us in the first place is because your theme behaves in an atypical manner (I don’t believe you saw or would see the same issue with a default theme or any number of other themes), so we’re not necessarily looking at a flaw in our plugin here so much as an integration issue between the two products and, realistically, we can’t always provide fixes on demand in those situations.

Not sure what you mean about changing the header? I have a page-events.php template in my child theme – this is where the $title stuff is

So conventionally a theme will build up pages from multiple templates. Here’s a simplified example:

• header.php (displays the browser title, page title, menu etc)
• page.php (displays most of the actual post content)
• footer.php (wraps things up)

Every theme is different so they may not even have those particular templates (and the responsibilities of each vary on a theme-by-theme basis), but very often there will indeed by a header.php template and that will be where the title is printed out.

What I’m suggesting here is locating that title area (if it’s not clear you could always seek the advice of the theme author in doing so – though perhaps you’ve already pinpointed it within page-events.php?) and modifying that in order to fix this in a different way from what was suggested previously, which isn’t looking like a suitable long-term fix.

You can then use conditional tags to modify the title area output on different pages, something like this:

<?php if ( tribe_is_month() ): ?>
    (Custom month view title)
<?php elseif ( tribe_is_list_view() ): ?>
    (Custom list view title)
<?php else: ?>
    <!-- theme's original title code which will -->
    <!-- behave as before in all other cases -->
<?php endif ?>

By making such a change directly in the relevant template (you can safely do so from a child theme) you will have what I think will be a far more robust solution.

Does that make more sense?

[Barry]

Nope that’s fine – I was just checking that the issue was not impacting the actual cart.

So the problem is essentially that the cross-selling plugin adds its extra information to the product page. In the case of tickets, of course, the WooCommerce product page is not used – they are sold via the event page instead, which is why you aren’t seeing anything.

So there are a couple of options you can explore here:

• The first is checking in with the authors of this other plugin – perhaps there is a template tag or something of that order you can use to embed related products in any given page (and, if so, you could customize the single event template appropriately)
• Alternatively you can allow tickets to be presented on the actual WooCommerce product page with a fairly simple customization as described here

Would either of those work for you?

[Barry]

OK. Would it be possible for you to (temporarily) turn on map view and also enable an embedded map for this event and for this venue? That might give me some more information to help assess the situation.

Thanks!

[Barry]

I can definitely appreciate that.

Unfortunately our current release cycle means a substantive fix, baked into our plugins, may still be a release or more away – however we definitely want to do what we can to assist in the short term and so while I can’t offer any guarantees we’re going to investigate a few possibilities that might provide you with some temporary relief from this issue.

My colleague Gustavo will spearhead this and so may drop in here to keep you updated 🙂

[Barry]

Hi Dominik,

Every theme is different and, looking back, we did spent quite a bit of time trying to work with you on this previously. With that in mind, I hope you can appreciate the level of assistance we can offer here is limited and it may also be worth considering seeking help from the theme author or even an independent developer.

I’m tending to think that perhaps it’s time to adopt a different approach. If I understand correctly, the issue is in making the prominent page title (below the menu, but above the content) display the correct thing: maybe customizing the theme’s header.php template would be a better way to proceed here?

You could potentially do this from a child theme and it may be a more reliable approach. Is that something you’d be happy to try?

[Barry]

Hi Peter,

It looks like some of those venue addresses are incomplete (and so perhaps Google is unable to suggest what the correct coordinates are).

Can you try updating one or more with a complete street address and see if that helps?

I appreciate you may not wish to be so specific, but that would at least help us to determine if the problem is simply that Google cannot work with the information provided.

Thanks!

[Barry]

Hi!

You could be right but I’m actually wondering if the problem is not with Divi itself but rather with a customization that has been made to it.

Are you aware of any changes – perhaps customizations to one of the templates or extra code in the functions.php file – that might have been made, whether by yourself or a developer working on your behalf?

It looks like a script called angelo.js is running but it lives in the root of your WordPress installation (which is why I suspect it isn’t related to the stock theme by Elegant Themes).

Would it be possible for you either to temporarily remove this and any other customizations/tweaks (or even revert to a pristine copy of Diva) and see if there is still a problem?

Thanks!

[Author]

Posts