I can’t remember exactly, but it’s been years since I’ve been using this design…
In case you’re wondering, this site was built on WordPress, a version that I broke and customised. Unlike the off-the-shelf version, I adjusted some files and added some self-built plugins to make it my own.
You’d think it’s tedious, but not really. The files I customised were built on top of the original WordPress with its original 11 tables. So, when there’s a minor update, it takes probably half an hour for me to adjust before updating, and a significant update would take me an hour or two.
In the last year or so, I’ve been a little more “lazy” so to speak, so unless the updates were critical, I didn’t update the WordPress version. It was only when the major release came about that I had no choice but to update it. Some of my plugins would be affected, and the likelihood of vulnerabilities (basically getting hacked) would arise.
The problem arose…
For some reason, when I did the update, it all seemed fine. Little did I know, there was a significant conflict with my theme (which I bought from Themeforest and customised). I hadn’t realised this until a few weeks later when I wanted to update a frontend design.
Then, I realised, I couldn’t; well not completely, but I could no longer use the backend version of Visual Composer. Unfortunately, due to the extensive amount of new projects that piled up, I had to put this aside until I had a bit more time.
For a good eight weeks or so, even though I had already updated my design, I wasn’t able to refresh it on the site.
Finally, it was time to troubleshoot.
I broke the troubleshooting into phases and did it mainly during the wee hours of the day. In total, I spent roughly ten hours across the span of a week, just trying to identify the issue. Sadly, I still couldn’t find the core of the problem.
When all was lost, and I was prepared to use a new theme altogether, I deleted the old one, redownloaded a fresh set, re-coded the portion I wanted to adjust. For some reason, overall it was no different from the old copy (maybe I overlooked a typo or something), IT WORKED!
Again, it could have been a typo, or I might have opened something and forgot to close it. Who knows? I’m not about to “tally” the old and the new to find out.
In light of this, here are some steps you can take to resolve a plugin conflict (disclaimer: you can probably find this information in many other sites, I just added my insights and tips into it):
Step 1: Clear your browser cache.
Not rocket science here. Sometimes it’s the browser’s cache that’s causing the problem. How so? In some cases, after updating a plugin, codes from the outdated plugin need to be cleared before the new codes kick in.
To clear your browser cache, for PC, hold down the Shift + Ctrl + Delete button, all at once; for Mac, press Option + Command + E. Then click clear data or empty, respectively.
If the problem persists, move on to step 2.
Step 2: Consider creating a staging site (or backups).
The next steps are pretty drastic; hence it’s not the best idea to implement them on a live site. That said, if you have done a backup, you can consider risking it.
I kind of do the live updates for some of my sites that are running our new hosting service, cause it’s super convenient to rollback; usually, I set the maintenance page, so there are no new users sign up. But generally, these sites aren’t high traffic so that I can afford the loss of minimal data.
Anyway, on a staging site, whatever change you make won’t reflect on your live site, until you commit the changes.
Of course, a staging site will only make sense if you can still access your site. As such, if your hosting (like our’s) has regular backups, you can always do a manual backup on the current version, rollback to an older one. That kind of happened to me before as well, I lost a week’s worth of data, but hey, at least nothing is broken. After that, I just monitor what I’m updating to see what caused it to break, and try to resolve it from there.
At People’s Inc. 360 (PINC 360), we have a new hosting service that specialises in optimising WordPress. We provide a “one-click” from production to staging, which makes it easy to troubleshoot and identify issues that may occur. Not to mention, we have automated daily backups with up to 30 backups stored, which you can also “one-click” reinstate.
My website isn’t on the new hosting yet, but I’m starting migrations to make that happen.
Step 3: Switch to WordPress default theme.
Quite often, the theme could be the culprit. The only way you can know is by switching to another theme – one you can trust. And the most trustworthy themes are the default theme which comes with WordPress.
Mentioning earlier, for my case, the current one that led to me writing this post in the first place… the theme WAS THE CULPRIT.
Anyway, if you have access to your WordPress dashboard, then navigate to Appearance >> Themes. In the themes directory, locate the Twenty Twenty theme. If you can’t see it, check for Twenty Nineteen or Twenty Seventeen.
Activate the theme and check your website.
But if you can’t access the dashboard, you can also remove the theme from the folder public_html (usually the root folder for Cpanel) >> wp-content >> themes >> and move the theme you’re using into another folder.
If the problem clears away, apparently the problem came from the theme.
Now, you have a choice to make: replace the problematic theme or sort through your list of active plugins to find which is conflicting with the theme. If the latter is your preferred choice, proceed to step 4.
Another thing you can do is to escalate the problematic theme to its developer. To reach out to the theme developer, first, click on the theme thumbnail. You will see the URL to the theme developer. Click on it.
If at the end of the day it turns the problem was never from the theme, move on to the next step.
Step 4: Deactivate your plugins.
Pretty straightforward here, deactivating all your plugins will help you isolate the plugin causing the conflict. The best part, you can do so in bulk.
First things first, navigate to Plugins >> Installed Plugins. Then click on the Plugin checkbox. Doing this will cause all plugins to be selected. Now, to deactivate them, select Deactivate from the Bulk Action drop-down box. Then click the Apply button just beside it. Upon click, all the activated plugins will be deactivated.
In case you’re wondering, it’s not a “must deactivate all at once” kind of situation here. If you would like to exempt a plugin from being deactivated, deselect it by clicking the checkbox next to it. This, however, isn’t recommended because the plugin you deselect could end up being the problematic one.
After deactivating plugins, the issue should go away. I mean nothing is running other than the core WordPress.
The last step is to identify the exact plugin causing the conflict.
Step 5: Reactivate the plugins.
To find the erring plugin(s), we have to activate one plugin at a time. (Take note, this is on the premise that it isn’t the theme that’s causing it.)
After each activation, reload the site to see if the problem occurs. The plugin that was activated before it goes “kuku” is the culprit.
If it is a plugin to a plugin conflict, there has to be another plugin causing the issue. If the plugin you already found is too important to you, you may want to find the plugin conflicting with it. To do that, leave this plugin enabled, and disable the rest.
Then, start activating plugins again. The moment after you’ve activated a plugin and the error occurs, you’ve identified the two plugins that are conflicting with one another.
So, how do we fix this issue? Well, you can either contact the developer or find an alternative plugin for it. Last option, but this would require coding knowledge, is to debug the plugin to see what’s causing the error; for that, it’s a bit too technical for this post.
If all else fails, start afresh. If that doesn’t help, well, you can hire my agency or me at www.pinc360.com.
I hope this helps!
P.S. I could have just gone ahead and given it to you step by step, but hey, you might not think it’s a good story, but it’s a memory for me. Thank god, I don’t have to redo my site, though it would have still looked more or less the same.Tags: automated daily backups frontend design maintenance page regular backups staging site theme developer themeforest visual composer wordpress wordpress default theme