Home › Forums › Calendar Products › Events Calendar PRO › Bug with Private Venues & Organizations
- This topic has 11 replies, 3 voices, and was last updated 12 years, 11 months ago by
Barry.
-
AuthorPosts
-
May 3, 2013 at 5:44 am #47547
rcstribe
ParticipantI noticed a serious problem with Venues and Organizations. Problem does ALSO exist in twenty twelve theme.
I normally set my posts, and in this case, my event, to Private, until I am completely finished editing and testing it. What happens, however, is that every time I save the (private) event – it greats a new copy of a private venue and a anew copy of a private organization! Of course, this creates a lot of confusion and a horrible mess.May 3, 2013 at 6:09 am #47551Barry
MemberIndeed it would and I can definitely replicate this. Bear with me while I check out a few ideas on this one.
May 3, 2013 at 6:14 am #47552Barry
MemberWould it be possible for you to workaround this in the short term by using the Draft post status instead of setting the visibility to Private?
May 3, 2013 at 7:14 am #47560rcstribe
ParticipantI suppose I could try, but my understanding is that sometime drafts are exposed…
Does this mean you (tribe) are not planning on addressing this?
I have to tell you that I am quite frustrated by what seems to be the attitude of “we’re coming out with a new version in a few months, so we are not really fixing any bugs in current version.”
I have accepted that I have to work around and/or ignore certain issues (that really should be addressed) – and there are other issues that I haven’t even reported – they are significant issues that I assume would take significant effort to address. I can’t afford to waste the time and effort on something that you are basically going to ignore.
I hope this came across as sincere input and concern, not a crazy rant…May 3, 2013 at 8:06 am #47562Barry
MemberIt doesn’t come across as a crazy rant at all, believe me when I say that we appreciate your frustration π
Also, I definitely did not mean to imply we will not address this. I’ve asked one of our developers to look into this and simply wanted to offer you a possible workaround in the short term so that you could keep going – realistically the assigned developer may not be able to leap on this issue today and it could be next week before we get an answer so I thought it was worth looking at ways to keep things ticking over in the meantime and avoiding unnecessary disruption to your routine as far as possible.
Regarding the exposure of unpublished drafts, I’m not sure in what scenario they might be exposed that would be problematic for you – but the role of a draft does seem to me to be a good fit for what you are trying to accomplish here. If it’s unpalatable for any reason then I’m afraid there aren’t too many other convenient ways of achieving this that I am aware of.
Last but not least we are not hoping issues will go away by ignoring them. We are focused on a large scale rewrite and that has had the unfortunate side effect of meaning we have delivered maintenance (“bug fix”) releases less frequently than normal – but we are doing that because we believe it is the best use of our resources and is in the best interests of the wider community of users.
May 3, 2013 at 8:43 am #47565Rob
MemberHi rcstribe. Thanks for your note here, and for sharing your concerns. I want you to know that we really take this type of feedback seriously and anytime someone is feeling uneasy or as if they’re not getting their money’s worth, it raises a serious red flag. I know how it feels to be in your position and it sucks.
Couple points here: first, I should note that while your solution isn’t a bad one, it isn’t really how WordPress was designed. The use of “Private” functionality exists to limit frontend access to posts/events/etc. It isn’t intended to serve as a backend filtering solution or as a way of saving draft posts. This issue you’ve reported, as Barry notes, is definitely a bug with our system. But I think you could save yourself a lot of hassle by just using the “Draft” format (or “Pending Review”) instead of Private, to achieve the same end. (I’m not aware of the privacy concerns you note regarding drafts being exposed.)
More importantly…it’s worth providing some insight on our development cycle, I think, and the development cycle for plugins in general. In an ideal world we would be fixing every single bug that is brought to our attention on the spot, and releasing a dot-release immediately thereafter to address it. But the reality is that this is unfortunately just not feasible when you’re on a broader development schedule and working with a fixed budget. We try to be as transparent as possible as to our process: that is, regular monthly maintenance releases where we fix all bugs and incorporate features as budget allows it.
We have deviated from that monthly release cycle these past few months. This was a calculated decision because we feel the end result – a highly modified, much better calendar solution – is something the community wants, and so if it meant sacrificing maintenance builds for a few months to make the finished product that much better, so be it. The majority of our users have been receptive to this and super stoked about it. We even actually did release a maintenance build, 2.0.11, back in January that addressed most of the critical bugs we were aware of at the time. For other things that have arisen in that time, we’ve tried our best to provide people with working solutions that can tide them over: either via code snippets here in the forum or by giving them the 3.0 code (beta) to test if the problem is resolved. That said there are limits to what level of support we can provide for a $50 plugin…which means that some of these bugs and other issues can’t really be addressed except by the devs, in the codebase, for the next release. I would love to be able to provide every single user who is stuck or facing a problem with the current release a solid code snippet or tutorial that temporarily solved their problem. But it’s sadly just not possible.
The particular issue you’ve noted here – private categories being problematic – falls into that category of bugs above. It is logged and on our docket to address for 3.0; I’m pushing to make sure that gets done for the initial 3.0 release because this is a bug and is absolutely our responsibility to address. But since it effects such a small subset of our users (yours is the first report I’ve seen of this) and there isn’t a straightforward “here are 3 steps to take for a workaround” route available, we hope you’ll understand the position we’re in when it comes to releasing new builds.
I would take issue with your claim that we’re “ignoring” issues, though. I can say with certainty that every legitimate bug that comes to light with the plugin is logged with our team and addressed in the next release, regardless of whether that’s a major release like 3.0 or a dot release like 2.0.11. If there are other issues you haven’t reported that are not limited to some aspect of your setup, then we certainly want to hear what those are so we can make sure they’re on the docket. But it’s unfortunate to see accusations like that thrown around when we make every effort to address every single bug that crosses our path, and the backlog of nearly 3000 threads in the forum archive here should attest to that.
I hope this helped shed some light on things. Please do know we feel your pain and that we are working our hardest to get the new release out. We aren’t waiting for it to be perfect (a day which never comes in any development cycle), but we also aren’t yet at the point where we have a finished product. I suspect we’re less than a month out at this time but if this timetable isn’t ambitious enough for you, let me know. I want to do right by you so if that means giving you a refund so you can purchase a solution that better meets your needs, we’ll make it happen. My email is rob /a/ tri.be and if you wanted to take me up on that offer or share any other concerns you might have, my door is always open.
May 6, 2013 at 5:44 am #47663rcstribe
ParticipantHi Bob,
Thanks for your detailed, sincere response. Let me share some more of mine with you:(1) I was hoping my post came across as sharing frustration, not a rant.
(2) I am not looking for a refund. I did not need any of the PRO features, but happily purchased a license just for support.
(3) It was probably a mistake on my part to share my frustration on that particular thread, since there is in fact a simple workaround available (your pointing out the intended use for Private vs Draft was also interesting).
(4) Let me elaborate a bit more on the source of my frustration –(i) One of my first issues was the one I posted in thread https://theeventscalendar.com/support/forums/topic/problem-with-calendar-view-and-woothemes-canvas-theme/ In the course of my researching that issue, I came across the statement
Well, since weβre not going to be doing much more with the 2.x codebase, would you guys like to try the 3.0 beta to see if this is resolved? If so, please email pro [at] tri [dot] be and reference this thread and attn. to me.
That didn’t make a great first impression or offer much hope that you would address the issue when I reported it. But I am happy to say that Barry made a real effort to pursue the issue for me and came up with a simple fix (CSS)!
(ii) Then I had a double issue of a garbage display for an Events List with no upcoming events and also for a non-existent event URL (instead of 404 error). While I consider both to be significant issues, I can actually live with the first one, sine I’ll always have an upcoming event. The second one is more significant. This issue has still not been resolved (even after I made the non-thrilled-with offer of granting admin access to the live site), and again ended with the offer of using a Beta product that you feel is not yet ready for production (and please don’t release it before it is!)
(iii) All this was going on while I was already late for the launch of this functionality. Then, once we launched and started using the system, I was taken aback by the mess of duplicate venues and organizations. When this conversation also ended with the offer of the beta of 3.0, I guess it triggered the frustration dump.
(5) A few more points:
(i) I do recognize that your willingness to share the beta is generally a good thing. I just don’t see it as the solution to all existing issues for a 5-6 month period.
(ii) I’ve had a few other issues/questions, to which I have gotten rapid and excellent responses.
(iii) I still feel that your plugin is the best out there – at least for my needs – which is why I am not only sticking with it, but also trying to engage and help you improve. Sometimes that includes criticism and maybe even venting.I thought that by writing these as bullet points, I’d be able to keep this short, but apparently not π
Jackie
May 6, 2013 at 2:41 pm #47736Rob
MemberThanks for the detailed follow-up, Jackie. This is great to see and I really appreciate you taking the time to reply. I definitely didn’t read your initial post as a rant! We’ve seen far worst on that end π It did, however, seem you were frustrated and we take those posts just as seriously as people cursing in our faces – though that thankfully happens very infrequently.
You make some great points here:
* The 3.0 beta stopgap solution is definitely not permanent, and every month that goes past it becomes increasingly problematic. Our initial plan was to have 3.0 out the door by the end of December; the fact that we’ve been pushed beyond that is due to scope creep / bugs in the code / etc. It’s worth noting we didn’t really start offering that beta on a widespread basis until it was stable enough to offer, sometime in late March/early April. But there’s no question that offering it as a solution isn’t an acceptable one. We realize the need to get 3.0 out and I’m confident we’re finally on the cusp of doing so effectively.
* We love criticism. Not because we always feel good about what it has to say, but because it makes us a better team. The only way we’re going to improve and better serve people in your position is when we’re called out or told we’re doing something wrong. If everyone was unsatisfied and didn’t do anything, we would never know there was an issue and would never get better. So I do want to thank you for this on that basis alone.It sounds like, if I’m reading your note right, the biggest issue that remains – which can’t wait for 3.0, anyway – is the one of the nonexistent URL. I talked this over with Barry and our internal dev team, and it is admittedly a bit of a struggle for us since we’re unable to recreate locally. But that said: we actually received an email from WooThemes’ head of support today, since he’s been seeing similar incompatibility issues between their themes and our plugin, and the discussions have begun on what we can do to truly integrate them. I can’t guarantee anything but we are committed to making it so on our end in whatever capacity is required…so know that this may change sooner than 3.0 if there is an update on the WooThemes side between now and then.
I realize that isn’t a perfect answer…but sadly it’s the best I can offer up at this time. We want to make sure you have a positive experience, and while the solution isn’t something we can specifically offer up in your use case, we are approaching every avenue – both within our own code and in terms of the other major players in the industry – that we can here. If you have any other questions or concerns, or if I failed to address a point you made here, please don’t hesitate to reach out directly to rob /a/ tri.be.
May 9, 2013 at 5:31 am #48000rcstribe
ParticipantRob,
I knew there was something else that frustrated me… I had another bug/issue to report, but was too frustrated to even bother posting (my bad). I’ve gone ahead and posted it at https://theeventscalendar.com/support/forums/topic/jetpack-share-buttons-do-not-appear/
May 9, 2013 at 7:13 am #48015Barry
MemberHi Jackie, I’ve replied to your new thread and we can progress that issue there.
May 10, 2013 at 12:33 am #48147rcstribe
ParticipantDiscovered another issue today – somewhat related to original bug, but has nothing to do with Private.
I have normally been creating Organizations by entered the data for a new organization in the data for an event. All good. But If I try to create a standalone organization, i.e. outside of an event, the URL of that organization never gets updated stays as auto-draft even after being published. For example: http://losangelesdogs.net/?tribe_organizer=auto-draftMay 10, 2013 at 9:59 am #48204Barry
MemberHi rcstribe – I can see that and will look into it – just for future reference though it would be massively appreciated if you could create new threads for new issues.
-
AuthorPosts
- The topic ‘Bug with Private Venues & Organizations’ is closed to new replies.
