[Brook]

Howdy Karl,

Your last response here was a bit blank. Were you trying to respond to my questions above?

Cheers!

– Brook

[Brook]

Perfect! Happy to hear it. Thanks for getting back.

• Brook

[Brook]

Howdy Douglas,

Are you experiencing the same error, namely a SQL error upon reindex? Or, is there some other way that Facet stops working for you? The two plugins are currently working perfectly for me and mostly working for Nicholas, so they are not wholly incompatible.

If you are seeing a distinct issue would you mind opening a new topic dedicated to it, and describing in detail what is happening? In particular your performance issues sound like the symptom of a server that is just not powerful enough for the two plugins side-by-side. In reading through Facet’s documentation it is clear that plugin often hits performance walls on slow servers. Ours does too. Which makes sense in both cases because the SQL queries necessary to run filtering or calendars are quite intensive on SQL servers. Running both a calendar plugin and a filter one will mean you will need an even more powerful server than usual. So the more info we have about your issue the better we will be able to advise you.

We actually do have an addon to allow public users to submit events! Community Events.

Cheers!

– Brook

[Brook]

Howdy Nicholas,

Are you still seeing this issue on the latest FacetWP? I have testing it as extensively as I can the past couple of day and have yet to see any SQL errors upon reindex. Everything appears to be working great. I noticed that the last couple version of Facet have some impprovements/fixes that might be relevant, so it is possible they fixed this for you as well?

Cheers!

– Brook

[Brook]

Any answer I could give you would be a personal guess, Kent. Even I do not place much stock in my guesses in this case.

You see, we are switching to a new release schedule right now. You may have noticed that roughly a year ago we began releasing new features much much quicker than years precivious. That was a purposeful thoroughly planned endeavor, and we were able to address an enormous chunk of our most popular requests. Now we are working on releasing bug fixes much quicker by doing a “maintenance release” every ~couple weeks. Ultimately this change will speed up both bugfix and feature releases, by making sure that new features are not delayed by a bugfix and that bugfixes are not delayed by a feature taking longer to build than expected. But given that 4.0.6 was our first release under this new schedule, we do not have enough experience with it yet to give accurate predictions.

If I was to speculate I would say we will see shortcodes within 6 months. Take that for what it is.

Edit: No dev branch yet. As I said we are respeccing this as of Monday. But, if you’re interested in beta testing it once its ready please checkout: The Events Calendar Beta Signup Form.

– Brook

[Brook]

That makes sense Tom. #1 from your screenshot is the  Date search, and that particular would be a pain to find.

For List view the file/string location is /the-events-calendar/src/Tribe/Main.php:4469 You Will see Month view just above it on line 4467. In Say What? The strings will be:

• %s In

• %s From

For #2 in your screenshot, it can be found in same Main.php file on line 4439. The text in Say What? would be:

Search

Are you able to modify those strings now, armed with the above knowledge?

Cheers!

– Brook

[Brook]

Howdy Stephen,

Thanks for your understanding, I am very sad that this is not working as expected.

I looked into this a while back while creating a snippet. Let me first give you some background on how Event Tickets Plus / WooTickets works.

When you add a Ticket to an event that ticket is actually a regular product in WooCommerce, albeit hidden from most views. When you add a ticket to a recurring event the same thing happens, a single product is added to the WooCommerce store, making it available for purchase.

When a potential customer views any event in a recurring series they will see the same product for sale each time, the same ticket. When they hit “Add to Cart” that product is added to their cart. It doesn’t matter if they  were viewing the January occurrence or the February one, the same product ends up in their cart with no other identifying info.

It is well after the above “add to cart” phase that the emails get sent out. When that happens the only real record of what was purchased is the Woo Product ID. From that product ID we can extrapolate the event series, but not the event itself ( using the function tribe_events_get_ticket_event() ).

So you would have to add some identifying information and carry it through past the checkout screen. The easiest way might be storing that data as a session variable. Perhaps hook into one of the WooCommerce add to cart actions, and then check $_SERVER[‘HTTP_REFERER’] to see what date was used for adding the product to the cart? In our upcoming solution we will probably end up adding a unique product for each occurrence. This will allow you to manage the stock for each event separately, make it easy to use our checkin tool, etc. But if all you want is to have the recurring event date printed alongside the ticket info then it can be much simpler. Add that identifying info however you think is easiest, then print it out somewhere in the following email template: /event-tickets/src/views/tickets/email.php which can be overriden by following our Themer’s Guide.

