Forum Replies Created
-
Posts
-
Hi there nilskau,
I just wanted to check in and see if you have had an opportunity to explore that last point (about the potential for a conflict with another plugin or with your theme)?
Hi theimageworks,
That’s a great idea and it looks like you’re almost there. Full steps for setting up template overrides can be found in our Themer’s Guide so that is worth reading, but the key point is that they should be contained in a directory called tribe-events (rather than events-calendar-pro as you have done).
So, to override the single event template from within your child theme, try:
themes/my_theme/tribe-events/single-event.phpDoes that help?
That’s certainly odd – and not something I recall seeing reports of.
Is it possible a conflict is at work and can you try running through our standard testing steps either on your live site or on a test site where you can also replicate the problem?
Does that uncover anything?
I’m sorry it’s not working for you.
Basically, you need to take the time zone of our home office OUT of the time zone equation. The location of our office makes no difference.
So can you confirm what your local (WordPress) time zone actually is? I’m not sure we can take this out of the equation entirely – though perhaps we can introduce some sort of toggle – without causing problems for other users.
Hi – that’s a great question – though it is (as you noted) a customization request and a fairly advanced one at that, so we can’t go into too much depth on this one I’m afraid.
That said, I can certainly offer a few pointers and indeed I think on this occasion there is something for us to improve on (in our codebase), too.
- It sounds like you are modifying core plugin code – that’s to be avoided!
- Similarly, you are adding your new filter code to the core plugin directory – again, try to avoid that!
- I’d guess the basic problem here is that your custom taxonomy filter’s tax query is overwriting the plugin’s own category tax query (or vice versa, which way round will depend on the order they are registered)
- The reason such a collision doesn’t occur with the built-in category and tag filters is that the tag filter is making use of the tag__in query argument
All in all then:
- You need to merge existing tax query arguments into your custom filter’s tax query
- Naturally you don’t want our category filter to wipe these out: so you’d probably need to wrangle things so your code runs after ours
- I’ll make a note for us to check into this and see if we can avoid such collisions going forward
I hope that helps!
Hi! It’s been a while so I’m going to go ahead and close this thread (and so it will no longer be monitored by staff). If we can help with anything else, though, please don’t hesitate to create new threads as needed. Thanks!
Hi! It’s been a while so I’m going to go ahead and close this thread (and so it will no longer be monitored by staff). If we can help with anything else, though, please don’t hesitate to create new threads as needed. Thanks!
Hi! It’s been a while so I’m going to go ahead and close this thread (and so it will no longer be monitored by staff). If we can help with anything else, though, please don’t hesitate to create new threads as needed. Thanks!
Hi! It’s been a while so I’m going to go ahead and close this thread (and so it will no longer be monitored by staff). If we can help with anything else, though, please don’t hesitate to create new threads as needed. Thanks!
Hi Jon,
Thanks for contacting us.
screenshot of recurrence pattern: https://cloudup.com/cmlzHahXTOB
…
Note: The DB for this site isn’t small, but it’s not really big either. 12,000 posts, 6000 comments, 200 categories, 11,000 tags.
Thank you for sharing this – it gives us a much better picture of your setup and what you’re experiencing.
That particular pattern, if I’m reading it correctly, will result in 402 individual events – all stored in WordPress’s posts table. So, if you make an update, that’s 402 posts that need to be modified.
As you can imagine that is a lot of work and given this the timeout perhaps is not surprising.
It doesn’t surprise me WPE kills long running PHP processes at 60 seconds, most hosts do. It does surprise me that TEC isn’t doing something to avoid this timeout though.
That’s definitely a valid point. A few ideas come to mind but, as I hope you can appreciate, none are trivial changes and this is something we’re going to need to discuss before potentially taking further action.
In the interim would breaking chains of events up into smaller chunks be a viable workaround?
Hi Nicole,
That does make sense and I guess one approach (if you’re managing this from a single site) would be to make use of categories – you could simply have a category for each language and, if you need to embed this on the front page, you could do so with our calendar widget and set it to the appropriate category.
I have to be upfront, though, I suspect there would be a few pieces of custom development work needed to make this work in the way you envision – but that is probably true of all comparable calendar solutions at this time and while others may not always offer a straightforward customization path, I can strongly vouch for the customizability of ours 🙂
Thanks again!
That’s possible. Would a move to the current system be viable? Though I appreciate that may mean some amount of work it is a far simpler system in its current form.
OK. It’s certainly sounding like a problem with some of the custom code in the child theme, in that case – it will be interesting to hear what you uncover.
Hi! It’s been a while so I’m going to go ahead and close this thread. If we can help with anything else, though, please don’t hesitate to create new threads as needed. Thanks!
