tribe_get_events() and Display of Non-future Events

Hi floatingpointmatt,

As outlined in our forum guidelines, we aren’t able to help with these kinds of customizations. But we do have some handy resources that might be helpful for you:

? Themer’s Guide – provides an overview of how to customize the plugin’s frontend appearance.
? Tutorials – useful tips and tricks for changing how the plugin looks and behaves.
? Technical Docs – provides an overview of the classes and functions in each plugin

You might also check out <href=”https://m.tri.be/k0″>Events Calendar PRO, which includes a Week View ??

Good luck, and thanks for using The Events Calendar!

~Leah

Leah, I appreciate your position; however, although you’ve viewed my post as a customization request, I view it as a documentation request.

What are valid options for tribe_get_events() $args?

I’m not feeling satisfied you’ve covered your claim: “By devs for devs, it’s ready to be the foundation for your wildest hack sessions.”

I was looking for a replacement for Time.ly, and you’ve got a compelling offering, but as a developer, I need more than just an automated dump of basic source code comments as documentation. See the WordPress Codex or PHP.net for an example of what I’m after (i.e. function name + args, with argument details and possibly examples).

I get that it’s expensive to do quality documentation, and I understand the desire to set appropriate support boundaries. I’m not asking you to hold my hand, just fill out some details about your public product offering.

Answers I would have found satisfactory include:

• What you’re doing won’t work. Consider a WP_Query loop (or our PRO product).
• $args for tribe_get_events() are detailed here (supply link)
• We’re working on updating our documentation. You can file an issue here (supply link… i.e. https://github.com/moderntribe/the-events-calendar). Bonus points if you add… I’ve filed a ticket on your behalf.

As it stands, you gave me a sales response instead of a support or technical response. I got a push to PRO — and links to your basic docs (not even anything marked for specific review), despite the fact I had already linked to your specific documentation for an API function call.

I apologize for coming off harshly, but although I appreciate Modern Tribe needing to make money, I also need to know that your product will help the company I work for make money (hence my experimentation on a site that won’t require your $250 Developer offering… or even your $65 Personal offering).

I appreciate your response, and believe you have a well constructed plugin. I’d just like to see either improved documentation, or more targeted support responses (you guys are the experts with regard to your products).

My intention at this point is to skip tribe_get_events, and rebuild things with WP_Query and get_post_meta, which may not be as future-proof as I’d like, but should get the job done.

Hey there floatingpointmatt, thanks for this follow-up here. My name’s Rob and I head up the Community team at Modern Tribe. Leah noticed your last reply when doing her forum rounds today – we generally only do one pass a week here at dot-org – and I wanted to offer up some comments of my own. You make some great points here and provide some fantastic feedback…on top of that, I really appreciate you doing so in a professional/restrained demeanor while clearly conveying how you feel we feel short. It’s tough trying to engage with people who are providing critical feedback in a rude, derogatory or otherwise unpleasant capacity…this one was a breath of fresh air.

Your criticisms of our documentation are spot on, and I will tell you in confidence that I agree with you 100%. Our current docs suck and are neither user friendly nor particularly detailed. There’s a saying that “bad documentation is a bug,” and for us, it’s one of the biggest bugs we’ve got on the radar at the moment. We’re currently overhauling our docs entirely and while release of that is still a couple months out, know that it’s coming and we’re doing it based on feedback exactly like yours. The examples you provided are wonderful sources of inspiration for us as we continue that effort. I would still dispute your challenge to our claim that the plugin is built by devs/for devs – I think an argument could be made that an experienced developer like yourself would know where to look to find out what’s going on in the code even without docs, but at the same time that’s an expensive thing to do time wise. (And I think in many ways running custom queries via tribe_get_events() is – or should/could be – a central building block for customizations.) But that’s irrelevant here…we need to do a better job there docs-wise, period, and I appreciate you calling us out on this.

While Leah is not in a position to provide technical responses – that’s not why we have here on the forum, her job is to serve as a sweeper and to weed out legitimate bugs vs customization requests – I think we should have done a better job lumping this in as a “bug” (tying into my point about bad documentation being a bug). That would have meant our more technical-minded forum colleague Brook, who reviews the possible bug threads Leah collects on her first pass, chimed in to point you in the right direction. But this one was a gray area for us since we don’t see a lot of docs-related questions here and I think we could have handled it better.

All that to say: are you sorted here, or do you still have questions we could address about the docs specifically? Sounds like based on the last comment in your prior note you’ve found a workaround, but correct me if I’ve misunderstood that. Thanks again for your time and feedback…if you have more, I’d love to hear it.

Hello Rob,

Thanks for taking time out to respond.

I appreciate your candor with regard to documentation, and look forward to seeing the improvements currently underway.

I also appreciate Leah’s position. While I have already stated my initial disappointment with the answer provided, I understand that support staff often have very specific roles. It’s not “just the way things are”, it’s crucial to running a business effectively.

(I also understand the frequency of your visits to the support forums here (i.e. weekly). It’s nice to see your involvement in the community, and though I’d always like to see dedicated support forums for a product… I’m also aware those forums often become rife with spam…)

As to sorting things out, I’m covered.

I’d still like to know what Modern Tribe feels the plugin appropriate solution is (re: idiomatically consistency); however, that would be something best dropped into your snippets folder (when/if the time comes).

Ultimately, I think your product probably performs perfectly for most users, and it goes above to offer an organized and documented solution for more involved (i.e. developer) use. I’d prefer to see a more open and active technical discussion area, so more technical questions have a clearer place to live, but I suppose it depends on the business model, available resources and your user base.

Thanks again for your assistance.

You make some fantastic points here – thanks for taking the time to respond. Your reasoning and rationale are extremely well-conveyed and I really appreciate being so professional and constructive in continuing to convey these ideas.

Sounds like you’re sorted for now, which is awesome. I checked with the team regarding your last question there and the general consensus does seem to be that tribe_get_events() is idiomatically consistent with get_posts(), but it also looks like the code as it stands wouldn’t work in a regular wordpress query. You’d likely need meta_type = DATETIME in your query and it might have yielded better results.

If you ever have additional ideas on how we could do better, I’d love to hear them…either here or via email (rob at tri.be). Thanks again for helping us get better.