lwilldev

I have an update to share in regards to their support.

I had thought that my ticket was closed because I told them to close it, as they were not being helpful. I was pleasantly surprised afterwards that someone replied to the ticket that actually offered something helpful. After that, however, things went downhill.

The summary of this story:

• The actually helpful person explained why my code snippet to exclude a specific category from all calendars EXCEPT for a specific one was not working. They provided an alternative that seemed reasonable and generally acceptable.
• Unfortunately, the alternative caused a new issue where if you used a shortcode with a category parameter, it would a) correctly exclude the noted category from the above bullet point but b) display all other categories. For instance, let’s say my shortcode contained a category parameter for admissions. It would correctly exclude the category from the above bullet point but display events from all other categories. The expected behavior is to display only admissions events.
• I told their Support Team about the new issue I had. I set up a test environment for them to look at it. I was told it was going to be escalated to their dev team.
• A few days later, I received an email from a different person. This person took many of my words from previous ticket communications out of context in an attempt to blame me for the problem and dismiss this bug.

Due to that last communication, I knew that a) the person who told me it was being escalated clearly lied to me and b) the job of this next person was to make up any excuse to close the ticket. I knew this was not going to get a proper investigation and I needed to do it myself.

I did determine that it was a bug where if you a) add a value to $repository_args[‘category_not_in’] in the tribe_events_views_v2_view_repository_args filter and b) add a shortcode with a category parameter, the tax operand is OR when it should be AND. I changed a line of code in class Tribe\Events\Pro\Views\V2\Shortcodes function args_to_repository to fix this.

I am glad I did not attempt their first suboptimal fix (to add custom code to work around the bug). Now that I know what the problem was, that would have not worked and been a waste of time.

This company should rename their “Premium Support” to “Lousy Support.”

Moral of the story:

• Don’t waste your time with their Lousy Support.
• If you are a non-technical person, you better hire a good developer to support this plugin for you. Because this company’s premium support will not do it.
• If you are a developer, ensure that you manage this plugin with Composer so that it will notify you of any conflicts with future updates.