[Rob]

Hey Christopher. Thanks for the heads up here; this is odd, since you are in a very small minority of folks still having problems as of 3.1; there were indeed some month view load time problems in pre-3.1 versions, but those were addressed with this release. This leads me to believe there may be something related to your site.

That said, we’ve got a 3.2 release for both core + PRO releasing right now. Can you try updating when the prompts hit your site (which should be shortly if you don’t see them already) and let us know if you have any better luck with the fresher codebase?

[Rob]

Hey mastafu. Thanks for the follow-up here. I’ve got Casey, our resident Community Events expert, on deck to reply to you in full tomorrow on this. Thanks for your patience thus far.

[Rob]

Hey Sean: thanks for this follow-up. I’m sorry to hear that those solutions don’t get you where you need to be…why don’t you let us know after thinking it over how you’d like to proceed, and we’ll take it from there. Sound good?

[Rob]

Hey Sean. Julie passed your note along my way, and I wanted to step in here because I’m a bit concerned at the specifics of this problem. I really apologize for your poor experience so far. I know what it’s like to be faced with a problem like this and we do want to do our best to get you sorted.

That said: based on what I’m seeing here it sounds like this is almost certainly a byproduct of something else at your system – either a conflict with another plugin or the theme (I know you’ve deactivated other plugins, but I’m not sure by reviewing the thread if you ever have tested on a Twenty Eleven/Twenty Twelve/Twenty Thirteen). If this is not a conflict then there may be something at play with your hosting setup. To be honest I’m not sure how much more we’ll be able to do given that this is the first report I’ve ever seen of such an issue, and it sounds like something other than our plugin is causing the problem.

We’d be totally able to pass along the names of freelance developers if you need someone to spend time looking at identifying the conflict/jumping under the hood to make everything play nicely. And we’re able to offer you a refund here in case you would rather not use the plugin at all (it looks like you have a couple of your past fall-back options still ready as needed). But I hope you can understand where we’re coming from when I say that we can’t dig much deeper on this issue.

[Rob]

Hey Mastafu: what Julie pointed to above is probably the closest we’ve got to offer on this. Unless I’m misunderstood, doesn’t the thread shared show you how to accomplish exactly what you’re going for here?

[Rob]

Hi Kevin. Thanks for the follow-up here. I saw your last note, and since I know you’ve been a fairly longterm user who has been active on the forum here I wanted to reach out and thank you for it, as well as to provide some context (and indeed, possibly clarify a few misconceptions that I perceived in reading your comments).

It’s admittedly disappointing to hear you find our QA process lacking; I will say that we spend a huge amount of time per release testing these issues. The biggest point I’ll stress is that 3.0 was an absolute, complete, total overhaul of the plugin. It was practically rebuilt from scratch and as a result, there were inevitably going to be bugs that were missed in QA. I can say with certainty that I’ve never encountered a plugin shop who released a major, new product that was entirely bug free…it just isn’t the reality. With this plugin, once we got to a point where we were able to say, “This is a solid, stable plugin” – and knew the community would generally be in agreement – we released it. We did so knowing that while there would surely be a few bugs reported to us by community members, the major/primary/widespread issues had been addressed and those that did arise post-launch could be patched in a timely fashion. To this end, we have the monthly maintenance releases that you’re likely aware of. This monthly cycle allows us to ensure no bugs sit in the system more than a few weeks at a time.

That said, we can absolutely do better QA-wise. We are fine tuning our systems with each release, and now that the 3.2 build is about to come out (which addresses pretty much all the lingering major bugs in the system), we can look at shifting over to new feature development. As part of that we are also able to look at refining how we do QA / what unit tests we have in place / and how we can better test for fringe cases. While I will stress that this is a gradual process and not something that happens overnight, I can say with certainty that our ultimate goal is something that catches as many different use cases (even those we might not have considered ourselves or had reported from the community) as possible. This benefits us just as much as it benefits end users such as yourself.

I will say that I take issue with, and honestly find kind of inappropriate, the comment that “Tri.be is more enthusiastic about spending dev time working on something new, rather than perfecting what you are already shipping, which clearly still needs some work.” There are a number of factors at play behind the scenes (budgets, resources, etc) that I don’t think you’ve considered here; but suffice to say that the team working on the other ticketing add-ons is an entirely separate crew than those working on the core/PRO products. Development on core/PRO does not stop, cease or change no matter how many add-ons we’re working on…future development on additional plugins has absolutely zero bearing on how we’re proceeding with either. These plugins remain on a monthly cycle; and each monthly cycle will be focused on a mix of stability + new features.

