[Barry]

OK – well glad it’s working 🙂

I’ll go ahead and close this thread – of course if we can help with anything else please don’t hesitate to create new threads as needed.

Thanks!

[Barry]

You’re right – and it turns out this is a bug we’ve got on the system. Sorry for the inconvenience – but we’ll fix it as soon as we can and will reopen this thread to post an update as soon as we have something to report.

Thanks for your patience!

[Barry]

Hi, yes regular side widget, the strange thing is I’ve not dona anything new, and its gone??

It looks like it’s still there to me – did you manage to restore it? Can you also reply to my previous question:

What happens if you deactivate all other plugins and switch to a default, unmodified theme – do you still hit the same problem with that widget?

This is a useful process to go through as very often the problem is a conflict either with a theme or another plugin.

Thanks!

[Barry]

Awesome, glad you got there and happy we could help 🙂

I’ll go ahead and close this thread – if we can help with anything else though please don’t hesitate to create new threads as needed and, if you have a moment to spare, we’d love to hear about your experiences with The Events Calendar so far.

Thanks again!

[Barry]

That’s definitely odd.

Unfortunately it’s not something I can replicate locally: with WordPress Importer activated the Community Events submission form behaves as expected.

Perhaps it’s something of a red herring … unless you tested with all other plugins deactivated and only a default (and unmodified) theme enabled, I’d be reluctant to chalk this down to a conflict. I wonder if in fact it may be a memory issue?

In any case, it sounds like you have a working solution in the form of deactivating the WP Importer which is of course the important thing 🙂

[Barry]

Thank you, that was helpful – I can now replicate this (the problem hinges on the products custom post type being enabled via the WPML → Translations → Custom Posts options).

If it so happened you were able to change that setting as a temporary workaround that would be great, but I do realize that may not be practical. Bear with me a little longer and I’ll see if I can discover anything else as to why this is happening.

Thanks!

[Barry]

That’s a great question but, unfortunately, a hard one to answer as each email service potentially uses a different form of spam filtering.

It could be that because the customer received two emails in rapid succession from the same source (faster than a human can ordinarily send them) the filters are using that as an indicator of spaminess … it could also be due to keywords in the ticket email – which naturally would depend on the product names, etc. Quite likely there are other factors and it’s probably a combination of many of them.

The best I can really suggest – unless of course you are already doing this – is configuring WordPress to send emails through a suitable third party email service with proper safeguards in place. Unfortunately, especially in many shared hosting accounts, the default mechanisms for dispatching email aren’t quite tight enough to avoid issues like this.

I hope that helps 🙂

[Barry]

Please note this thread will no longer be monitored by staff – if you still need help with this or anything else, please don’t hesitate to create new threads as needed. Thanks!

[Barry]

Excellent – glad that worked.

I’ve added this thread to a list on our internal bug tracking software, so as soon as we’ve got a fix in hand we’ll do our best to pop back in here and let you know.

Thanks!

[Barry]

Glad you figured out a solution 🙂

[Barry]

Awesome 🙂

[Barry]

Definitely, thanks for sharing.

I think the problem with that strategy though is perhaps that it is executed at a level whereby even WooCommerce is unaware of it. What I mean by that is, for the ticket form we obtain the action URL from WooCommerce itself (which, ultimately, uses WordPress’s get_permalink() function). If it “knew” that the cart page was served via HTTPS then it would provide us with an HTTPS URL … of course what we see here is that it doesn’t do so.

Probably then the best way forward is to augment this tweak by filtering on post_link (and forcing the URL to HTTPS if it relates to the cart page).

As it sounds like you only wanted to keep us in the loop I’ll go ahead and close this thread – but thanks again for sharing, it could definitely be useful information for others in the same situation 🙂

[Barry]

OK. So I’m not sure why things didn’t work properly when you took things back to a basic state, but really that’s a separate problem. What I’d recommend here is talking to the theme author about the particular problem you’ve described here as it looks to me like it’s a consequence of the custom event templates that ship with the theme.

[Barry]

OK, so your theme is assuming that all of the items on that timeline are posts and so is targeting them with rules like this one:

.timeline-layout .post.align-left{width:300px;float:left;clear:left;}

Events are not blog posts though and so the posts class is not applicable. To workaround this, you would either need to add matching rules such as:

.timeline-layout .tribe-events.align-left{width:300px;float:left;clear:left;}

For each of the timeline layout rules, or else take steps to also add the post class to all events in the timeline, or, change the rule so it isn’t so specific.

I hope that helps!

[Barry]

Yes, sorry – I realize you are using EDD but often work with people using WooCommerce Tickets and, well, that just slipped out 🙂

Can you confirm where you are seeing that screenshot? Is that in the attendee list screen (if so, I can’t replicate the same thing – when I delete attendee entries those rows disappear entirely … is it possible there is a theme or plugin conflict there?).

[Author]

Posts