Recurring events all marked "this event has passed"

[Kevin]

I am having trouble with my site where recurring events that have not yet occurred are being marked as “this event has passed.” Clearly that is not the case.

You have the exact same issue on your demo site. Here is a URL: http://wpshindig.com/event/milwaukee-wordpress-wednesday-4/2013-11-06/

I see a previous report of this issue that you closed as a “theme or plugin conflict”. Clearly a bug if it is on your own demo site.

[Kelly]

Hi, Kevin. What an excellent and timely question! 🙂

We’re actually in the middle of trying to track down what’s going on with this. Thank you for pointing out that it’s happening on our site. That’s very helpful.

Would you mind sending a link where it’s happening on your site as well as your site’s System Information (from the bottom of the Help page in the Events Calendar Settings screen)? That would be very useful for us.

Thanks, again! 🙂

[Kevin]

This reply is private.

[Kelly]

Hi, Kevin. This is excellent! Thanks so much.

It looks like we were able to locate a bug where this is showing up specifically for recurring events with an initial event that had passed. Would you please confirm that’s the case with all of your events that are showing this behavior?

[Kevin]

From what I can tell this is the case. All of the recurring events whose initial event date have passed are appearing this way.

[Kelly]

Thanks for confirming, Kevin. It’s super helpful to know that.

It looks like we’ve got a solution that just passed QA for our upcoming maintenance release, so relief is on the way! 🙂 Thanks for your patience in the interim!

[Kevin]

Cool. I’m glad that your support folks are receptive and responsive. I do have to say that your development team needs to figure out a better way to QA the product before it releases. I’ve encountered quite a few nasty bugs in 3.0 and 3.1 that should never have seen the light of day if you had a reasonable set of test cases set up.

The post today about your new EDD plugin leads me to believe 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.

Sorry to sound critical, but this has been an unusually buggy plugin, escpecially givent it’s cost.

[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.

[Neill]

Hi Kevin,

Just wanted to give you an update on this one. We have a release scheduled for this week and as Kelly and Rob mentioned, this particular issue passed QA and I can confirm it is in this release.

I will close this ticket out, but please feel free to open another ticket if you find the update has not solved your issue and we’ll take it from there.

Thanks for all your feedback, info and your patience so far, all of which help us with our process.

Neill

[Neill]

Hi Kevin,

Just wanted to give you an update on this one. We have a release scheduled for this week and as Kelly and Rob mentioned, this particular issue passed QA and I can confirm it is in this release.

I will close this ticket out, but please feel free to open another ticket if you find the update has not solved your issue and we’ll take it from there.

Thanks for all your feedback, info and your patience so far, all of which help us with our process.

Neill

[Support Droid]

This topic has not been active for quite some time and will now be closed.

If you still need assistance please simply open a new topic (linking to this one if necessary)
and one of the team will be only too happy to help.

[Author]

Posts