It’s interesting to hear your comments on the cost. Out of curiosity, what do you consider the baseline for an “expensive” plugin? I notice you made a comment that you’d expect the plugin to be more stable given its cost. We generally look at it from the other end of the spectrum – that users are paying $65 and getting access to literally hundreds of thousands of dollars in development work, to say nothing of QA/support – and so I’d be interested in hearing more on where you’re coming from and how we could better set your expectations here.

Anyway: all that to say, we really appreciate your support and – even more than that – your feedback. I’ll be the first to acknowledge that we don’t consider this plugin a 100% finished product….like anything, it is a work in progress that we are continually refining from month to month. We’re confident that it’s a stable product that will continue to get more stable over time. And you should know that, as the flagship product of our events suite, it’s ultimately our main priority – because without it we won’t have customers. Don’t let the addition of other add-ons distract from the fact that this is our baby and we’re proud to keep it moving forward from month to month.

If you have other thoughts here that you’d prefer to take offline, definitely feel free to shoot me an email (rob @ tri.be) and we can continue the discussion. Thanks again for helping us get better as a team.

[Rob]

Paul: thanks for the followup. I understand that you want a copy of the ticket emailed to admins as well as the users, and can appreciate your reasoning behind it. But I’m not sure how much clearer I can be in saying that this is unfortunately not something we’re going to be able to provide. If we had unlimited time and resources to write users a snippet or build out the appropriate templates every time a situation like this arose, we absolutely would. But in reality we have to balance the needs of all our users here on the forum and need to prioritize bugs and other integration issues, rather than building functionality. I can see how you view this as a shortcoming of the plugin but I absolutely take issue with the claim that it’s an obvious fault (you’re indeed the first person I’ve seen requesting it). Especially since the WooCommerce plugin does appear to allow order notifications (though not ticket notifications) to be emailed to site admins, and which should be workable for tracking ticket orders.

