Why You Should Avoid Avada

Please note the publish date for this post. I have not used Avada in over a year, so I cannot attest to what development has been done since then and what has been fixed. This post merely outlines my experience with Avada and serves as a good cautionary tale to theme development and selection. If you need support for your site running Avada, please go to the Theme Fusion website. My comment section is not an ideal Avada Support location.

Avada is the highest selling theme on Theme Forest, and with good reason. It’s attractive, responsive, supports retina displays and is jam packed with features. But underneath that beautiful exterior lies a dark truth. Avada is a nightmare for multisite. After a year of use, I’m trying to get as far away from Avada as possible, and if you run WordPress multisite, you should too.


About a year ago, we began doing some long overdue cleanup on UNC Chapel Hill’s open WordPress multisite network, web.unc.edu. The network was started back in 2009, and for several years there was no real oversight or enterprise level planning to the project. As such, the previous administrators would install themes and plugins anytime they came across a new one they felt like they wanted. That led to there being almost 200 themes installed, only a handful of which were responsive and/or still in active development. I decided we needed to remove support for those old, crummy themes and look at modernizing our offerings.

We began looking around at the most popular themes to see what might be a good addition. We found Avada and on the surface it looked like a great option. Immensely popular, responsive, actively maintained, retina support, lots of customization options, etc. While I was somewhat nervous on the prospect of a theme with that much functionality in it (especially the bundling of plugins), we believed it would help our users have an extensive ability to customize their sites without feeling the need to ask us to install custom themes.

Well, I should have done more research. Avada, while extremely powerful, is led by developers who seem to have no regard for the effects their decisions have on their users. That is something that is difficult to grasp from just looking at a theme, but in hindsight, the signs were there and it is my fault for not thoroughly testing and reviewing all of the code. It’s a lesson I’ve learned and I will not make that mistake again.

Here is a list of a few of the issues with Avada that I’ve encountered.

Plugin Deactivation

After deploying the theme, things were going well. The users who had begun using it were happy to have so many options. But we began getting strange reports from some users that their plugins had all been deactivated. There didn’t seem to be any particular consistency to the reports, various active themes, various active plugins. Finally one day I noticed when switching my test site over to Avada to check something else out, the few plugins I had activated had somehow become deactivated.

Knowing that Avada had bundled plugins, I suspected it had a bug that was accidentally wiping the active_plugins field in the options table. I opened up the theme and did a search for ‘active_plugins’ to see if it was being touched by anything. What I found was shocking.

This is horrible for a number of reasons:

  1. In an effort to prevent conflicts with the plugins they had packaged into the theme, they were intentionally deactivating all plugins. Why you would ever think this was a good idea, I have no clue. Why not just target the plugins you are bundling?
  2. They wrote their own SQL to manipulate the active_plugins value in the options table instead of using the available core functions such as update_option(). This shows a lack of understanding of proper WordPress development techniques. It’s even more shocking since they use get_option() 2 lines before. Who knows what other best practices they are ignoring throughout the theme.
  3. This code was just loose inside functions.php, which means it fires on every single request to the Avada theme. This meant that even just previewing the theme caused it to deactivate all of your plugins (which explains why it occurred to people who were not even using the theme).

After discovering this, I simply commented out this section in my installed version and asked them to fix it for the next release. Their response was comical:

We need to access your website to diagnose the problem. Can you please set up an accessible server for us and reproduce this issue on it? So that we can have a look.

What? They wanted access to my server in order to replicate the fact that it deactivates all your plugins? It is abundantly clear from the code I pasted above that it did it, and even worse, it was by design!

Once they discontinued the bundling of plugins within the theme, they removed this code and resolved this issue, as they no longer needed this code to avoid fatal errors if the bundled plugin was already active. But this was just the first major indicator of problems with Avada.

Timeout Issues

We also had reports of some users not being able to access their dashboards. In some instances, these were on sites with zero active plugins, but the common denominator was always Avada. I began searching through our error logs for any type of indicator. There were a number of timeout errors that were the obvious culprit of the white screens, but nothing specific about where the timeouts were occurring. Then I happened to come across a few instances of this: Call to undefined function layerslider_activation_scripts() in /wp-content/themes/Avada/functions.php on line 133

