[Barry]

Hi Glenn,

I absolutely agree this has been a frustrating process and your email has been passed to the head of support who I am sure will respond in due course. In the meantime, I’ll try and answer your most recent questions in turn.

we went through the painstaking process of creating an NVS[?]/SOAP app – i cannot believe that all of that work is necessary just to create an app to get Live API credentials.

I’m not sure what to say here except that this is a requirement of PayPal’s adaptive payments system, we can’t use an alternative unless they (PayPal) make one available.

It was certainly a failing on our side not to highlight this step in our knowledgebase and we have initiated corrective action on this count.

another question: is it normal that in the backend under WooC > Checkout > Tribe PayPal Adaptive Payments there is absolutely nothing there but a “Save” button???

The user interface with regards to our adaptive payments gateway could be improved upon and, in the course of handling your enquiries, that is also something that I have requested we review and revise.

For the time being, though, yes that is expected.

And what about the REST API checkbox under WooCommerce > API that was checked when I installed the plugin? is it supposed to be checked?

That’s not directly related to this set of problems: essentially, check it if you wish to take advantage of it or uncheck it if you wish to disable it. For further advice on WooCommerce’s REST API specifically I’d recommend reviewing their own documentation or even contacting their support team.

you “recommend” that we enable the PayPal IPN? it’s either needed or it’s not, isn’t it? that sounds kind of vague, i’m afraid.

Well, no, it’s not necessarily a case of it’s needed or it isn’t.

IPN allows PayPal to “talk” to your store and provide an update re the payment status. Generally this is a desirable thing because it automates the process of updating your order data – however, it’s an optional step that you don’t strictly need to enable.

For that reason it’s something I (strongly) recommend but you don’t have to if for instance it will get in the way of you as a developer implementing some other objective for your client.

the more I think about it, the more I think I’d like to request some kind of Supervisor to contact us.

Again, we’re sorry for this hasn’t been as smooth as it could have been and please rest assured that this exchange has already been drawn to the attention of the team leadership 🙂

[Barry]

Tony (and indeed everyone): your feedback in response to this recent change has been very valuable and we’re sorry that we’ve let so many of you down.

We had already taken on-board the need to at least make this data available via export, but I’ve gone ahead and logged a further action point about maintaining separate columns within the regular attendee list (and fixing filterability of purchaser names), too.

Once again I can’t offer any promises as to when this work will be processed, but we’re certainly mindful of just how many voices there are in this and other threads and will prioritize accordingly.

[Barry]

For sure – and thank you for your support and patience while we worked through this 🙂

[Barry]

Glad you found a way to tweak things 🙂

[Barry]

Sorry to hear that.

What I’d recommend in that case – as it seems you are facing something particularly odd here – is creating a new topic of your own. That way you can share your system information and other details and one of the team can help you out with this specific problem.

Thanks!

[Barry]

Yes – a subscriber can upload photos via the frontend submission form 🙂

[Barry]

In general, I’d recommend staying up-to-date: if this glitch does occur again in the process of updating things definitely let us know – but I’d hope that the fix remains the same 🙂

[Barry]

Hi Jennifer!

The purchaser name and email should still be visible in the attendee screen – they’ve just changed location and now live in the Ticket Type column.

Is there a reason that doesn’t work for you or are you seeing something other than that?

[Barry]

… The redirection part of the problem, from /veranstaltungskalender/ to /kalendar/, does seem pretty odd. If the above steps don’t help would you be able to try our standard troubleshooting steps?

Thanks!

[Barry]

Hi Florian,

My mistake with the proposed settings page fix: the slug setting is indeed within Events → Settings → General, however please visit Events → Settings → Display and toggle some of the selected views on and off – save the change then restore the actual set of views you wish to use – and save again.

Does that help?

[Barry]

Yes, you kinda missed that part in your “knowledgebase.”

Unfortunately so – and I can only apologize for that omission.

Regarding IPN, yes – I would recommend you activate it.

[Barry]

Hi Flo,

Sorry for not being clearer – but for future reference this is the system info we generally ask for:

theeventscalendar.com/knowledgebase/sharing-sys-info/

Before you go any further though, can I ask you to visit Events → Settings → General and re-save that screen (you may need to amend the event slug field, save, then set it back and save again): does that resolve this? We found that worked for a different user with an otherwise very similar problem.

[Barry]

Thanks!

So you seem to have some customizations in place – one of which is a custom wootickets/tickets.php template (located within your child theme’s tribe-events directory) and my guess is you have also done something to change the position in which the ticket form displays.

What I suspect is that one or more customizations are getting in the way here. Can you temporarily disable them, starting with the most obvious ones (like the custom tickets template) and see if that resolves the problem at hand?

[Barry]

Fantastic, I’ll go ahead and close this topic but of course please don’t hesitate to create new topics as needed if you have any further questions.

[Barry]

Excellent, I’m glad to hear that Daniel and our apologies for the disruption.

[Author]

Posts