[Barry]

Glad you’re sorted, @kizmacelroy – I seem unable to replicate quite the same thing if I reset and start the update process again (mimicking the same order of updates you noted) but have asked some team-mates to also test this scenario out. We’ll see what we come up with.

@Math: are you still hitting problems? If so, were you able to follow Cliff’s recommended steps and, with WP_DEBUG in place, are you able to share any more specific errors that might be visible? If you can, this may help us to zero in on the source of the problem.

Thanks – and our apologies for the disruption.

[Barry]

OK – can you try removing the ‘e’ at the end of ‘importante’? To clarify, try with the rule written like this:

.tribe-tickets-remaining {
    display: none !important;
}

[Barry]

Hi Silas:

I see your custom tribe-events/tribe-events.css stylesheet is in place, but there’s a minor error:

tribe-tickets-remaining{
color:#777;
display:none;
font-size:11px
}

To be a valid selector, you need a dot immediately before the class name (with no spaces in-between), as follows:

.tribe-tickets-remaining {
    display: none;
}

Notice I removed the color and font-size rules – you can keep these if you like, but since we don’t want this element to display at all they are surplus 🙂

Does that help?

[Barry]

Ah yes.

There are limits on what we can do when creating events within WordPress and “pushing” them to eventbrite.com (we’re bound by what their API allows us to do) but, depending on which country you are operating from, I believe you can create an event and use any payment method that Eventbrite supports for your tickets – and then successfully import those into your local calendar using our plugins.

This could allow you to take advantage of EventBrite Payment Processing and promote those events from your WordPress installation.

If you wished to give this a try, remember that you have 30 days in which to seek a refund if things turn out not to work as expected.

Does that help, here?

[Barry]

Hi Nick,

I don’t believe there’s any particular restriction in our latest release. Can I confirm which article you are quoting, there?

Thanks!

[Barry]

Hi Silas,

Sounds like you have made a great start!

Overriding rsvp.min.css in this way is not supported, I’m afraid, but if all of your tickets are being added to events you could instead add your rules to tribe-events.css, ie:

betheme-Child/tribe-events/tribe-events.css

Alternatively, how about adding your custom CSS via the Appearance ‣ Customize ‣ Additional CSS option?

Let me know if that helps 🙂

[Barry]

I understand you’re not happy, but we’re doing our best to reply within our stated target response times (24hrs of you posting, not including weekends) and have done so reliably since the start of this exchange.

I’ve got a couple of possible avenues we might follow to get a better handle on this and get things back on track:

• If you already have or can create a staging site, perhaps you could deactivate all other plugins except ours and switch to a default theme and let us see the problem and troubleshoot further under those conditions
• Alternatively, you could use the Duplicator plugin to create a file you can share with us which will allow us to duplicate the same problem on our own machines – we can then troubleshoot and figure things out from there

If you follow the Duplicator route, please note that the resulting file may be very large so it may be easiest to upload it to Dropbox, Google Drive or some other comparable service and provide us with a link to access it from there (which you should share via a private reply).

Unfortunately, we still cannot see your system information. Can you share that with us manually, again via a private reply? That may also provide us with some insights.

[Barry]

Hi there!

There may have been a mixup in your previous exchange and that conversation might have been associated with a bug that, while similar to what you described, was actually separate.

To view tickets and modify custom fields setup via Event Tickets Plus, the logged in customer would need to visit the single event page where they purchased the tickets.

It is not possible to edit attendee data from the WooCommerce-generated /my-account/orders/ page, I’m afraid.

Does that clarify things/help at all?

[Barry]

Hi Amanda,

I’m sorry to see how frustrated you’ve become – all we want to do here is help you.

Also Cliff — the gif you sent testing our site isn’t even our site!

That’s correct. It is from Cliff’s own testing site, which he noted in his first reply.

The point here is that this is not a general problem: Cliff cannot replicate on his own site and other customers are not reporting the same problem so, at this stage, it looks like the problem is specific to your site.

We need this FIXED ASAP! It is affecting ticket sales and NO ONE can HELP US?

Understood. We want to help you fix this – but since we do not control or have access to your site we’re going to need your help and cooperation.

Can I ask you to revisit Cliff’s first reply? It contained a wealth of information and a number of steps aimed at helping us collect more information to better troubleshoot this issue.

If there are elements of that which you do not understand or are having trouble with, please let us know and we’ll offer as much additional guidance as we can.

Thank you 🙂

[Barry]

It’s pretty perplexing.

If you disable all other plugins and switch to a default, unmodified theme (then try flushing the cache again), do things correct themselves?

Keeping the site in that same default state, if you ‘buy’ a few more RSVP-type tickets, do they start to show up in the attendee screen then?

theeventscalendar.com/knowledgebase/testing-for-conflicts

Testing for conflicts in this way (you might want to read through the above resource) is the next logical step, or you could do it in reverse by creating a fresh staging/testing site per my last note – start with a clean WordPress site and nothing but our plugins and see if you can replicate the problem under those conditions.

I’m afraid we’re just not seeing this problem locally and other similar reports turn out to have been a slightly different problem to what you’re describing here, so further troubleshooting as I have outlined is certainly worth a shot.

Do let me know if you have any further questions about this.

[Barry]

Sure – keep us posted 🙂

[Barry]

Hi there!

Sorry to hear you’ve continued to experience difficulties.

Like Jeremy, I find I can’t replicate things locally and when I look at the import records on our Event Aggregator server I can see it is successfully fetching events and is sending them back to your own site, ready for the actual posts/events to be created.

Based on that, whatever the problem is, it seems to be one that is localized to your WordPress installation. We did just ship some further fixes (and adjustments were made to the EA client code) … to that end, can I ask you to update The Events Calendar to our latest version?

If you could also install and activate Transients Manager, wipe all transients and try again that could be worth a shot.

Can you give that a go and let me know if things start to work?

Thanks!

[Barry]

Excellent, thanks for confirming 🙂

I’ll go ahead and close this topic, but please do open fresh topics as needed if we might be able to help with anything else.

[Barry]

Thanks for confirming!

If we can help with anything else, please don’t hesitate to create a fresh topic — one of the team will be only too happy to assist 🙂

[Barry]

Thanks for the update!

Yoast #10188 | Yoast #10258

My reading of these two issues is that the core problem happens when Salient (which it looks like you are also using) is present. In fact, in the second of those issues, our plugins are not mentioned/aren’t required for the same core problem to occur.

That to say, it does rather seem like a problem that the Salient crew should work on resolving. Have you reached out to them about this issue?

[Author]

Posts