[Barry]

OK, from our standpoint though I’m not sure what else to suggest. Would it be possible to test this out on a test site (could be as simple as installing a fresh copy of WordPress in a subdirectory, and initially installing only our plugins) and see if the problem can be replicated there – without your theme?

Depending on the test result, of course, you could continue to verify if adding your theme brings about the problem you described.

[Barry]

I can definitely appreciate that.

Let me try to address some of your points, though – they’re all perfectly valid and I’ve no doubt we could make some improvements here but I did want to at least give an idea of why we operate the way we do.

Closing off the original ticket makes it feel like you have no way to get an update on the status of the bug fix (especially when no time period is given), I really didn’t want to open a new thread but didn’t see another way.

In no way do we want to “slam the door shut” by closing a topic – but we do (as Casey noted in his last reply) typically reopen and post an update, as soon as we have something to update. So it’s always possible to check in periodically and of course if you’ve subscribed to updates you’ll normally receive an email.

Generally we do close topics wherever possible – it’s an important control measure for us because the unfortunate reality is that topics are prone to being “gate crashed” and derailed if they’re left open.

For a bug like this that breaks an essential part of WordPress core, I would imagine this is a high priority item.

I don’t disagree and will raise this with the team – if we can reasonably raise its priority (in relation to existing issues) we’ll certainly do so.

…it “potentially may wait for more than one release cycle.” because it isn’t a high priority (which I beg to differ). So essentially I could be waiting 1-6 months for a bug fix that is effecting multiple of my WordPress sites. That seems pretty crazy and not very reasonable at all, especially for a paid subscription.

I don’t want to bog the conversation down with a semantic debate 😉 … but to clarify, I did not say this isn’t a high priority – rather I stated that there may be other bugs which happen to be higher priorities.

All that to say, I’m sorry we didn’t meet your expectations here. Please bear with me and I’ll update you again shortly once we’ve had an opportunity to reassess.

[Barry]

No problem, I’m sorry there’s not a faster way to go about it – though this sort of troubleshooting (even on a dev site) can be a bit time consuming it’s definitely proven to be hugely reliable in most cases.

I’ll leave this open and look forward to your next update 🙂

[Barry]

Fantastic 🙂

 

[Barry]

Hi!

Apologies for the delay, looks like this thread was unfortunately overlooked 🙁

Essentially, there is no built-in mechanism for positioning your main events page on the front page of your blog – however you could certainly use our range of widgets to achieve this (and customize them to include more detail etc) or else you could look at third party plugins such as Event Rocket to help you achieve this goal.

Does that help at all?

[Barry]

Hi Paul,

There’s not really a built-in mechanism for this. Currently the best approach is to cancel the existing order, delete the corresponding entries from the attendee list and then build a fresh order through WooCommerce’s order editor.

Would that work here? Certainly if you’d like to see a more integrated approach we’d love to hear from you over on our feature request page (UserVoice).

Thanks!

[Barry]

Hi – sorry to hear you’re hitting difficulties.

There is unfortunately a bug here and it relates to accessing day view (for “today”) when using default or “ugly” permalinks. Would it be possible for you to investigate switching to pretty permalinks?

Often this is as easy as navigating to the Permalinks Settings screen and selecting an option like %postname% then saving the changes.

Does that help?

[Barry]

Very strange – I believe that is the first time we’ve had such a report.

In the first instance can you set up a regular WooCommerce product (ie, not a ticket) and run through the transaction process? Does the same thing happen?

[Barry]

Do you mean embedding events via shortcodes, or something like that? If so we’re certainly aware of the demand for this and definitely encourage you to show your own support over on our UserVoice page – and if you see the implementation as being something other than shortcodes, again, we’d absolutely be interested in hearing your thoughts 🙂

Thanks!

[Barry]

Thanks for confirming Tony – we’ve got this logged and will fix it as soon as we can 🙂

[Barry]

Hi Martin,

That’s a puzzling problem. It does look like you indicated having already run through our standard troubleshooting steps though which is awesome:

YES, I’ve deactivated all other plugins to check for a plugin conflict.
YES, I’ve reverted to the 2011 default WordPress theme (with other plugins still deactivated) to check for a theme conflict.

Did that make any difference or allow you to isolate any conflicts?

[Barry]

Thanks Andy!

@cvaughn does that help?

[Barry]

Hi – sorry it’s not working for you.

Perhaps your theme or another plugin is interfering?

Unfortunately, we don’t really have too much control over the image etc that Facebook picks when you embed a link within their own service. Running through our standard troubleshooting steps though might help you to isolate if there’s a conflict somewhere along the line.

[Barry]

Hi – sorry you’re hitting difficulties!

Can you share the code you’ve added to your custom pro/widgets/list-widget.php template? Sharing via Pastebin or Gist (or some similar service) is best rather than posting directly in the forum.

Do also note the above filepath – the extra pro segment – as that is one place where it looks like the tutorial has come out of sync (so, basically, your custom version should live at your-theme/tribe-events/pro/widgets/list-widget.php).

 

[Barry]

Hi – thanks for following up on this one.

I’m afraid that we don’t have anything further to report just yet – but I can assure you that Casey logged this and it will be addressed in a future maintenance release. We also do our best to post updates in the original thread (as soon as we’re ready and able to do so).

Generally speaking though it’s important to understand that a new release goes out once every 1-2 months – so in terms of time-scale you should not expect anything until a little more time has elapsed, especially as something like this potentially may wait for more than one release cycle – simply because there are often a number of existing bugs that have been in need of attention and are higher priorities.

I hope that clarifies things and thanks again for getting in touch 🙂

[Author]

Posts