[Brook]

Howdy David,

Good question. That box should appear if your theme supports featured images, regardless of whether you are running Pro. If your theme doesn’t support it tho, the box is missing.

Do you see featured images available for new posts and pages? If so, what theme are you using?

Cheers!

– Brook

[Brook]

Howdy Annelies,

It would be my pleasure to assist with this as best I’m able.

WordPress does not natively support breadcrumbs. In fact, WordPress posts are not hierarchical, meaning that anything which does try to add breadcrumb support to WordPress will inherently be broken in some ways.

All that said, I have seen some third party plugins add breadcrumbs with decent success, they just rely on you to not do anything that will break stuff. You will have to consult the documentation of whichever breadcrumb you are using in order to modify it. I have absolutely no idea how to modify this third party software. Fortunately, events are a standard “WordPress Custom Post Type”. It is likely that your breadcrumb plugin or theme has instructions for modifying the behavior of a “CPT”, and that generic instruction will apply to Event as well any other post type.

Does that all make sense? Do you now know where you can begin searching for some instructions?

Cheers!

– Brook

[Brook]

Howdy Shadi,

Thank you for taking the time to report a bug! I have just logged this for our developers to look at. We will fix this as soon as we can.

To be up front, I logged this with a fairly low priority. Thus, it is naturally a bit lower on our list than some other more severe bugs. But in time we will hit all of them, including this one.

Why is a refunded order (ticket) not released back in stock?

This is an issue we discovered a short while ago, and are working to fix. This one is actually logged with a fairly high priority. By default, WooCommerce does not restock refunded items. However, you can change this behavior by checking a box on the refund form, and when you do unfortunately it does not affect the stock of tickets. So we would like to fix this too. One a fix for this is ready, all you will need to do is update your plugins and the issue will go away.

Please let me know if you have any questions while you wait on a fix. Cheers!

– Brook

[Brook]

Howdy Ilkka,

I would love to help you with this.

Actually, you can not override QR.php. Only files inside of the /views/ folder can be overridden. There is good reason for this. Almost any file outside of that folder is extremely to break compatibility with plugin updates, thus if you overrode it you would likely find yourself unable to update without getting errors.

However, I bet we can still easily accomplish what you want to do. I’m guessing you are trying to alter the HTML code output by the inject_qr function. You can still do this, and stay compatible with plugin updates! You will want to stop our plugin from outputting that HTML, then copy/paste the code that powers it into one of your own files such as the functions.php in your theme.

Here is what I would do if I were you:

https://gist.github.com/elimn/8a0a0dfd02842c30ff3d27e895819837

Does that all make sense?

Cheers!

– Brook

[Brook]

Howdy Deb,

I would love to help you with this.

We strive very hard to obey WordPress best practice with our plugin, as such our plugin stored data in a way very similar to the WP Posts and Pages. The primary post, or in this case the ticket, is stored in the wp_post table. The meta data is stored in the wp_postmeta table, and in this case the email, name, and event the attendee is associated with, would all be meta data.

Some other data is stored elsewhere in the database, but probably not relevant to your needs. See this for more info:

https://codex.wordpress.org/Database_Description

If it is at all possible to use our builtin functions or the WordPress API to fulfill this request, I would encourage you to do so. They make it a lot easier. For instance, the following function will get all attendees for an event including their meta data. In this case, it is getting attendees for the event with an ID of 123:

Tribe__Extension__Tickets_Order_Helper::get_instance()->get_event_attendees( '123' );

If you must retrieve the info direct from the database, that too is possible. Here is the SQL WordPress generates to get our attendee info from the database:

SELECT
 post_id,
 meta_key,
 meta_value
FROM
 wp_postmeta
WHERE
 post_id IN(123)
ORDER BY
 meta_id ASC

Again not the ID used. In this case it will be the ID will match that of the tribe_wooticket post you found in the database.

Does that all make sense?

Cheers!

– Brook

[Brook]

Howdy Alan,

I was able to replicate this on my own multisite. I had a valid license, the plugins were not network activated (and thus not network licensed), and yet the alert showed. I am able to dismiss the alert, but sometimes it comes back.

I’m sorry again about the inconvenient alert. We are looking into patching this. I’ll update you when we know more.

Cheers!

– Brook

[Brook]

This reply is private.

[Brook]

