- This topic has 1 reply, 2 voices, and was last updated 8 years, 9 months ago by
.
-
Posts
-
We’ve noticed some confusion lately surrounding an aspect of our support process, which we wanted to clarify so our users understand what this means and why it’s important. You’ll notice anytime you post a thread, you see two checkboxes asking whether you have:
- Deactivated other plugins to check for a plugin conflict; and
- Reverted to the default WordPress theme (with plugins other than The Events Calendar still deactivated) to check for a theme conflict.
Our baseline for testing — and what our support team uses to test any bugs you report — is the default Twenty Thirteen theme, with no plugins active beyond The Events Calendar and its add-ons. We realize that most sites are not going to be running such a stripped down environment; but as this is the baseline for any new WordPress installation, it’s as common a ground as we’ve got with our users. This deactivation route is common practice around the web for supporting WordPress plugins. This does not, however, mean that we won’t support your issue if we can’t recreate it on Twenty Thirteen with no other plugins active. We always use this deactivation route as our first step to troubleshooting…but it’s not the only step. If we can identify where the conflict lies, it’ll be easier for us to narrow down why the conflict exists in the first place and hopefully try to point you in the right direction as a result.
It’s important to set expectations, though, that The Events Calendar and its add-ons will not integrate smoothly out of the box with every single plugin/theme out there. We do our best to comply with WordPress best practices and our code strives to show that; if you or another developer identify something we’re doing that goes against industry standards, we’ll of course fix that in a subsequent build. But the sword cuts both ways: if our plugin isn’t integrating smoothly on your site, and it’s discovered that something you’ve got installed — the theme, another plugin, etc — isn’t compliant with WordPress standards, we won’t be able to do much other than refer you back to the developer behind that theme/plugin.
As any developer knows, it’s key to have a test/staging environment, independent of your live site, to troubleshoot issues when they arise. Working entirely on the live site limits your ability to do this type of testing and makes any change you implement risky. Because of this our hands are tied tied when users say “I can’t deactivate the plugin or the theme, this is a live site!”, and we probably won’t be able to help out much until deactivation can be tested.
Lastly, we unfortunately cannot support any theme on which you’ve done your own customizations. If you find a bug exists on a theme you’ve customized, please make sure it also occurs on that same theme without your customizations in place. If it does, we’ll be happy to take a look. But if it doesn’t, that means the problem is with your code and is unfortunately something you’ll have to figure out on your own.
Hopefully this helps clarify things…if it doesn’t, or if you have questions/suggestions to improve this system, please let us know. Otherwise, thanks again to everyone for their use of The Events Calendar — and your support in general — so far.
- The topic ‘Read this: an important note on plugin/theme deactivation’ is closed to new replies.