Does that paint a pretty clear picture? Do you think you have what you need to take a whack at customizing this?

Cheers!

– Brook

[Brook]

You are welcome crossover. Thanks for your understanding here, I wish setting up HTTPS was more universal and I could be of more help.

Let me know what I can do or if your dev has any questions. Cheers!

– Brook

[Brook]

Thank you for getting back Greg. I am happy to know you found the issue. Very strange that you have two of those functions somehow. When I do a folder search for all of our plugins that name doesn’t show up, even doing search through all of our branches in git. That shouldn’t be a duplicate function, unless the old snippet is still in there somewhere, perhaps with the action commented out but the unused function still remaining?

Regardless it’s great that you got it working. Let me know if you need anything else.

Cheers!

– Brook

[Brook]

Howdy Win-River!

By same problem do you mean you’re seeing a 404 on the events page that goes away when you remove this snippet?

function tribe_set_default_date () {
if ( !is_single() && empty( $_REQUEST[‘tribe-bar-date’] ) ) {
$_REQUEST[‘tribe-bar-date’] = ‘2016-07-01’;
}
}
add_action( ‘parse_query’, ‘tribe_set_default_date’ );

If so, have you tried the new snippet?

https://gist.github.com/elimn/d034dfddb9be206d9cc1

Or if that’s not quite your problem, mind opening a new topic and describing the issue in detail? We would love to help!

Cheers!

– Brook

[Brook]

Thanks for the reminder Douglas. Mr. Gibbs actually did get back to me quickly, but then my I lost my virtual sticky note to test this out. I just got in touch with him again, got the latest copy of the plugin, and am starting testing. I’ll report back in a few hours.

• Brook

[Brook]

Howdy Mike,

I am happy to help! You’ve definitely been with us a while to not even be on Modern Tribe’s version.

You might be perfectly safe doing:

• 2.0
• 3.0.3
• 4.0.4

But since manual upgrades are fairly quick to do, but testing to see if anything is broken can be lengthy, I figured why not do the upgrade? (Manual Updates Tutorial)

At least most of your data should import, even if jumping direct to the latest version. If there is any corruption it is likely to disappear by simply resaving an event. If there are missing details though, these will need to be filled back in.

Let me know if you have any more questions. Cheers!

– Brook

[Brook]

You are correct. The city is only used to fill in the <input> field. It might be nice to fill it in if you wanted to, but I do not see why it would be necessary.

Let us know how it goes, and if we can assist with our API any.

Cheers!

– Brook

[Brook]

Thanks for looking. Could you try:

1. Temporarily renaming /tribe-events/ to /tribe-events-bak/.
2. Does it load the venue template now and get rid of that date/time?
3. Rename it back.
4. If renaming it did get rid of the issue temporarily try renaming the files/folders inside their until the issue goes away again, Do this until you can isolate what file is causing the problem. Once you know the file, would you mind sharing a copy of it? Perhaps upload it to pastebin or gist?

• Brook

[Brook]

I’d be happy to explain this a bit more. 🙂 Anytime there is a JavaScript error this happens. This is the nature of JavaScript and just something all websites have to live with. There are millions of different causes for halting JavaScript errors, but they all result in JavaScript not working anywhere on the page. Typically the most visible thing on the event pages that relies on JavaScript working is the loading spinner, but drop down menus, maps, contact forms, all kinds of things can stop working as well. So yes, we certainly do see a lot of “loading spinner not working” topics. But if you read through them you will notice the cause is different nearly every time.

In your case the cause is that your server isn’t configured properly to work with WordPress. Basically you need to either disable HTTPS to make it WordPress compatible, or setup WordPress to fully work with HTTPS. Depending on your website host this can be a very simple process or a very complex one. And unfortunately it’s not one I can really assist you with. But, once your server and WordPress are configured to work together, that JavaScript error should go away and every plugin that relies on the WP Ajax API, including ours, will start working.

Does that make more sense now?

• Brook

[Author]

Posts