Forum Replies Created
-
Posts
-
Hi!
How about a different approach where you set up a filter using the parse_query hook and then, according to the query variables in the URL, modify the start_date and end_date properties of the query? It’s very much customization territory so we can’t offer too much help for something like this, but is probably the cleanest way to handle this (and still enjoy the benefits of pagination etc).
Some of our own logic uses that very same hook (see TribeEventsQuery::parse_query() which runs at priority 50, so you would probably wish to use a higher priority for your own callback) if you want to get a sense of what’s happening “under the hood”.
Yes – that’s a bug that was unfortunately introduced in the latest release and we’re working to get a fix out as quickly as possible. In the meantime, could you workaround it using the steps described here?
On Event page, venue "Website" field is garbled after 3.6 update
Hopefully that at least gives you temporary relief until a substantive fix arrives.
Sorry for the inconvenience!
Interesting!
We’re always on the lookout for things like this and if you want to post a feature request we’d love to hear from you – please do so over on our UserVoice page:
(This just lets others add their support, which can be useful information for us when prioritizing requests.)
Thanks!
How odd – it’s not something I can replicate, though. Is your test site publicly accessible? Can I take a peek with only The Events Calendar/Events Calendar PRO running?
Hi!
The best place to start is with our Themer’s Guide, which covers making safe modifications to plugin templates.
Depending on how your theme is structured it may be possible to add a call to get_sidebar() and pull in the sidebar that way – if not, you may need to use dynamic_sidebar() (both of which are documented in more detail in the WordPress Codex).
Does that help?
Hi Robert,
There’s no means of doing this baked into the plugin, certainly, but perhaps it’s possible to change the status of each order back to pending, then associate each with a ticket product and finally complete the order.
It’s not something that’s really been considered though, so I’m afraid I can’t offer any guarantees there.
Definitely – this came up recently and we’ve got it logged as in need of a fix. Unfortunately we were unable to squeeze it into our 3.6 release, but bear with us and we’ll get a fix out shortly 🙂
OK … that sounds like something where we should possibly make an adjustment – but could you simply avoid posting the same ID multiple times?
You could certainly consider completely deleting (ie, trash them and then, as a precaution, empty the trash) and re-import from there.
Other than that – unless you manually correct them – you could potentially run a few SQL queries perhaps wrapped in a short PHP script to do this. However, this former approach may be easier and safer if you don’t feel comfortable putting the necessary queries together.
We welcome feature requests – but don’t you think it may well be useful in some cases (even if not in your particular case)?
OK, I think I’ll need a little more detail here as I can’t seem to replicate this:
- What is your WordPress timezone setting?
- Are you finding an issue with newly created events or just those created previously?
- Are you creating them initially as single events and then converting them to recurring events after initial publication, as in jourdand’s case?
- Is this only a problem with all day events for you or do you find like jourdand it effects regular events, too?
Sorry for all the questions – but I’d love to get a better handle on this. Thanks!
OK, but unfortunately if these issues all relate to the automated import of events from individual/personal Facebook pages that’s really something we’d have to leave to you to resolve, I’m afraid.
If I’m misunderstanding and you’re hitting problems in the course of ordinary use, though, definitely let me know.
We’re certainly interested in figuring this one out if we can. Please bear with us a little longer though as though we can clearly see it on your own sites, we cannot replicate locally just at this time.
Awesome – glad that’s working for you.
It should work with h:i format and we’ll get that addressed as quickly as we can. Thanks again for your patience and support 🙂
Hi: it’s important to note we typically do not provide support on weekends (nor on public holidays). So while we strive to respond within 24hrs – or faster if we can – that doesn’t unfortunately mean we can reply on Saturday if your last post was made on a Friday. I’m sorry you see that as glacial, we definitely don’t want to leave you feeling isolated, but we do try to be upfront about the level of support we provide.
I just checked my WP time zone setting and changed it to LA (West Coast PST).
On refresh of page/s the times being displayed on the site are still all over the place.Changing the setting at this point will not correct previously imported events, unfortunately – but you should find it resolves the issue whenever you import events from here on. Does that clarify things/can you confirm you are finding it works as expected with newly imported events?
