Causing 404s with Avada page builder

  • We’ve been trying, for over a month, to get Redis caching to work, but we keep running into the same type of issue. Initially it would, somewhat randomly, start causing 404 errors on all our CSS files, breaking the entire site. So I changed the Avada options to store CSS in the DB. That fixed that issue, but now we sometimes see one of the .JS files for our theme throw a 404, and that prevents images from loading on the site. We’ve confirmed that all these issues are tied to Redis caching.

    In all cases the solution has been to hit the “Purge Cache” button. Not the Settings > Redis > Flush Cache button, as that one does not address the problem, but the “Purge Cache” button that, for some reason, only seems to appear in the admin bar and nowhere else. Flushing the Object Cache does not address the 404s.

    We’ve run out of settings in Avada to test for this, and Redis has almost no settings of its own. Is there anything else we can try, or should we start looking for other caching solutions?

Viewing 5 replies - 1 through 5 (of 5 total)
  • Plugin Author Till Krüss

    (@tillkruess)

    This certainly is a bug in the Avada theme and how it stores CSS. This plugins just provides and API that WordPress core and plugins use.

    What you can try is asking their support team which cache groups they are using to store CSS and ignore them in Redis Object Cache using the WP_REDIS_IGNORED_GROUPS constant.

    Another option would be to call wp_cache_flush() every time the Avada scripts/styles change, but their support team would need to tell you which hook could be used for that.

    Let me know what they say.

    Thread Starter Exavior

    (@exavior)

    Thanks for your response!

    I’ll reach out to them and see what I hear. Also, it’s not just a CSS issue, as since we switched CSS to be stored in the DB (to address this issue) we have a JS file that now randomly 404s. Seems to happen when site updates are made, but not all updates, so it’s hard to identify when/how it happens.

    Either way, the temporary solution is to purge the cache, which leads to one big question I had. The “Redis Object Cache” plugin appears to have 2 levels of cache. One which is a general page cache, the other which is the object cache. The admin bar has links for “Purge Cache” and “Object Cache” management, but the settings page for the plugin (/wp-admin/options-general.php?page=redis-cache) has only a “Flush Cache” button, which seems to just flush the Object Cache, and does not fix this issue by purging the page chace. My question is why is there no “Purge Cache” option there as well? On mobile the admin tool bar does not display in normal portrait mode, so not having a readily accessible “Purge Cache” has been a bit of a hurdle.

    Plugin Author Till Krüss

    (@tillkruess)

    Redis Object Cache is only an object cache, there is no page caching whatsoever.

    What the full URL of the .js file?

    Thread Starter Exavior

    (@exavior)

    The JS file is /wp-content/uploads/fusion-scripts/cc3e432e4ddb090ffbea2b4850292edb.min.js?ver=3.11.10

    It looks like the cache, that when purged addresses the issues, is part of “Nginx Helper” which was installed by the host. (Dreamhost). I’m wondering if we should just uninstall that. The UI made it seem like it was tied to Redis.

    That plugin does have an internal setting to switch between “nginx Fastcgi cache” and “Redis cache” but the Redis option requires a hostname, port, and prefix, which we are not familiar with.

    Plugin Author Till Krüss

    (@tillkruess)

    That should be a real file on disk. Can you try to recreate the issue with the .js not loading and then comparing the URL that WordPress is trying to load, compared to what’s inside the fusion-scripts directory?

Viewing 5 replies - 1 through 5 (of 5 total)
  • You must be logged in to reply to this topic.