Forum Replies Created
-
AuthorPosts
-
October 3, 2014 at 4:37 pm in reply to: Organizer URL: modifying "tribe_organizer" in organizer slug #786113
Barry
MemberIt shouldn’t make a difference: if you start with a few manually generated events and organizers and find you can’t replicate it, though, there’s no harm in importing some more from an existing source. If there’s a difference, that could tell us something interesting.
October 3, 2014 at 1:52 pm in reply to: Organizer URL: modifying "tribe_organizer" in organizer slug #785868Barry
MemberI simply set up a multisite network with the latest versions of The Events Calendar and Events Calendar PRO, set up a subsite and some test events/organizers etc within it – and checked out the appearance of the permalinks.
You don’t necessarily need to create a brand new network though – so long as you have a test installation that is multisite, you could just take things back temporarily to that state, flush permalinks and see what happens.
Barry
MemberAwesome 🙂
Barry
MemberInteresting. Strangely I don’t see it and I don’t know of anyone else reporting it.
Can you try running through our standard testing-for-conflict steps? Perhaps something else is impacting?
Barry
MemberHi nbuckland,
I’m sorry to hear the update to 3.8 breaks your site. We do try to stick to one issue per thread though, so let’s deal with the initial question you asked in this thread – but of course please don’t hesitate to create a new thread for any 3.8-related issues, one of the team will be only too happy to help.
Is there some way to view a list of previously attended events for a specific user? I teach hundreds of classes per year and I would like to view a user’s profile to see a list of classes he’s attended without having to look through all the attendee lists.
No purpose-built functionality exists for this, but it would certainly be possible to build a custom component that implements this (that would however be sufficiently complex as to be out of the scope of what we can help you with here on the forums).
I can definitely see the potential for this sort of functionality and would encourage you to post a feature request – doing so allows others to up-vote and comment on the idea, giving us a really good sense of how many people might need this.
Does that answer your question?
October 3, 2014 at 1:39 pm in reply to: Refunding Tickets doesn't change # of available tickets & still allows checkin #785828Barry
MemberHi Christina,
Great question!
If you manually intervene and cancel (or refund) an order, that does not automatically result in re-stocking of inventory and this is an intentional behaviour on the part of WooCommerce: just because you give someone their money back doesn’t always mean they won’t still be attending – similarly, if you cancel a shipped order in a non-ticketing context you won’t necessarily get those units of stock back … for reasons like those, WooCommerce by design requires the merchant to manually adjust stock in scenarios like this.
It should flag up the fact that the ticket was refunded (or cancelled) in the attendee list, if that isn’t happening then there’s definitely an issue – but it is expected for them to remain in the list.
Does that clarify things at all?
Barry
MemberHi – I’m sorry it’s not working for you.
3.7 is still working on another live site, which I’m using for comparison: http://www.17statestreetcafe.com/events/month/
…
Note – this was happening with 3.7 as well, I just checked an older site and the bug is also there.So if I’m not mistaken, it sounds like it is working on at least one site with 3.7, but not on a different 3.7 site and additionally not on a site with 3.8 – is that correct?
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.Might this actually be a conflict? I do appreciate when you created this thread you noted having already run through our standard troubleshooting steps as above: just for the avoidance of any doubt, can you confirm that didn’t lead you to identify any conflicts?
(And/or could this stem from event-related customizations that are in place on some of your sites but not others?)
Barry
MemberThanks for clarifying.
I can understand why your developer sees a link to the categories, yet I can’t help but suspect something else – be it code in another plugin or your theme – is applying a taxonomy query: I don’t at this time believe our plugin is generating those extra inner joins, unless I am misunderstanding the circumstances in which this is happening.
it happens on this page (http://blank.woodlandevents.eu/eventsmap/) ..
So I mean it seems to be up and running and seems pretty snappy and responsive. Has something changed to avoid the server crashing? Would I need to perform some other action to see the problem at work?
we are absolutely sure that there’s no conflict.
OK, but we’re still pretty puzzled by this as we cannot replicate it.
Could you create a test site – this could be as simple as a fresh WordPress installation in a subdirectory – and install and activate only The Events Calendar, Events Calendar PRO and also Debug Bar but nothing else – then create some test events and categories and see if the same query is formed?
If so and before you install or activate any other plugins (or anything other than a default theme), can you provide us with access so we can take a look at the site?
Thanks!
Barry
MemberHi vistagemarketing,
It appears that in both 3.7 and 3.8 the Chosen div’s have the class .chzn-container, however, in the new 3.8 the stylesheet (chosen.min.css) uses the selector ‘.chosen-container’
Can you clarify where you are seeing this problem exactly? So far as I can tell we updated most or all of them – but if you can point me to a specific example that would be awesome. Do you have any customizations in place that might be impacting/could this be a browser caching issue or something of that nature?
Thanks!
Barry
MemberIt is something that strikes lots of people as odd, yet it’s fairly standard and I’d tend to see it as a feature: if you were handling credit cards, for instance, you might wish to review the order etc – partly to filter out fraudulent transactions but also for other standard checks – before charging it.
Though you may be using PayPal, the same process exists and similar reasoning probably sits behind that … but, at the end of the day, the best people to speak to on this count are the team over at WooThemes.
It seems to be processing automatically in your demo here: https://theeventscalendar.com/support/documentation/wootickets-new-user-primer/#installwoo
I’m wondering if he had to make this adjustment for this to happen?Hmm, I don’t think so – if you look at the third video (purchase experience & processing an order) you’ll see Rob explicitly notes needing to mark the order complete. The workaround I linked to should help you out here – but again if you hit difficulties it is probably worth talking to WooCommerce’s own authors/support team.
Thanks!
Barry
MemberHi partynews,
Fantastic that the original problem is solved 🙂
How we can display the events of an organizer and a country?
For organizers, the answer is organizer view! Do note that that requires you install and activate Events Calendar PRO, though. To form a list by country it’s going to be just a little bit harder; but an easy avenue is to categorize or tag them accordingly – then simply view all events in that category (“countries/United Kingdom” or whatever structure works for you).
If you do have any further questions on this we’re more than happy to help – but please do create a fresh thread: we try hard to stick to one issue or question per thread.
Thanks again!
October 3, 2014 at 8:57 am in reply to: Organizer URL: modifying "tribe_organizer" in organizer slug #785253Barry
MemberOK. I can’t seem to replicate with an otherwise “plain vanilla” setup using multisite (with subsites/subdirectories rather than subdomains), either.
If you do a similar test and flush permalinks, etc, do you find the same thing still occurs?
Barry
MemberThat is a great question.
The first thing I want to emphasize is that we’re actively working on a fix that will resolve or at least reduce the potential for collisions of this nature – the WordPress ecosphere being what it is, though, this sort of thing can be very hard to guard against and I wouldn’t really say that either ours or Mailchimp’s code is at fault, as such.
I do realize temporarily deactivating Mailchimp until any fix we can deliver is released may not be the most appealing way forward, but that is one path. Another is to try removing their widget only on single event/venue pages.
There are a few ways you can control the deployment of widgets to do something like this and it’s worth doing a bit of research to see which solution you like best, but one plugin that immediately comes to mind is Widget Logic:
wordpress.org/plugins/widget-logic/
This allows you to specify a set of conditions that must be met before the widget is displayed. So, for the Mailchimp widget, you might add a condition like this:
! ( is_singular() && tribe_is_event_query() )(The leading
!symbol is important here) and that should block it from displaying on single event/venue pages. If this works then, again, it need only be in place as a temporary solution.That could definitely be worth a try here.
Barry
MemberAwesome that worked for you jebs38, happy to hear it 🙂
Thomas: yes, there is definitely a conflict with Mailchimp – in fact it’s a problem with their datepicker code which happens to have this side effect. We’re aware of it and are working as quickly as we can toward a fix for that one.
October 3, 2014 at 8:15 am in reply to: Adding new eventDisplay types (extending beyond map, photo, etc) #785161Barry
Member<p>Good stuff :-)</p><p>I’ll go ahead and close this one out, but if we can help with anything else please don’t hesitate to create new threads as needed and one of the team will be only too happy to assist.</p><p>Thanks again!</p>
-
AuthorPosts
