Does not follow WordPress standards

I’m so glad I’m not alone. I regret ever suggesting this plugin to my client.

Ditto, seems like something major is going on with this company. Horrible support and coding.

Hi @davidwebca,

I would love to hear more from you on the issues you pointed out. I know that you are frustrated with our plugins and it seems like it gave you a lot of problems to customize.

My message here is to try to get as many details about the problems that you faced so I as one of the Lead Developers behind The Events Calendar can try to make sure these concerns are addressed where possible, or in the case that we have a solution already point you to it.

In the past two years we poured a lot of time into re-structuring our code to create what we call Updated Views, but in that process we have a lot of documentation and legacy code that we are removing and updating.

Our updated views are a much better solution for customization because it allows for files to be updated independently instead of one huge template file that gets outdated quickly and turns into a problem for third-party developers to maintain.

Please do consider my request, as my intentions here are try to figure out why you had such a bad experience with our plugins and possible improve the experience of all of our users by taking in feedback.

best Regards,

Sorry if it came across rude, but I really struggled when I thought it was about to be easy. We decided to buy this plugin thinking it would save us time, but I spent way more than I would have if I had simply created a few Custom Post Types. Only thing I’m glad I didn’t have to fight with is the month / week calendar views, but other than that I’ve struggled every step of the way.

Here are my notes, and those come from an advanced developer and programming teacher of more than 15 years of experience working with WordPress for long time, so take that as you will.

–

1. Hijacks the main WP_Query

The plugin Hijacks the main WP_Query and global post object. Depending on the moment in the execution chain, it’s sometimes impossible to get the main post and global query which prevents or complicates a lot of customizations on the theme developer part, but also adds an insane amount of uncompatibility with other plugins.

2. Uses proprietary functions to load templates

Instead of using pure “locate_template” and its accompanying functions, the plugin uses a private class wrapper (accessing “$this” in a template) and uses it’s “template” function. This was probably done because of #1, but because of that, it’s impossible pass down data to the templates, except with a custom folder structure that totally defeats the purpose of having a specific template structure to override.

The template structure you use in your plugin isn’t the same as the one that is suggested for the theme developers and the legacy for the single views that is still supported makes a mess out of the views that we need to override (my theme currently has /tribe-events/, /tribe/events-pro/, /tribe/events/ and their v2 sub-folders each).

You should not hijack the main WP_Query like you do. You’re probably doing that to let users select a base template in the admin interface and “wrap” your content with it, but it’s just bypassing 99% of the useful action hooks and filters that developers use to inject content here and there. (Ex.: hook into locate_template to use a different view render engine like roots/sage’s blade or timber twig, namely).

3. Ajax should be an option

The new way that you refresh content in v2 is cool, but since it’s reloading the whole sub-view, overriding the header bar is repetitive and clunky. Plus, when an URL is faulty in the output, it’s harder to debug if there’s no global switch to deactivate it.

4. Faulty code wrapper around caching

Because of the complexity of the caching layer you’re adding over almost everything, I haven’t been able to pin point exactly why, but it’s impossible to save the rewrite URLs in the admin without them being cached wrong – (?:events) params are added to the cached urls which prevents switching views. I have to flush the rewrite rules (your transient / cache trigger) with wp-cli to force it to flush and regenerate correctly with the events slug. Plus, it’s only set to invalidate and hooked when you save permalinks, but because of the way some hooks are registered, flushing permalinks from the admin wouldn’t work so I had to use WP CLI.

The fact that I had to search for that and dig down into the code because I didn’t find any information on why would my views and URLs not rewrite and clear properly is indicative of an over-complex solution for what seems to be a non problem. Caching probably shouldn’t be implemented by this plugin, but added by end-developers on a case-by-case basis or added as an option or an add-on plugin. There’s only one option to disable one of the cache, but I wish I could also have removed your internal rewrite cache when I encountered errors in it because of translation issues (specified below).

5. Messy usage of text domains

The plugins have multiple text domain used each which clutters WPML’s string translation dropdown menu, namely ‘tribe-events-pro’, ‘events-pro’, ‘tribe-events’, ‘events-calendar-pro’, ‘event-tickets’, ‘tribe-common’ to name a few.

6. Wrong registration of translation strings

For example, the slugs: src/Tribe/Main.php:2662 to 2667. The slugs translations should always be identified by your translation functions with a context – using _x() instead of __() – because there are 2 exactly same words “event” registered, but one of them is “lowercase event” and the other one is “slug for post type”. I had to dig in the code to find out why my default slug was “vnement” instead of “evenements”. It’s because “évènements” was entered in the French translation of that word which is okay for the first one, but not for slugs and somehow your function rips out accents instead of them being sanitized through WordPress’ default slug generation. The default WordPress slug generation creates “evenements” correctly, so you should probably rework the code to use WordPress’s internal functions down the road. TL:DR; – The plugin is effectively broken in French (maybe other languages) because your custom rewrite layer isn’t able to replace the post type query var because accents weren’t properly sanitized.

–

I hope these notes don’t feel like I’m rude or anything, but I had to make sure to pass these comments for the sake of your future buyers.

Regars.

Ohh this was amazing dude, dont apologize for actually explaining your point of view at all. There is no need, on our team we are all very used to the idea of Code Reviews and honest criticism is always welcome, specially because you backed up what you were originally saying with actual things we can talk about and for us to fix.

Allow me to explore all the topics you pointed out one by one.

