Implode Passing glue string after array is deprecated

Hi Eric-

Thanks for reaching out, I’m sorry to hear about the fatal error. This error is a result of an older PHP syntax that is no longer valid after PHP 7.4. The bug was patched in July 2020, so it’s likely that your theme is out of date.

You can immediately get access to your sites back if you change the PHP version down to 7.3 or lower. Here are Web Hosting Hub’s instructions on how to do that from your cPanel.

Once you’re able to log back into your sites on PHP 7.3, you’ll be able to update GridOne to the most recent version, 1.25.7. If you don’t see a theme update available in your Dashboard, you can download that version directly from this link.

Once you’ve downloaded the Zip file, navigate to Appearance > Themes > Add New and click Upload, and you can perform the upgrade by uploading the zip file directly there.

Hi Eric-

Thanks for the updates, I’m glad to hear you were at least able to log in and get your themes updated.

You mentioned that you cleared your browser cache, but do you have any server-side caching that might need to be cleared? Some caching plugins, like our own W3 Total Cache, may not serve cached pages to logged-in users, which would account for the behavior you described.

If you’re using W3 Total Cache, look for the Performance menu in the top admin bar, where you’ll find an option to Purge all caches.

Hi Eric-

It looks like your site is back up again now, hopefully you’ve already solved this on your own!

You can get some more information by enabling the WordPress Debug Log, by adding the line define('WP_DEBUG_LOG', true); in your wp-config.php file.

I also noticed that W3 Total Cache has been disabled now. I’m guessing that a cached copy of the error page was being served.

It may be necessary to manually clear out your cache files. Using FTP or Web Hosting Hub’s cPanel File Manager, delete the directory /wp-content/cache and then re-activate W3 Total Cache.

Hi Eric-

Looks like we were responding at the same time. Try the step above to manually delete the /wp-content/cache directory and re-enable the plugin.

Hi Eric-

We’ve tested W3 Total Cache pretty extensively with our other BoldGrid Products, so I’d have to suspect something else might be going on.

Can you list the other active plugins on arctechstrategies? Particularly any that it shares in common with artstechpartners, but not you main business site?

Hi Eric-

Thanks for the updates and the details about your plugins.

I tested out W3TC with all of those plugins active and I couldn’t replicate the error. Two of those plugins did jump out as potential troublemakers.

First, Lazy Load Optimizer and W3TC might conflict because they both have the ability to add lazy loading. If you like that plugin, make sure that W3’s lazy loading is turned off in Performance > General Settings > User Experience. I tried it out, though, and I couldn’t get an error from using both.

Second, Admin Bar Edit Content Links jumped out because it hasn’t had an update in over 3 years, so it’s possible that it may have an error after updating to 5.6.2. You mentioned that you deactivated it, and it looks like it has pretty basic functionality, so that might be a “Red Herring” as well.

So all of that being said, I recommend a complete re-installation of W3 Total Cache. Here are the steps:

1. Deactivate and delete W3 Total Cache
2. Make a backup copy of your .htaccess file, and then delete all of W3 Total Cache’s directives. Look for the sections that begin and end with #BEGIN W3TC... and #END W3TC... and delete them all.
3. Delete the W3 Total Cache files and folders:
   • wp-content/cache directory
   • wp-content/w3tc-config directory
   • wp-content/object-cache.php file (if it exists)
   • wp-content/advanced-cache.php file (if it exists)
   • wp-content/dbcache.php flie (if it exists)
   • wp-content/upgrade directory
   • wp-content/plugins/w3-total-cache directory (if it exists)
4. Re-install W3 Total Cache, and make sure that Object Caching and Database Caching are disabled if you’re on a shared hosting platform.

Particularly in your case, since we can’t find any WordPress errors, pay special attention to the .htaccess directives, since they can create 500 errors like this without engaging WordPress’s error handling processes.

Hi Eric-

Thanks, that’s really good to know! Database caching *shouldn’t* be on by default, I’ll double check with the development team on that.

For the majority of websites and servers, Database caching doesn’t give that much of a performance boost, and sometimes it’s even slower than using MySQL, unless the queries on the site are very complex, so you shouldn’t see much, if any, of a performance loss from that.

You’re right, the setup wizard is a very new feature. We’re doing some digging to find out why the Database cache might have caused the error (it shouldn’t be fatal like that) but in your case I’d recommend leaving it disabled. Cheers, and thanks for the help Eric!