Sometimes a WordPress error looks really scary. A client recently contacted me when she saw this after logging in to her site via wp-admin. I have also seen this on the front end of some websites in recent weeks as well.
Notice: Indirect modification of overload element of WP_HOOK has no effect in … /…/html/wp-content/object-cache.php on line 664
This message was repeated about a hundred times, filling the screen and preventing access to any part of the back end of the site. Luckily, I was able to solve this in about two minutes. Since I could not access the backend of the website, I immediately accessed the server via sftp. SFTP refers to Secure File Transfer Protocol. It is a network protocol that provides file access, file transfer, and file management over any reliable data stream. There is a special sftp login provided by your host (or you can create a new sftp user login on your hosting platform), and it can be accessed with an ftp/sftp client such as Filezilla. This website was hosted at GoDaddy, on one of their Managed WordPress hosting plans, which makes it very easy to find the credentials for sftp access.
Once logged in to the server, the first thing I did was rename the plugin folder inside the wp-content folder. I changed the name to x-plugins. This effectively turns off the plugins so you can test to see if your issue is plugin-related. Doing this did not fix or change the error message, so I changed the name back to plugins.
Next, when I looked at the error, I discerned that it was related to a caching problem on the server. When I looked at the files on the server, I saw a file there called object-cache.php.
I downloaded the file onto my desktop and deleted it from the server. (I downloaded it so that if I needed the file, I would always put it right back.) This was the magic trick, as I suspected. After deleting this object-cache file, the errors went away and the back end of the site worked fine.
I did some research on the object-cache.php file and caching in general. The WordPress Codex states that, by default, the object cache is non-persistent. This means that data stored in the cache resides in memory only and only for the duration of the request. So, it seems something got “stuck” and this file should not have been present. The website does not have a caching plugin, which might have caused this, but GoDaddy does automatically cache website files, so this may have been the cause.
Just to be sure that I did not make a critical error, I reached out to Taylor Lovett of 10Up to confirm that my deletion of this file was ok. He confirmed that the file must have been created by a plugin, and the error related to this change in WordPress 4.7, which explains the timing of this error after GoDaddy performed the WordPress update.
This article on the WP Tavern by Ryan Hellyer describes different types of caching, how they work and how they are used.
I am sure I could have also called GoDaddy and their support technician would have solved this for me (and if this had not worked I might have done that!), but it was very gratifying to fix an error that looked really scary in a matter of minutes.
Note: Since I first encountered this error in December, I have seen it a few more times – always on GoDaddy sites.