This is how this problem started. My preferred Web Browser is Firefox and the WordPress Admin Toolbar appeared there automatically each time I accessed my web site. This was fine but I began to get delays in opening my home page and more often than not 504 Gateway Time-out errors resulting in failure to load the page.
Pressing F5 to refresh the page seemed to fix it and the home page would reappear. I asked Fasthosts for help and pointed out that if I opened my home page in another browser e.g. Chrome the page would appear quickly but without the Admin Toolbar – because it hadn’t been enabled in that browser. Likewise, if I opened the page in Firefox on my wife’s computer or on my Android tablet it would appear quickly without the Admin Toolbar.
I’d been starting Firefox periodically to check for 504 Gateway Time-out errors and yesterday was initially pleased to see the home page opening very quickly – until I noticed the missing Admin Toolbar. Without it it’s impossible to edit my web site and I got worried. I remembered I had an option to log in via wordpress.com (rather than wordpress.org) because I had installed the Jetpack plugin.
Having logged into wordpress.com I clicked on the edit icon (like pencil and paper) and eventually got an error saying There was an error retrieving your site settings.
Clicking on Make sure your Jetpack is up to date gave me the option to log on to wordpress.org and then the WordPress Dashboard appeared at the Updates page, presumably to update Jetpack. However the page assured me everything was up to date.
Nevertheless I did choose the option to reinstall WordPress 4.6 but that made no difference when trying to log on afresh.
I used WinSCP to browse the server’s files and temporarily renamed the Plugins folder to PluginsXX, thus disabling all plugins. This did not result in my Admin Toolbar reappearing but naturally disabled things in my site, galleries, buttons etc.
As mentioned, all plugins were disabled but that didn’t help. Currently I’ve enabled almost all but for Disable Comments (because it caused an error causing the home page to fail to load after logging on via wordpress.com) and Jetpack because it had a hiccup or two.
Without Jetpack I can no longer log on via wordpress.com but I’ve copied the link to the wordpress.org Admin login and added it to Firefox so I can edit pages again. This is a workaround and not the way things are supposed to happen – but without the Admin Toolbar the page loads quickly without the dreaded 504 Gateway Time-out error. I have to use the separate link I copied to log in and edit but at least I’m up and running.
I previously backed up the site with WinSCP but its connection kept having to be remade when scanning a particular month of uploaded media. Filezilla didn’t have this issue when I switched to it instead. Apparently it’s also important to back up the SQL database but phpMyAdmin wouldn’t let me log in until I got help from Fasthosts on Twitter.
Tried deleting wp-admin and wp-includes folders from the server and replacing them with fresh copies from wordpress-4.6.zip but it made no difference. Also deleted folders left over from the first (failed) installation. Initially I renamed those folders, adding XX at the front of their names, so that they could easily be reinstated if necessary.
Looked at suggestions in the WordPress Codex but am hesitant at spend too much time exploring these complicated options because I can log in and edit my website.
Server time-outs in FTP
When trying to retrieve a directory listing of uploads folders containing a lot of files, the server kept timing out in both Filezilla and WinSCP. Filezilla’s dialogue looked like this:
Status: Insecure server, it does not support FTP over TLS.
Status: Server does not support non-ASCII characters.
Status: Logged in
Status: Retrieving directory listing of “/htdocs/wordpress/wp-content/uploads/2016″…
Status: Directory listing of “/htdocs/wordpress/wp-content/uploads/2016” successful
Status: Disconnected from server: ECONNABORTED – Connection aborted
and WinSCP looked like this:
Both FTP programs failed when trying to access the July uploads folder.
Thankfully I had managed to previously download the July folder – and because that month is finished there should be no new files there.
My local copy of the July (07) folder lists 16538 files totalling just under 2GB. It seems the sheer number of files causes the shared server to time out. If the uploads folders from earlier months remain unchanged then future backups can (hopefully) safely make accessing the server copies unnecessary.