- Posts
Hello,
I have two websites built with Boldgrid and the GridOne Theme a few years ago (on webhostinghub which includes Boldgrid for users). They’ve been fine until just now. Both are now down and when I turned on debug I get this error:
Deprecated: implode(): Passing glue string after array is deprecated. Swap the parameters in /home/labtec5/public_html/arctechstrategies.com/wp-content/themes/boldgrid-gridone/inc/boldgrid-theme-framework/includes/configs/configs.php on line 33
This appears to have happened just after WP automatically upgraded to 5.6.2. I cannot find a newer version of GridOne that might fix this, so wondering what to do! I could modify the code but I’m not sure if this is the right way to handle it, and I don’t know which parameters to swap.
Thank you,
EricHi 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 Jesse,
Thanks for the prompt reply! Unfortunately I think something else is going on. Switching to php7.3 or 7.2 cleared the Implode error, but I still get a “critical error” message from the browser and no website.
What’s odd is that I can still log into the sites as Admin, and even use the “visit site” link in the Admin bar. But after logging out the site stops loading again. This was true even with php7.4.
I installed the newer version of GridOne (1.24.2 to 1.25.7) but that also did not improve anything. I cleared the browser cache, etc. and switched back to php7.4, still not loading. But I also don’t get any debug errors.
Obviously there’s something subtly different about how the site works when I’m logged in or not, but I don’t know that process. Maybe this isn’t a Boldgrid problem?
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.
Jesse,
I am using W3 Total Cache, but purging did not help. I even disabled it, and also disabled Boldgrid SEO, no improvement. Most peculiar!
I think I mentioned this problem started right after the automatic upgrade to WP 5.6.2. Does that give any more clues? Since I’m not getting any debug errors I’m not even sure where to look.
— Eric
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/cacheand then re-activate W3 Total Cache.Wait! Turns out W3 Cache did not deactivate the first time. When I went to my other site and did all the previous changes, including deactivating the cache plugin, it started working. Same with the first site.
So right now both sites are working normally with W3 Total Cache disabled. If I turn it back on, they stop loading. They are both running v2.1.1 which is the latest, and I went back to php7.4.
— Eric
Hi Eric-
Looks like we were responding at the same time. Try the step above to manually delete the
/wp-content/cachedirectory and re-enable the plugin.Yeah, sorry, we overlapped. I deleted the cache directories and reactivated the plugin, but that stopped the sites loading again!
FWIW, I have the cache plugin active on arctechstrategies.com, but I still have it disabled on the other site, artstechpartners.com, and that’s loading fine. I’m not sure what you can see from looking at source code, but maybe having them to compare would be useful.
Also, I have a third site (my main business site) that is WP but did not use Boldgrid. I just installed W3 Total Cache there and it’s fine. Sped it up, too! So maybe this is some interaction with W3 cache and another part of BG?
— Eric
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?
Well, let’s see… Both arctechstrategies and artstechpartners are running Admin Bar Edit Content Links, Akismet Anti-spam, Boldgrid Easy SEO, Boldgrid Gallery, Lazy Load Optimizer, Sucuri Security, Updraft Plus, W3 Total Cache and WP Power Stats
Lab-tech-systems.com is running all of those *except* the two Boldgrid plugins and Lazy Load. And it’s not a Boldgrid site.
I deactivated all the plugins on arctechstrategies except W3 Cache, no change. Deactivating that is the one thing that brings the site back. But it causes no problem on the lab-tech-systems site.
I still wonder about the timing of this, with the upgrade to WP 5.6.2, and the fact that the site loads when I’m logged in. I can turn debug back on and turn on logging, but it’s not putting up any messages in real time.
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:
- Deactivate and delete W3 Total Cache
- 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. - Delete the W3 Total Cache files and folders:
wp-content/cachedirectorywp-content/w3tc-configdirectorywp-content/object-cache.phpfile (if it exists)wp-content/advanced-cache.phpfile (if it exists)wp-content/dbcache.phpflie (if it exists)wp-content/upgradedirectorywp-content/plugins/w3-total-cachedirectory (if it exists)
- 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 Jesse,
Well, your Step 4 was the answer! Before I reinstalled W3 Cache I looked at the settings, and database caching was turned on. Turning it off cured the problem. I’m fairly sure it’s been turned on for years because that was the default, but for whatever reason now it’s a problem. As it turns out, the lazy load function in W3 Cache was not turned on for any of the websites.
So I think maybe we’re done. Thank you very much for your patient and responsive help with this issue!
— Eric
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.
Well, to be clear, when I added W3 Cache to the lab-tech-systems site it opened a setup wizard and stated that database caching is NOT on by default (and it wasn’t). But on the other sites, which were built a couple years ago, I’m pretty sure it was because I wouldn’t have known to change it. I don’t think there was a wizard. And they did work up until now. Doesn’t hurt to check I guess.
Thanks again!
- The topic ‘Implode Passing glue string after array is deprecated’ is closed to new replies.