I want to start saying a couple of things about the project and my experiennce. Our codebase has existed for about 12 years in some way shape or form, as you probably can imagine that means that we have a lot of legacy code that we have to respect, and most of that legacy code was created by probably one or two dozen of developers over the initial years of The Events Calendar without a lot of engineering leadership, so each developer took the code in a particular direction.

Don’t get me wrong I am incredibly grateful they created this amazing product but that was like 10 years ago, as you might imagine things change a lot in that time, specially PHP and WordPress standards for certain things.

We are pretty strict with how we deal with legacy code modifications, some times we mess up and break legacy compatibility without wanting to but we are trying to do our best to always be improving the codebase in the correct direction.

With that said and out of the door, let me address the things you mentioned.

—

1. Hijacking of the main WP_Query

Yes, that is a terrible part of our plugin that the moment I joined about 7 and a half years ago I wanted to change, but I understood that it was not possible for a multitude of reasons most of them being legacy compatibility of what we call our Views V1.

This was probably as decision made in those initial years that people didnt think was to bad, but now we look back and cannot unmarry our Legacy Views (v1) from that concept.

When we developed the updated views (v2) we created with the mindset of removing that terrible piece, but we couldn’t fully remove until we were able to completely remove the codebase from V1, which we are finally after this many years doing with version 6.0.0, I mean the removal of the V1 codebase, the removal of the hijacking will happen likely one or two version after.

2. Uses proprietary functions to load templates

There are two pieces to what you are suggesting here and one of them I couldn’t agree more with you.

The part where you are talking about the terrible way how we have to hijack the main template loading for the sake of a template setting on the administration, you are almost 100% correct there, that is present simply because of legacy compatibility reasons, but that as I explained on #1 will go away.

There is a second piece that you describe as being bad around the usage of a Class to wrap the includes, that piece I need to disagree with you. Let me explain why I think that is, and I would be more than glad to hop on a Zoom/Meet call to talk about this in depth.

WordPress templating with the locate_template is very very bad for any sort of larger scale development that requires automated testing, because of exactly the reason you pointed out as a benefit.

The way we structured that particular template class is to allow a more predictable variable inheritance using the $this->template() method which allows you to pass extra params from the parent template to it’s child, and the way it works it isolates one template from the other unless you want to pass the variables.

Again we don’t have nearly as much documentation on some of the inner working of that particular part of our codebase due to time contrainst, but our team is now finally fully staffed in a way that will allow me and other developers to spend the proper time documenting and creating the information about these pieces of our code.

That whole mess with the Single and V2 folders will eventually be removed for good once we can get rid of V1 in the codebase, so that will become a lot cleaner in the next year or so.

On the locate_template that is the plan once we can get rid of V1.

3. Ajax should be an option

Yes, we coded views V2 with the mindset of having a couple more layers namely the hability to load pieces of the view without having to refresh the whole thing.

But time constraints got in the way of us finishing that for the initial release of Views V2, but we have plans to get back to it after version 6.0.0.

On the option of not using AJAX to load and have the links work is 100% part of the codebase, there are tiny pieces missing to allow that to be the case, but again this is a business and we can polish code forever, so other things took priority.

So I global switch will be included in future versions but not for now yet.

4. Faulty code wrapper around caching

Ahh yes permalinks in WordPress and the routing system. So this one is complicated and gets harder when you add translations to the picture which is the whole reason that piece of code needs to be so complex.

There is not caching to the permalinks that is how WordPress handles permalinks because of how expensive it is to generate that massive array of regular expressions for the routes/permalinks.

So the problem isn’t a an over complex solution for something that isn’t a problem is a complex solution for something WordPress doesn’t handle well, which is the hability to reverse the process of creating a permalink.

Meaning, if you land on WordPress from the permalink side you have your internal query args properly set, but if you land on any particular with a set of query args there is no native way of figuring out the matching permalink.

Our rewrite rules API aims to solve that for us, and let me give some back story on why, on V1 we had countless problems with faulty URLs and problematic Links.

I am not saying that on V2 there arent problems with the permalinks, there are but we are slowly making that system more and more stable.

I would love to dig with you on the why your particular case was breaking so we can figure out one more edge case that we need to cover so that never happens again.

Keeping in mind that we have a LOT of customers, and on probably 95% of the cases our solution works and it’s sooo much more consistent and let me say a lot more covered by unit tests.

Again the caching is not a product of our code but more how WordPress handles rewrite rules.

5. Messy usage of text domains

Plain and simple yes, that is something we need to get better at, with the full roster of developers now we will have time to create some more automations on our Code Review process to prevent incorrect domains from being included.

They normally happen when we are moving pieces of code from one plugin to another.

The tribe-common piece is the internal shared codebase from The Events Calendar and Event Tickets, which is needed for our codebase to not be super duplicated.

But all the other duplicate domains are just wrong and we need to fix, if you have a list of the ones you are encountering, please let me know and I will be more than glad to fix all of them.

6. Wrong registration of translation strings

Legacy code… yes they need to be fixed. But that piece about accents in the Rewrite rules we will 100% fix, it’s in our roadmap and we actually have started to fix some of those problems.

—

Let me repeat and say we don’t take these as being rude in any way shape or form. All of these comments are really properly worded and I agree with most of them and have layed out plans to fix most.

Again I would love to chat more about all of these, I am always looking to improve our codebase in any way that we can.

Best Regards,