[Barry]

Hi wggb,

Let me try to answer each of the questions you raised.

I’m not sure what changing the theme would have to do with the query being generated.

It’s not uncommon for themes to modify queries – they might for instance have a setting to allow a certain category or specified set of posts to be excluded from the homepage, or something similar to that, but not be too discriminating in terms of which query they modify.

It could equally be due to another plugin which also needs to manipulate the query to achieve its goals – but again may not discriminate between the query used to build the main blog loop (for instance) and an events query.

Do you know where this particular query comes from?

It certainly looks similar in form to a typical events query issued by our plugin.

It would be worthwhile finding out however A) if it is indeed being modified by another product – I suspect it might be – and B) if changing that resolves the performance issues or C) if it still poses a challenge in terms of performance even if it is not impacted on by other code.

I can’t really try that on this site as it’s a large production site for a local news station in Mass.

I can definitely sympathize, but perhaps you could set up and run through the troubleshooting steps in a duplicate development or staging environment?

There are some aspects of our plugin, particularly the query used to build the month view, for which we are trying hard to improve performance. There is a limit to what can be done though and a lot depends on the resources available in your hosting environment and of course the number of events you have in the system … are you able to share any information along those lines?

[Barry]

The long list of post IDs in particular draws my eye – do you experience quite the same results with a default theme and with no other plugins (except for those by Modern Tribe) in use?

[Barry]

Hi Anna,

I can’t access your site directly right now (seems to be in maintenance mode) but based on what you’re telling me I’m guessing this is just expected behaviour.

When the browser is resized the logic responsible for laying out the events will indeed move the ‘panels’ around in order to achieve the best possible use of space.

[Barry]

Hi braniganinteractive,

One possibility here would be to loop through your results and use the post ID for each event to retrieve the related Eventbrite ID / test if it indeed exists by using WordPress’s get_post_meta() function (the related meta key is _EventBriteId), so something like this:

$ebID = get_post_meta($eventID, '_EventBriteId');

If you get a valid ID string back you could use it to form a URL for the event over on Eventbrite, as they typically follow a reliable and simple pattern:

www.eventbrite.com/event/{event_id}

(Where of course {event_id} would be the actual string of numbers.)

Does that help at all?

[Barry]

Hi cocoispmunibe,

That’s not directly supported, but you could for instance add a link on the second day back to the first event for those who wish to buy tickets.

[Barry]

Hi cocoispmunibe, I’m afraid currently that is not possible but it’s a feature that we have under consideration and I’ll certainly make a note of your interest in our internal issue tracker.

Sorry we can’t offer more at this time.

[Barry]

No problem at all – glad you’re sorted here 🙂

[Barry]

OK, when you say “Add to cart” I’m taking that to be the ticket form on single event pages. For that you could try adding the following CSS rule:

.single-tribe_events #tribe-events-content form.cart { background: #007fff }

You could add this to a custom tribe-events.css stylesheet – we’ve got details on how to set that up in our Themer’s Guide.

If I add tickets to the cart I can’t actually progress as it seems you’ve set things up such that users need to be logged in to continue with the checkout process – so I can’t see the other areas you mentioned. However, it sounds like these relate to the WooCommerce generated cart and checkout pages which aren’t under the direct control of our plugin (and which we can’t support – but the fine crew over at WooThemes can probably point you in the right direction there).

[Barry]

Definitely, thanks for checking in 🙂

[Barry]

It definitely could be useful – do feel free to go ahead and post a feature request for this:

https://tribe.uservoice.com/forums/195723-feature-ideas

Since it sounds like you’ve got a solution you’re happy with in the meantime though I will go ahead and close this thread out. Thanks again!

[Barry]

Hi tomoko,

Can you confirm that:

A) WooCommerce is activated in addition to being installed
B) The Events Calendar is also installed and activated

Either of those could be the source of the problem.

[Barry]

Hi merlin1710,

I’m not absolutely clear on what you wish to change here – is it the background of the ticket form (currently white in appearance) or is it the Add to Cart button itself (currently WooCommerce-purple)?

[Barry]

Hi Mike,

The first thing to highlight is, with the first generation of WooCommerce Tickets (or WooTickets as it was at that point) the PDF did not exist only in the email. The generated document was saved in the uploads directory – so reverting to the technique as used in that earlier version of the plugin wouldn’t be a silver bullet given the concerns you are outlining.

The other side of this is that if you are changing/adapting the way WooCommerce Tickets works (by adding barcodes to tickets for instance) then it’s really up to you to take responsibility for any security issues: perhaps you could take advantage of inline images within the emailed tickets (so that a copy of the image does need to remain on the server) or perhaps you could devise some other clever way of building barcodes using only HTML – but I’m afraid it’s outside the scope of support we can offer to work through that with you.

[Barry]

Hi infamia, I don’t actually see the same thing – is it possible the problem is compounded by the presence of your theme / another plugin?

[Barry]

Hi Mike,

Glad you sorted the email template override issue.

Regarding the second problem, each ticket has a security code which is basically a hash of various bits of information – unless a fraudster had intercepted an email or somehow knew which codes were allocated he or she would have to be extremely lucky to turn up with a fake ticket that happens to have a valid code on it.

I’m not too sure how or what difference the delivery format, be it PDF or HTML, makes here.

[Author]

Posts