I thought that was strange, and I still haven’t really figured out why it showed up because it definitely was available (Layer Slider is packaged in the theme) and being included a couple of lines before the call on line 133. But it gave me a place to start looking.

I opened up the code for Layer Slider to begin investigating and immediately found the culprit in activations.php.

On activation, Layer Slider was going through every single site on the network and attempting to create its required tables. This is probably fine on a small network with maybe a hundred sites. But we have over 8,000. It was obviously timing out. It also means that I then had hundreds of erroneous tables in my database. They should have checked to see if the plugin was network activated, not just if it was multisite. Anyway, I commented out the multisite portion and that solved the problem.

The bigger issue for me here is that these are a theme and plugin that both advertise multisite compatibility. I guess they are, as long as it isn’t a big network. This problem still exists in the latest available version of Layer Slider as of this post (5.3.2).

PHP Errors

I had a coworker do the local testing of this theme prior to installing on our dev server and eventually production server. I assume he did not have debug on when testing because a few months after we added this theme, I was asked to build some additional layouts into a child theme of Avada (pro tip: don’t bother). When I first activated the theme it blew up my screen with dozens of PHP warnings and errors.

They were mostly minor undefined index warnings, but they are triggered repeatedly on every page request front-end and back-end until you go the Theme Options screen and click save. It speaks back to the issues with plugin deactivation. It’s lazy programming. Why are you not checking to see if the index exists? Why don’t you set some default values when the theme is activated? These warnings are still happening in the latest version of Avada (3.6.2).

The Final Straw

We’ve been sitting on an older version for a while trying to figure out how to handle the decoupling of plugins.

On web.unc.edu there are a couple of hundred sites with Avada active, many of which are using at least one of the four bundled sliders. We already had Revolution Slider available to all users on the network, so that was our promoted slider of choice. I didn’t want to install 3 other sliders for everyone, because sliders are terrible and it’s dumb to offer four plugins that do the same thing.

Most people were using Revolution Slider and Layer Slider, so my solution was to support Layer Slider for those who were currently using it, and drop Flex and Elastic from the network at the same time as we updated Avada. I wrote a script to handle the Layer Slider activation on sites that required it, so that they wouldn’t break when it was no longer bundled in Avada.

On Wednesday, I attempted the update…and all hell broke loose.

Apparently the update to version 3.6 is not your usual WordPress theme update. You know, where you just update it and everything is cool. It requires extensive work if you want to maintain the current look and presentation of your site, outlined on their documentation site*. There are 7 major outlined changes that you will have to deal with when updating. That’s bad enough for one site, nevermind hundreds.

* Edited Note: This documentation has now been updated for version 3.7 which includes even more action items that you must do in order to prevent your site from looking different.

But that alone isn’t the only issue. There isn’t really any way to know those things need to happen unless you go actively searching for it. It wasn’t posted on their blog (assuming that anyone reads it). A link to the aforementioned update instructions is not present anywhere on the Theme Forest site. There are no notes about it in the changelog. Heck, it’s not even prominently featured on their documentation site. You have to go under Installation > Important Update Info.

Why would I re-consult the documentation to run a simple WordPress theme update? Something I do over and over again every single week. Why do they not default to the previous settings, with the option to enable the new ones?

One of the tenets of WordPress core development is it’s insistence on maintaining backward compatibility. Apparently the developers of Avada are not aware of this, or are not interested. Each release seems to include changes that require action by the user to simply maintain the appearance of their site.

Upon the realization that all of my users sites now looked drastically different, and in many cases were very broken, I had to revert back to the previous version of Avada. Then I made the mistake of reverting to an unpatched version that still had the plugin deactivation problem, so I spent the next couple of hours cleaning up sites and trying to determine what plugins they had previously had active, while at the same time trying to calm down angry users who were as surprised as I was that their sites had suddenly broken.

This was it for me. After a year of use, numerous issues, and no clear update path, I decided to drop Avada as an option for our users. I’ll apply any security patches as needed, but I will not try to do any further updates.


Add a Comment

Your email address will not be published. Required fields are marked *