Forum Replies Created
-
Posts
-
Hi there taochiflow! Rob from Modern Tribe here – Brian pointed out that you’d chimed in on this thread when he and I met this morning, and it’s clear to me that you’re frustrated. That’s never a good feeling and I apologize on behalf of the whole team for your experience thus far. In looking through some of your recent history and the paper trail that follows it, I think there may just be a miscommunication here that I’d like to see if I can sort out. It’s always disappointing to see when someone is bummed about their experience, and even moreso when the perception in their eyes is that the plugin “does not work on WordPress properly.” Since this does sound like something specific to your installation – not a core problem with the plugin itself – I think working through it together should get everyone on the same page and hopefully let us better convey the scope of this problem.
In reviewing some of the threads where you’ve elaborated on this problem, I noticed you logged a very similar issue a few weeks back: https://theeventscalendar.com/support/forums/topic/recurring-event-not-showing/. By following that thread to its conclusion – though I’m not sure if you ever saw Geoff’s follow-ups, since we never heard back from you in the thread? – I notice that another user chimed in and confirmed the same problem was a WPML conflict. I would bet that’s what is causing the same problem you’re seeing.
I notice you mentioned in that other thread that you have in fact deactivated WPML, and the issue persists. Can you confirm once more that you’ve tested this with the WPML plugin completely turned off? And that if it is indeed still persisting, that you’ve been able to deactivate all your other plugins to run a similar test?
This is where doing a secondary test site is important for our support team: it gives them a conflict-free environment to better assess the problem and definitively conclude whether there is another plugin/theme conflicting. If we get through that stage and have confirmation that the problem occurs even when no other plugins are active, then we’re definitely willing to log in on the admin side and check it out for a user. (I would have no problem giving such a directive to Geoff or Brian when the time is right). But we’ve found that process can be streamlined and can save time for everyone if users are able to meet us halfway by following the “Testing for Conflicts” instructions.
Let me know. I want to do right by you here, though it’d be easier to solve this if we had you posting in your own thread rather than in this one (where I worry we might distract from the issue xxtita originally posted and still needs help with). If the solutions I’ve proposed above don’t get you where you need to be – or you find that even in conflict testing the problem does persist – you can definitely open a new thread and we’ll prioritize checking it out for you.
Thanks in advance for your patience and support so far. If you have other feedback or want to continue this discussion offline, I’m always available via email (rob @ this domain). Thanks a ton for helping us improve.
Hey spotstudio! Thanks for the follow-up here. This is definitely a concern for us and something we’ve prioritized on our end. (Though Brook noted that we had already nailed down the scope of the forthcoming secondary maintenance release – PRO 3.8.2 – that’s a super minor build that will only include a fix for one minification-related problem). That’s basically a “hotfix” release to address a bug that can’t wait through the forthcoming release cycle.
But this is slated to be addressed as part of the 3.9 build we’re currently working on. While we generally do not commit to specific features/bug fixes in specific releases – anything can change during the development cycle, and as a result we generally take the mindset of only announcing those things when they’ve shipped – I’m happy making an exception here and being totally transparent that barring any huge disaster, this will be addressed in the forthcoming build. It’s worth noting that (as the original thread points out) this is a fairly new issue that emerged only in WooCommerce 2.2; so this is actually the first fresh release cycle in which we would have been able to patch the issue to begin with.
Hope that helps – if you have other thoughts/concerns/comments that you’d like to share, please don’t hesitate to let me know here or via email to rob (@) this domain. Otherwise we will let you know in the thread here once 3.9 ships and a fix is available to you.
Hey kiralybalazs! Rob from Modern Tribe here – just wanted to let you know that we just shipped a 3.8.2 release for Community that addresses this very issue. You should start seeing an update prompt on the backend of your site very soon.
Thanks a ton for bringing it to our attention! We QA’d it pretty heavily so I’m not expecting any issues…but if you still experience problems on update let us know and we’ll do our best to get you sorted.
Hi there seattledog! Rob from Modern Tribe here. I head up our support team and am project manager for the entire plugin suite, and was made aware of this thread a few minutes ago when Casey brought it to my attention. Since it’s clear that you’re disappointed in the level of service provided – and you raise some great points through this feedback relaying that disappointment – I wanted to jump in. You are a customer who has taken a leap of faith in us by buying our products…a failure to meet your expectations is a definite failure indeed, and I want to say right off the bat that I apologize on behalf of the whole team for your poor experience. We can (and will) do better.
Also, before going much further, I should note: this point you brought up got us talking about how we could best handle these types of Genesis-specific issues going forward. As a direct result of that conversation, we decided that our colleague Brian – who you’ll see has now taken over this thread to address any follow-up questions you might have – will be our go-to guy for all Genesis-related threads going forward. (Previously we were all dividing the load fairly evenly among the team). I realize this doesn’t make your experience so far any smoother, but know that it was your concern and the subsequent discussions which should prevent any other Genesis users in the future from sharing your disappointment.
I see Brian offered up some solutions/guidance already that may help ensure things are easier to address if the situation arises again. Was this the same resolution you ended up with? If any additional questions have arisen, definitely note them here and Brian will do his best to get you sorted.
From a higher level: you touched on some great points here. Theme framework support can definitely be a challenge to provide at times. When it comes to Genesis specifically, step-by-step documentation is a solid idea. For a while we even had a tutorial on how to best integrate with Genesis and what steps would be required, but it was only applicable to the 2.0 codebase; based on your comments I’m wondering if it isn’t time to get that updated to comply with the 3.x release. Similarly, your point on the lack of a shortcode is a 100% valid one – that’s unquestionably one of the most requested features we have. In the past it hasn’t been possible, but with some recent changes to the codebase and some further tweaks we’ve got planned, it looks like it’s finally something we’re moving on. I can’t say much about the specifics since we’re still working out some of the logistics…but I can say with a fair degree of certainty that true shortcode support is coming soon. Even more immediately, the forthcoming 3.9 release will include porting the shortcode functionality from our experimental Event Rocket add-on (https://wordpress.org/plugins/event-rocket/) into the core The Events Calendar. The broader shortcode support is likely to roll out in subsequent releases. I’m optimistic that what we end up with will be to your liking 🙂
In general, quite often with one of the many “major” theme frameworks, users are (naturally and rightfully) expecting a higher degree of compatibility. But it also is often these bigger theme frameworks that tend to deviate from certain WP development norms. In the case of Genesis specifically: it is unquestionably a solid framework. But I think it could fairly be described as “atypical” in certain respects. It doesn’t for instance appear to have a header.php or footer.php template, and looks to build everything up using hooks rather than the classic template driven approach of most themes we find ourselves supporting. This means that for us on a support level, we can’t as easily suggest users go into index.php or page.php, open it up, find get_sidebar() and do something with it. (Because in Genesis, index.php usually does exist but consists of just one function call – so the structure is very different). As that is the sort of approach that would be viable with probably 90% of themes we support, it by extension becomes the standard against which we measure. (More on the template structure, from the WP codex, can be found here in case you were interested: http://codex.wordpress.org/Theme_Development#Template_File_Checklist). A framework that does things differently like this isn’t doing anything “wrong”…but it does unfortunately make us less able to spend what would inevitably be a longer amount of time researching that specific theme and a workaround for conflicts it may present.
To be clear: we try and accommodate these types of requests best we can, particularly when a solution can be identified in a 15-20 minute window. (Going forward, by simply having a “resident Genesis expert” to take on these threads, I suspect we’ll be able to help a LOT more Genesis-centric requests in that 15-20 minute window). But we also use WordPress’ default themes – those the core WP team uses as their standard – as a baseline for our development efforts. In most cases we’ve found that if the latest core WP theme and a custom theme interact with the plugin differently, there’s a good chance that the theme developer is doing something different that we’ve not accounted for. There are a number of reasons for why they would. But when that arises and it’s not a quick solution to workaround on our end, we generally view that as the responsibility of the theme dev and ask customers bring such requests to them. Conversely if a theme developers came back after looking at an issue and told us, “this is because The Events Calendar is doing X, Y and Z in the plugin codebase and it is at odds with what we consider to be coding best practices for these reasons”, we will get to work at fixing that.
All that to say: we clearly failed you here, both in terms of properly setting expectations and in terms of delivering the level of service you would expect. Please do let me know if you find – for any future Genesis issues you post – that Brian’s assistance is still not getting you to where you want to be. While we obviously won’t build customers’ sites for them, I think we can go a bit further than we did here and you have my word that we’ll do so going forward. If at any point you find to the contrary, I can always be reached directly via email at rob (@) this domain.
Hi Cynthia! Rob from Modern Tribe here…I head up the support team and believe you and I have even exchanged notes over your long stint as a customer with us. I wanted to chime in here because Brian brought this thread to my attention today and it’s clear to me that you’re frustrated with the plugin + our support process. We never want to leave a customer feeling this way – especially someone who has shown continued faith in our product over the years.
I’m sorry on behalf of the whole team that we failed to both deliver the level of service you’d expect and for not properly setting expectations from the offset regarding what we can and cannot support. I’d love to hear your thoughts on how we could get better. Do you think if we had been clearer regarding the distinction of what is supported vs what isn’t at https://theeventscalendar.com/support/forums/, it would have spared you this disappointment? Similarly: we added a TERMS page since you first became a customer (and which all new users need to agree to before buying) that tries to clearly delineate what we define as support vs customization. That’s available here: https://theeventscalendar.com/terms/. I’d be interested in hearing if you were aware of that and if so, whether you think it lacks the detail needed to properly get the point across.
Regarding the matter at hand here: I’ll note right off the bat that since it’s clear you’re disappointed and such a longtime customer to boot, I did have Brian go back and put together a snippet here that will get you pretty close to where you want to be here. But even so, it’s going to require a bit of work on your part to drive to completion. Generally this is the way we try to handle such complex or customization-oriented issues: we’ll do our best to get you what you need in a 15-20 minute period. But we won’t do all the work ourselves, since that both tends to be more time-consuming and requires involvement from more of the dev team. We try to walk the line between being as helpful as possible and providing a reasonable level of support for a $65 plugin. We have definitely had requests to provide a more robust, deeper level of support and have looked into that. But logistically it just wouldn’t be possible without charging a substantially higher amount for this plugin to cover both existing design/dev/project management efforts and the newly-heightened support costs such a move would require. Not to say it’s out of the question, but realistically it isn’t something we’ve got on our roadmap at this time.
All that to say: I’m sorry we let you down here, and am optimistic that the snippet Brian provided will get you where you need to be to drive things to completion yourself. I also want to thank you for this feedback in the first place; if you still have faith in the plugin when it comes time for your next renewal, I’d be more than willing to give you a free renewal as a THANK YOU for your continued support over the years. You should also feel free to shoot me an email (rob @ this domain) at any time if you’d like to continue this discussion offline.
Hey carnfield! Rob from Modern Tribe here – I head up the support team, and Josh brought this thread to my attention when I returned from vacation this morning. Naturally I wanted to prioritize a follow-up since it’s clear you’re frustrated.
You make a few great points here, and we really appreciate you taking the time to provide this feedback. I know what it’s like to use a plugin and find a limitation that diminishes its overall value – it sucks, and is made even worse when it’s a plugin you paid money for. It’s clear we failed to properly set your expectations here from the offset…as Josh noted, the lack of recurrence support across the entire tickets framework is something we try to be pretty transparent about on the product pages. (We actually even attempted to call those out more than the rest of the text by making it bold – to clearly reiterate that we don’t have recurrence support, but that it’s on the roadmap). However it sounds like the bold treatment still wasn’t enough to make this readily apparent before you purchased, and as a result left you unable to make a fully informed decision. I apologize on behalf of the whole team for that and welcome any ideas you’ve got on how we could have made that information more prominent on the product page.
As Josh noted, this is actually something that we’re working on currently – the development work is literally going on as I type this 🙂 While I don’t want to commit to any specific release, you should know that we do see the value in this and realize that it’s a hugely requested feature among the community. If we weren’t to act on it we’d be letting our customers down and failing to stay competitive. Once the work is done and passed QA – so we know it’s solid code that we can stand behind that our users will be stoked about – we’ll ship it. While certain users may claim to have found a way to “hack the code” and make this work, it is worth reiterating that it’s not an easy tweak…definitely not something doable within just 2 hours. The recurrence code runs pretty deep throughout the PRO codebase and there are a lot of factors that have to be considered. Rather than implement a “hacky” solution just to get something out the door, we prefer to do it right – even if that means delaying the finished product a bit. I’m optimistic that if you stick around (which we hope you do!) that you’ll find it to your liking.
I’d also like to clarify: that comment about our updated recurrence structure that you mention, is actually accurate. We did launch a refactor of the recurrence framework a couple releases back and have more work on that front coming over the next month. This refactored recurrence architecture was needed as a first-step before we could get started on recurrence support for tickets…but now that it’s done, the work I mentioned above to bring this into the tickets framework is moving along nicely.
I hope that helps! It sounds like there may be some odd billing issues going on as well, which is definitely concerning. I want to help you out there but in the interest of security/privacy, I think addressing that should be done via email instead of here on the forums. If you email pro (@) tri.be we will refund the duplicate purchases for you so you’re not being tripled charged. And while it’d suck to lose you as a customer, know that if you want your original purchase refunded so you can use a plugin that better your meets your needs, that offer stands no questions asked. I want to do right by you…even if it means refunding you your $ and sending you into the arms of a competitor.
Thanks again for your feedback and helping us get better. If you have other ideas or concerns that you’d like to share, you can always email me personally: rob (@) tri.be.
Hey Brandon! Rob from Modern Tribe here. I head up the support team, and Josh brought this thread to my attention the other day. After discussing with the group on our weekly meeting today to get a sense of how often other users express these same sentiments, I wanted to reach out to both thank you for taking the time to write out this concern (extremely politely, at that) and to shed some more light on our process.
I can absolutely see how it’d feel like you were snubbed when we closed a thread before actually providing a fix. While there is a reason for doing this that I’ll get to momentarily, it’s clear that we failed you by not communicating our process more clearly from the offset. To that end I’ve added a new bullet to the main forum overview at https://theeventscalendar.com/support/forums to cover this point specifically, so that hopefully we can spare others your disappointment down the road. I’d love to hear if you have other ideas on how we could have better set the expectations of how we process support requests and new bug/feature tickets, if you have any.
To keep the forums moving as efficiently as possible, we close threads out once they’ve “run their course” – regardless of whether that means a fix was actually implemented. We’ve found that leaving threads open once they’ve largely been addressed just opens the door for thread hijackers – people who come pick up an otherwise dormant thread to report an issue that may or may not be the same problem – and other situations that generally lead to chaos and disorder. To streamline things our process is generally as follows:
- A user opens a thread. We’ll review it, and try to help them find a solution/workaround.
- If what they’re reporting is a bug that can’t be worked around, we’ll log it in our central ticketing system with a link to the thread in which it was reported (and any other subsequent threads that emerge related to the same issue). This ensures a link between the thread and the ticket, and allows us to – when we’re gearing up for release – go back to every user who reported an issue and let them know whether or not it’s going to ship in the forthcoming release. (I notice Leah did that in your original thread here).
- Once that ticket is logged, we’ll sign-off with the user; confirm that it’s on our radar as an actionable item for a future maintenance release; and will close the thread out from there. This allows us to only have open the threads that are active and require actual immediate follow-up (versus threads that will require follow-up in the coming weeks when the patch is ultimately nearing deployment, but would be otherwise dormant between then).
Where we failed you here, beyond doing a better job of making this process clear to you before you ever even posted your first thread, was not properly giving you a final chance to acknowledge that you were OK with us closing the thread in the first place. While I’m not sure there would have been a ton more to discuss, giving you a final chance to speak your peace would have been the right thing to do.
While I don’t have any specific deadline I can promise, what I can tell you is that we are actively working to improve Filter Bar integration with all our ticketing add-ons…not just Woo, but for each of the commerce engines our ticketing platform supports. The effort to get that moving was actually already underway just about the time you created your thread, as it was a known issue and a priority for us. I’m optimistic that we’ll get the plugin where you want it to be in as timely a fashion as our release cycles allow for…and that if we don’t, you’ll be vocal about that so we can get better.
Anyway, I hope this helps shed some light on things. If it doesn’t – or if you have questions, concerns or want to continue the discussion – you can always feel free to email me directly (rob @ this domain). Thanks again for this feedback and helping us improve.
Hey om4! Rob from Modern Tribe here – I head up the Support team and wanted to get involved here after seeing your last reply, expressing obvious frustration with our troubleshooting process. We appreciate this feedback and you make some great points here…while I’m going to let Josh continue to address the core issue of your thread here, I figured I’d offer up some context on why we have people follow these steps and the value we’ve found it adds. I also should clarify right off the bat that we aren’t suggesting we would not troubleshoot on your staging environment. But we do ask folks to meet us halfway before we do.
We usually have people run through the testing for conflicts procedure when we cannot recreate a problem they’re reporting – if that’s happening, it naturally means that there’s something different about their setup than our own. We do all our testing on a totally stripped down, Twenty Fourteen environment with zero other plugins active. This is as close to a conflict-free environment as it gets. Running such a test here (and we had a few folks on the team try it) consistently yields the correct behavior with regards to recurring events. So while it may be accurate that something in our plugin’s code is causing this behavior on your site, there is something about the site where this problem is occurring – be it custom code, the theme or another plugin – that is triggering that. If it were purely in the plugin code alone we’d be seeing it on our end and getting a higher number of these reports. Having someone follow the troubleshooting steps we outlined at the page Josh linked to is a quick, streamlined process of clearly answering the question – “Is this a conflict, or something else?”. We’re happy to look into it and dig deeper when it is “something else”…but I do question whether it’s reasonable to expect that depth when we haven’t yet even narrowed it down.
I’m also not sure its fair to accuse the team of “bouncing [conflicts] back at people”, when by reviewing this thread I get a clear sense Josh is doing his best to help you out. At no point has he said that he isn’t going to dive into the staging site to check this out for you – he just requested, as is our standard operating procedure, that you meet us halfway before doing so and confirm that there’s zero, nada, absolutely no chance of a conflict at play. It’s especially important when – as is the case here – we don’t even have specific steps to recreate the problem.
The conflict procedure is one that many users are willing to work with us on. That said I can understand that the steps might be more time-intensive than you may have time for, and we’ve been exploring recently adding a setting for “conflict mode” that runs through all this automatically. Hearing your feedback here makes me wonder if we shouldn’t expedite that. Out of curiosity, would you find such an approach less unpleasant: something where you just hit a button and it essentially automates this step? Would love to hear more from you as to how this troubleshooting process – independent of exploring your staging site, which Josh will follow-up on – could be made less intrusive on end users such as yourself. If you wanted to continue this conversation offline I’m always available via email (rob @ this domain).
Thanks again for your patience so far. I’m optimistic we can get you sorted here – either by identifying that this is legitimately a bug (and patching it accordingly), or seeing what’s up with your system that may be causing this funky (and as of yet un-recreatable) behavior. I welcome any other feedback you may have – it’s these types of concerns that help us improve, and at the end of the day, I want to do right by you…even if it means altering our systems to better set expectations and make the troubleshooting process easier for everyone.
Josh and Mark: I’m passing this over to Barry for driving forward, since he’s got the context and experience troubleshooting these hosting-specific issues.
Hey Paolo! Rob from Modern Tribe here…I head up our Support team, and Geoff brought this thread to my attention just now. Wanted to jump in here to see if I could clear up what we can and cannot support here on the forums – I think we may have improperly set your expectations early on in the process, for which I apologize. We try to be really transparent, both in the terms of service users agree to when purchasing and in the overview guidelines (https://theeventscalendar.com/support/forums/) here at the forum, how we define the distinction between support and customizations. It appears based on what I’m seeing in this thread that the functionality is working as it should – but that the overrides themselves are the cause for concern. As that’s custom code, it’s not something we’re going to be able to do a whole lot on.
Do you know who built your overrides in the first place? I get the sense by reviewing this thread here that it was an outside developer, since presumably you’d feel comfortable correcting them yourself if you were the original author (let me know if I’m wrong there). I think getting those custom overrides sorted out is what it’s going to take to get you on the right path here – but admittedly, since those are customizations and not out-of-the-box functionality, the best we’re going to be able to do is try to point you in the right direction.
Are there specific elements of your override that you’ve got questions about? If not, and if it remains a struggle with the documentation: is there a specific portion of our docs that we could shed some more light on? I’m happy to have Geoff continue attempting to point you in the right direction, but want to caution that this doesn’t mean we’ll be able to fix your overrides for you. That’s ultimately something you/your developer will need to work out.
Hope this helps and sorry I couldn’t offer up more. Let us know what other questions you have at this time based on the information I’ve shared above. Similarly, if you have ideas on how we could be clearer about this from the offset – to spare others your disappointment down the road – I’d welcome it. I can always be reached directly via email at rob (@) this domain.
Hi folks! Thanks for jumping in and offering up your feedback – I see some long-term customers and new faces alike in this thread. Thanks a ton for sharing your experiences. We’ve obviously let you all down here, and my apologies on behalf of the whole team for the disappointment so far. It’s clear that you guys have a set of expectations from this plugin, and that we’ve failed to deliver on those. What this plugin currently does and how it was developed to behave is not in line with what this subset of the community is requesting. Clearly that’s a due to a lack of both communication and properly setting expectations on our end. We apologize – and thank you for helping us get better.
That said, I’m a tad concerned at what I see as a questionable use of the forum here. We generally keep SUPPORT and FEATURE REQUESTS separate: support is what’s given here on the forum, to help users troubleshoot problems and smooth out integration issues. Feature requests – no matter how “must have” a feature is to a certain users or “useless” the plugin is without it – need to stick to UserVoice. We’ve got someone monitoring UV and prioritizing features based on what comes through. But the forum is not the right place to complain about missing functionality or to give the support team grief over the fact that our development cycle isn’t moving quickly enough. Some of the comments in here are downright hostile or are at least are ignoring certain realities of the plugin development cycle. There’s no reason for anyone to get angry – the stakes aren’t so high that someones life or physical well-being is at risk, nor for that matter are the support members here on the forum in any way responsible for the decision not advance this feature sooner. Remember that if you want an “out” in the form of a refund – to keep blood pressures down and hostilities to a minimum – one remains on the table so you can leave at any time. While it’d be a bummer to lose you guys as customers, I suspect there are competing plugins out there with functionality that is more in line with your expectations – or who will turn around new feature requests in a more timely fashion than our release cycle allows. I’d be happy to do some research and direct you each towards one if that’d be helpful.
As Brook noted, we’ve got a ton of users working with this plugin at the moment. While some variation on this feature is widely requested on UserVoice, we should keep perspective: the majority of customers using this plugin have made do without the functionality being requested. Remember that WooCommerce Tickets isn’t designed or pitched as a full-on event management system…it’s merely tacking onto WooCommerce and TEC to add tickets to your events. While we’re working to take it more in the direction you guys are requesting – I can say with certainty that we watch UserVoice to prioritize features accordingly, and that this is one of the handful of new features for tickets that’s actively being worked on which will ship over once they are done/pass code review/QA – I also want to stress that this isn’t exactly how the plugin was designed in the first place. To that end I caution against comments like “this should have been included from the offset” or “this plugin is useless without the functionality,” as I’m not really sure what grounds someone has to make a statement like that. We had a specific vision in mind when designing this plugin; it’s worked for most of the people who have purchased it; and for those it hasn’t, we’re taking their feedback and working with it to the extent we can. If anyone has thoughts on how we could have done this more gracefully or better communicated our progress to you guys, I welcome them. I suspect that’d help save other users your disappointment down the line.
Adam, your points are solid and I know you’ve been struggling with certain aspects of this plugin for a while. Thanks again for sticking around to offer up your perspectives. The comment you made about people walking up and giving their name is perhaps ignoring a key aspect of how this plugin is meant to operate, though: namely, where is their ticket? Every ticket goes out via email and attendees are expected to use those. Presumably they will be handing the person at the event door said ticket; that ticket will have the security ID; and that can be cross-referenced. Have you considered taking this approach? Or is there a reason why it wouldn’t work? I’d be interested in hearing more simply because this seems like one key functionality here – the tickets themselves – isn’t being used. That’s not really now the plugin is intended to work. And as a result I could definitely foresee logistical challenges.
I should reiterate: the attendee data functionality being requested is absolutely something that’s on our roadmap. We’d be fools not to listen to such a vocal subset of our userbase on something like this. It is being worked on, though it isn’t as simple/easy a fix as some users who perhaps aren’t as intimately familiar with our codebase might suggest. It’s not something I feel comfortable giving a specific timeline for, nor – unless I’m mistaken – is it something we claim in any of our pre-purchase marketing material to offer at this time. I’d appreciate a heads up or a link if there’s anything we’ve put out suggesting to the contrary. I’ll also reiterate the offer that if folks aren’t happy with the current implementation or the speed with which we release maintenance updates, the offer for a full refund stands. If I continue to get word that the team is dealing with these types of criticisms I may end up reaching out to some of you personally via email about whether it makes sense to continue this relationship at all.
All that to say: I’m sorry we let you down. Your concerns are valid and we’ve heard them. If you have additional ideas, thoughts, complaints or requests on this topic those should be brought to me via email (rob @ this domain) so we can flush them out and try and get you in a good spot in the short-term. But I’m closing this thread to prevent further discussion – there isn’t really a ton else to say here and I worry it’d just degrade further. I welcome your feedback via email and appreciate all you’ve offered up so far.
Hey Mike! We can definitely try to help you out here, but would you mind posting a new thread summarizing the scope of your problem? Since this thread is a couple years old there is a lot that has changed in the codebase and I worry we’d create extra confusion tacking your concern onto an existing thread.
Thanks in advance. We’ll hit your new thread in as timely a fashion as possible.
Hey folks: realized after seeing the last reply in here from jenunderscore that I neglected to come back in and bring this thread full circle. My apologies for that.
It does sound like there is unquestionably a demand for this — and the more I’ve reviewed it with the team and flushed out ideas these past few weeks, the more feasible I think this might be. And since we exchanged notes last we flushed out our Tickets framework plan even further…there’s no question this is going to be a part of that. While I’ll caution that it may yet slip, we currently have that slated to wrap before the year is out. At this point it’s just a matter of putting together the right team of developers to build out Tickets 2.0 (which we’re doing this week).
Thanks again for the feedback. Once this is added, we will unquestionably roll it out and promote heavily here on the forums. If you need anything else in the interim don’t hesitate to email me directly (rob @ this domain).
Hey Brandon! Thanks for the follow-up here; I head up Modern Tribe’s support team, and Brian brought your last reply to my attention. Wanted to jump in here to offer up our apologies for the inconvenience so far and to shed a bit of light on our release process.
This is indeed a bug introduced in the last release cycle. You are also absolutely correct that this issue has been reported a couple of times previously, and it’s definitely on our radar – as Brian mentioned we’ve actually got a fix in the Current Release (the build we’re working on now) that addresses this and has already passed QA, which suggests it’s pretty much ready to ship. But I do want to note that our release process is generally once every 4-8 weeks, and the bug in question here was reported during this release cycle – which means we haven’t actually shipped an updated codebase since the issue was reported. Our process is such that when a bug is reported after a certain version is released, we’ll log that and prioritize it for the subsequent build. Based on what I can tell that’s how this issue played out The fact that you were in the dark as to how often we release and what our release process entails was absolutely a communication failure on our end, and I apologize that we didn’t properly set expectations on that front. If you have any ideas on how we can do better I welcome them.
When it comes to finding a temporary solution: It’s odd to hear that the snippet there isn’t working for you – I just talked to Brian and he confirmed it gets the job done on his end. Mind elaborating a tad on the problem it yields so we can try to troubleshoot that?
Otherwise, as Brian mentioned, we are working towards a release later this month for the next round of plugins. We generally cannot get more specific than what Brian suggested above – largely because it just sets people up for disappointment. In the past we’ve promised “X build is going to ship by Y date!” and for whatever reason (bugs caught towards the end of QA, merge problems or any number of other reasons) have ended up that missing that deadline and disappointing the community. As such we’ve taken a position of not promising any specific release dates beyond our general goal of monthly/every two month maintenance releases. But you have our word that – barring any major hiccups between now and then – the next round of plugin updates will be out before September wraps. When we do such a release, part of our process involves going back to the forum threads and following up with users:
* If the bug they reported WAS fixed in that build, we confirm as much (as will be the case here)
* If the bug they reported WASN’T fixed in that build, we’ll let them know that it’s still on the radar and that we hope to deploy a patch in a subsequent release (I don’t foresee that happening with this issue since as I noted above it is already fixed)Anyway…all that to say, thanks for your patience and I’m sorry we let you down. I know what it feels like to have a client who is expressing concern about these things and if there’s anything else I can do (shy of releasing the plugin early) to help set their minds and prove that this is a priority for us, please let me know. You can reply here or feel free to reach out directly to rob (@) tri.be. Thanks a ton for your support and patience so far.
Hi folks! This is a thread that is actually unassigned/marked Resolved, so not appearing in anyone’s queues unfortunately. As a result any comments posted since Leah’s last remark has not been seen before today. I apologize for the oversight and am officially closing this thread now to prevent further discussions from taking place. If anyone has an issue they should post a new thread – and we’ll get you a reply in as timely a fashion as possible. Thanks!