Thank you for isolating this and documenting it Jeremy. This is extremely helpful! As a token of thanks I just extended your agency license by a couple of months.

We are going to craft in a fix modeled after your idea as soon as we can. If I have some extra time this next week, I will even sneak it into our very next release. But, you know how life goes, it might take a little longer than that.

Thanks again!

– Brook

[Brook]

That is great news George. Thank you so much for trying that.

For now, yes you will need to modify that code on each install. However, I am going to try to sneak that code change in to our next maintenance release. If everything goes ideally, then the next time you update your plugins it should include this fix, and you will no longer have to worry about it on any new sites.

Basically this error stems from scenarios where a server has set the temp dir to be readable, but not writable. That would be extremely rare, but when it does happen we can account for it with this line of code.

Cheers!
– Brook

[Brook]

Oh I am sorry to hear your usual customizer won’t be able to help here.

Can you explain why? Thanks.

Absolutely. In order for tickets to work properly they must be a “Simple Product”, and ideally be set to “Virtual”. Since the product you were trying to sell was changed to a group one, it won’t be either of those.

Unfortunately the best solutions right now are mere workarounds, like the one I recommended at the outset. Basically any solution I can think of will either require a customizer of some kind, or you will need to instruct your users on what to add to their cart. I wish I had better news.

Please let me know if you have any more questions.

Cheers!

– Brook

[Brook]

Excellent news! It never hurts to discover you already have everything you need aye?

Please let us know if you ever need anything else.

Cheers!

– Brook

[Brook]

I’m going to give it a try replacing all USD mentioned in your code with GBP which I think will work, but I don’t think that’s a reliable long-term solution, nor is editing each event to fix it manually each time, so I’ll be very grateful when Modern Tribe have a chance to look at this. Will this be in the next update?

I certainly agree. Anything that involves directly editing the plugin is not a good longterm solution.

That would be awesome if already had plans to includes this! But no, there are no plans to include any changes here in the next update.

The more I look at this the more I think this will likely happen in tiered steps:

1. We will add some additional filters to Eventbrite API requests.
2. We will create an extension which allows you to setup a custom currency.

Definitely feel free to give that adjustment a whirl. We are passing that currency along in the cost requests, so altering it will likely work assuming there are no difficulties with the API not functioning as outlined.

The line of code you quote is the defaults for a ticket. Defaults will get overridden based on the data passed. However, as I mentioned earlier our programmers were unable to set the currency with the new API, when it was just released. Thus, we did not add a box to the ticket area for selecting the currency. And because of that, you can not override the defaults from within WP Admin. Furthermore, I am not seeing any filters you could use to override those defaults either. Hence why I think first we will first need to add some filters before a longterm solution is viable.

Please let me know if you have any followup questions. Does changing the default currency in that code work as expected?

Cheers!

– Brook

[Brook]

That is excellent news! I really appreciate your feedback, I shared it with the folks who help out with feature requests.

Please let us know if you ever need anything else. Cheers!

– Brook

[Brook]

Howdy Alan,

We are looking into why that messaging is showing up. A couple of other users have reported this strange behavior.

It should not cause any problems. The only thing our plugin does not do when a license is invalid is automatically update. The plugin runs fine, all features work, it just can’t automatically update. Since you’re on a multisite with a nonmultisite license, you can’t autoupdate anyways. So I guess we could characterize it as overzealous messaging, or more accurately messaging that’s showing when it shouldn’t.

I will let you know what our investigation finds. Likely, this is a bug we can patch in a future update to our plugin. Thus when you update to that version this will go away.

Does that all make sense?

Cheers!

– Brook

[Brook]

Howdy Johanne,

I was able to reproduce your same issue in certain circumstance. This definitely looks like a bug. Given the impact this has I have logged it as out highest priority on a scale of 1-5. Although, it is possible that someone with better knowledge of our priorities will alter this, as it is likely to not impact many users. Thus bugs which impact more users and were reported earlier might take precedence on our list of priorities.

While you wait on a fix, the only two workarounds I can think of:

1. Set ticket orders to auto complete. However, it sounds like this will not work for you due to the circumstance you mentioned.
2. Continue manually completing orders where you have received payment.

So the good news is this is something it looks like we can fix, and we plan to as soon as we reasonably can. As soon as  a fix is ready we will respond to this topic, letting you know you should update your plugin.

Please let us know if you have any questions.

Cheers!

– Brook

[Author]

Posts