Class name refactor implications for add-on authors

Howdy, add-on devs! Our 3.10 release of The Events Calendar / Events Calendar PRO just around the corner and, as usual, packs in a wide range of fixes and improvements.

In this release we also embarked on a fairly substantial program of refactoring: most notably, our classnames now follow a consistent naming scheme – making it easier than ever to read our code and understand its structure, not to mention better placing us to take advantage of neat language-level features such as autoloading.

It will also gives us a cleaner codebase on which we can continue to build awesome stuff, which is in turn something we know will benefit all the plugin and theme developers out there who wish to integrate with our platform.

We’ve worked hard to maintain backwards compatibility so far as is possible, but we also wanted to communicate these changes early to give you the best possible chance of updating your own work where necessary.

With that in mind, we’d direct you to the develop branch of The Events Calendar over on GitHub.

A good example of one of the changes is that our main class – TribeEvents – is now named Tribe__Events__Events. Don’t worry, though – you can still use the original classnames, such as TribeEvents, and it should continue to work as expected (keep in mind, however, that in debug mode you’ll see that deprecation notices are generated).

Please do take the time to test this new structure with any of your own plugin, theme or other custom code – some time spent testing now is well worth the investment! If you encounter any roadblocks or obstacles created by these changes, definitely let us know over at the forums.