We do plan on enhancing this product with new features in the future and if there’s enough interest/demand in this (as per our UserVoice) we will definitely make it a reality. But right now it just isn’t possible by default. That said, a good developer could almost surely accomplish something like this for you. And if you were willing to dig into the code, our docs (http://docs.tri.be) are here to help. The support team here is always able to try their best to point you in the direction as well.

Perhaps an add-on like this (http://docs.woothemes.com/document/advanced-notifications/) or something similar would suit your needs. But as I mentioned here we are going to be unable to do much beyond that here and I really appreciate you understanding where we’re coming from on this. If you have other questions, comments or thoughts please don’t hesitate to email me directly (rob @ tri.be). But I am going to close this thread for now.

[Rob]

Mike, I welcome any further thoughts / concerns you might have – but I suggest we take this offline. If you’d like to continue the discussion please don’t hesitate to shoot me an email directly, rob (@) tri.be. Thanks again.

[Rob]

Hey guys – thanks for this. Mike: you make a really great, passionate case for this and I can’t say how much we appreciated it. I shared it with the team and we discussed this a lot today, and the ultimate takeaway should be this: we are going to do this, and it’s a huge priority for us. While we generally don’t comment as to specific functionality and where it is on the roadmap until it’s done and ready for release, I want to be 100% transparent here.

First: I see some references earlier in this thread to discussions about adding this functionality “last year”, and that as a result of how much time has passed, it should really be included by now. The unfortunate reality here though is that when we first had those discussions, we also expected the core/PRO 3.0 plugins to be called 2.1, and we planned on having them out by October 2012. The scope grew, the plugin became something bigger than what we planned, and we ended up not getting it out the door until substantially later than that. The months since have been spent almost exclusively on stabilizing the core plugins + addons, rather than feature enhancements. Our monthly maintenance build for November seems to be the first where we’re feeling confident enough that we’ll be able to shift back to feature stuff in December. But I want to stress that this is not just a matter of WooCommerce Tickets – the whole plugin ecosystem needs to be considered.

To that same end, we’ve had a couple additional ticket plugins – EDD Tickets and WPEC Tickets – in the queue for a while now, and have made a conscious decision to avoid enhancements to the tickets framework (which runs both those and WooCommerce Tickets) until those are both out the door. As both are looking to ship within the next month or so this again lines up with the feature-minded timetable I mentioned above.

One of our main struggles with this plugin is balancing what it was intended as (a simple, lightweight, straightforward ticketing tool) and what people seem to largely use it as (a broader event management system). While we are finding that balance, it is something that’s taken time. But I am 100% serious when I say we all want to do attendee names as you’ve noted – and in our ticket system, it’s literally our only P1 feature for WooCommerce Tickets. While available resources and the development cycle have kept us off it so far this year, we feel your pain and will prioritize this when we can. I realize that’s not as ambitious or specific a timetable as folks might have hoped for and I apologize on that front.

Nicholas: I’m sorry to hear you’ve moved over to another solution, but wish you the best of luck with Event Espresso and am glad to hear you found a feature set that better meets your needs.

[Rob]

Hey Paul. Rob from Modern Tribe here; I head up the support team here and Kelly passed your note my way. I apologize for your poor experience so far – it does sound like we falsely set your expectations as to what to expect from this plugin early on, and we failed you majorly on that front. As Kelly noted in her last message if there’s anything you could point us to that we can change – product pages, primers, whatever – so others don’t face your same experience down the road, we sure would appreciate it.

Paul, unless I’m misunderstanding a core element of this ticket, what you’re noting is an issue with WooCommerce. Once you’ve reached a stage where you’re manipulating/changing order statuses on the backend of your site, you’re no longer working with our plugin…you’re working with WooCommerce and the behaviors there are based entirely on their codebase. Our plugin is not meant to be an event management tool; it’s exists to add a simple ticketing feature by tacking onto WooCommerce’s capabilities.

A few of the other complaints you raise – perceived missing functionality, the lack of shortcodes – are disappointing, since we try to be pretty clear about what the plugins do / do not accomplish upfront. Likewise it’s a shame to see you taking shots at totally separate plugins and the comprehension of the support team in one fell swoop. At the end of the day we’re just a group of people who love doing cool things with WordPress and it should be apparent by the archive of past threads that we work every day to make people happy.

I sincerely wish you the best of luck in this endeavor, and we’re absolutely willing to help do what’s reasonable within the confines of our support system. But we will not be able to provide customization work or build custom integrations for you. I really want to get this relationship back on track and would be happy to discuss this further offline if you email me directly (rob @ tri.be); but if we’re unable to come to an understanding as to what support does/doesn’t entail, and if we cannot establish a base level of respect on both sides, I think it might make sense for us to refund your money and direct you to a competitor who can better meet your needs.

[Rob]

Hey Nathan. Thanks for the follow-up here and for posting this note. While we obviously failed you here on multiple fronts, I really appreciate you taking the time to write this out and explain the perceived shortcomings. These are things that will help us improve over time and will ensure others don’t face your same problem down the road.

Let me respond to a few of your specific items from the numbered list:

1. The search is indeed not as optimal as it could be. While we are actively working to get a new search module in place, since it’s as much a pain point for us as it is for the rest of the community. While I don’t have a specific timeline for that I expect it to be over the next few months. In the interim, we hope that the ease of accessing/reviewing forum content (via the search and other methods) is something folks will check out before buying the plugin, to make sure our support system is a good fit.
2. While I can absolutely understand the concern regarding non-disclosure agreements, please try and see things from our perspective here as well: without a link to the site where we can see problems in action, it’s almost impossible for us to provide meaningful support. The private message functionality should serve your needs here – but as you noted, you need to get passed the first post (ie send a reply instead of a new thread) in order to use that. Please let me know if it’s not functioning properly for you, though, and I can troubleshoot that.
3. While we definitely encourage folks who want to stay on top of their threads to make sure they enable follow-up emails, you can also – at any time – find the threads you’re participating in by clicking your name here on the forums. All yours for example are right here: https://theeventscalendar.com/support/forums/users/blitz/.
4. This is a really good point. While we are working on a way to specify specifically which of a user’s given licenses/linked sites their support requests relate to, so that you can accomplish exactly what you’ve requested here, at present unfortunately the only option is to manually select or submit the URL.
5. I think my explanation in #3 addressed this already; basically, you already do have access to what you’re requesting here.

As for the refund approach, let me provide my thoughts there (as that was a conscious decision): we take pride in and stand by the support we provide….we personally help hundreds of customers per day. We do this because we love it. We do this because we want a sustainable way to share our good work. As can be seen by browsing through the pages of archived threads here, the vast majority of our customers come away either with a resolution to their problem (assuming what they’re reporting is a bug or code failing on our end) or an overview of where they should go for next steps (if they need to hire a developer or find outside help).

But there are unfortunately limits to how deep we can go. In a world where time and resources abounded? Absolutely – we’d build a perfect support system and would help every user with every type of request imaginable. But the unfortunate reality is that this just isn’t possible. When you use our code, you are getting literally hundreds of thousands of dollars of development for $65. You have all the pieces to a website puzzle and all you need is someone to connect them. But that $65 doesn’t buy you a developer, it buys you user support. And based on looking at your past threads it seems the team has done their best to help you out. That said, when it becomes apparent that we’ve falsely set someone’s expectations as to how much support we can provide, or they want more than we’re actively able to offer, it usually makes sense to part ways rather than continue to create stress on both sides.

All that to say: it does sound like your needs are outside the scope of what we can provide support for. While I understand that you want a “better system of support,” the unfortunate reality is that this system – which certainly does have its limitations, but has also worked for literally thousands of other users before you without issue – is what we’re stuck with for the time being. Since it sounds like that’s a significant problem for you I think it might make sense to come to a decision here: either we try and get this relationship back on track by mutually accepting the limitations of this support system, or I must insist we refund your money and ask you take your business elsewhere. While I’d hate to have to resort to #2 I also hope you’ll understand where I’m coming from when I say that in order for support to function smoothly, we really need everyone to understand and respect our system.

Ultimately the choice is yours. Please email me directly (rob (@) tri.be) with your thoughts or if you’d like to continue this discussion offline, and we can take it from there. Apologies once more for failing to properly set your expectations.

[Rob]

Hey J-P. Thanks for the follow-up here. We do indeed still have the notes from our original exchange with you on this in an open ticket. We definitely appreciate the work you’ve done on it so far and we do want to incorporate something that accomplishes what you’ve mentioned and set the groundwork for.

That said, our development cycle is a monthly one. And since we just launched a major overhaul (3.0) of all plugins back at the start of the summer, our monthly releases since then have been focused almost entirely on optimizing the existing codebase and stabilizing bugs/improving our documentation. Once we see how well the current release (shipping in early November) does in the wild we’ll be able to best determine where resources for the next release go. And if things are looking good enough that we can start shifting back to features at that time you should rest assured knowing that this is something we’ll seriously exploring based on how much demand we’ve seen thus far.

Thanks again for your patience/understanding here so far, and do let me know if you have other questions or if I can clarify this at all.

[Rob]

Hi Nicholas. I head up the support team here, and Kelly passed your note along my way. I wanted to follow-up with you to provide you an update here – it sounds like the answer we gave isn’t to your liking, so I figured I’d provide some context.

Ultimately, what’s being requested here is additional functionality – it’s a feature that will take the plugin in a different direction than it’s headed now. Currently this plugin serves one simple purpose: allowing you to tap into WooCommerce to add tickets to your events. It was never meant to be a full-on event management plugin, and while we do see the value in adding attendee specific names and indeed have it on the roadmap, that change is part of a broader overhaul to the plugin. It unfortunately will not occur overnight. We have some more bugs to iron out and stability issues we want to get sorted before we continue work on additional features. But we know this is something a lot of people want and we’d be foolish not to ultimately look on either supporting user solutions like J-Ps, or integrating our own.

If folks need a solution in the interim, they’re unfortunately probably going to want to either hire a developer to build something, or find another plugin that better meets their needs from a functionality perspective. Sorry that I couldn’t offer you a more immediate resolution here but please know your feedback is being heard. If I can answer any other questions or provide any other insights here please let me know. Otherwise thanks for your patience and understanding.

[Rob]

Not a problem at all! Thanks for the update Jonathan. Since this isn’t as high traffic a forum as PRO there will be no problem leaving this open. Just let us know when you’ve had a chance to give it a shot and we’ll follow-up as needed from there. Thanks!

[Rob]

Any thoughts here Jonathan? Just wanted to check in to make sure you’d seen my reply here. Please let me know if we can get you anything else on this front. Thanks!

[Author]

Posts