Why The Surly Curmudgeon Had to Leave GoDaddy
When I first started playing with WordPress a few years back, The Surly Curmudgeon was hosted at 1&1 (now Ionos). I had chosen 1&1, because the church website I had built in Germany using static HTML and FTP was hosted there. I abandoned my old website (also built manually with static HTML and FTP), and created a new site along the lines you see at The Surly Curmudgeon today using WordPress. As the site developed, I wanted to allow e-mail subscriptions and a contact form, but 1&1 wouldn’t support e-mail functionality in-house. I started shopping around for a new hosting service, and about that time received an e-mail notification about automatic renewal of a domain registration I had never used at GoDaddy. I thought I had cancelled the auto-renewal for that registration, and called GoDaddy to complain. When I did, the sales people got me interested in moving The Surly Curmudgeon to GoDaddy’s “managed” WordPress hosting. I decided to do that with the promise of a “seamless” site migration. That process was anything but seamless! The weeks-long struggle and near disaster to make it happen is detailed – here.
But finally the site got moved to GoDaddy, and everything was mostly fine. Over the next couple of years though, GoDaddy’s warts started to become apparent. The first issue came when I tried to implement a simple contact form. During testing, I discovered that if anyone using the Brave browser tried to submit the contact form, it would break the site’s image rendering for all visitors! After weeks of struggle between the Brave community, my theme (GeneratePress) support folks, and GoDaddy, the issue turned out to be caused by GoDaddy’s content delivery network (CDN). The details of that tragedy are posted – here. That issue was resolved by simply disabling GoDaddy’s CDN – not the most elegant solution, but at least we had a workaround for the problem. Obviously, performance on the site suffered by having to leave the CDN turned off.
Then about a year later, The Surly Curmudgeon’s contact and subscription forms suddenly stopped working when a WordPress update broke the plugin I was using to display the forms – Popup Maker. Since they weren’t working anyway, I simply unpublished the subscription and contact forms, and removed the links to them from the site’s navigation menus, as detailed here. I was way too busy to mess with them, moving house and writing up Bible Studies for my church and home group ministries. Once the move was completed, I had a chance to revisit the contact and subscription form issue. That turned out to be way more of a struggle than it ought to have been. Those travails are detailed – here.
In the process of getting the contact and subscription functionality re-implemented, I started to realize a few things I wasn’t happy about with my GoDaddy managed WordPress hosting.
- My Site Health screen started reporting issues I couldn’t resolve.
- The PHP version was old, and couldn’t be manually updated under GoDaddy’s “managed” WordPress hosting.
- Scheduled tasks like automatic backups and security scans using plugins were failing. It turned out that the “managed” WordPress hosting doesn’t support WordPress’ cron function at all – although I had to learn that from elsewhere than GoDaddy’s own tech support.
- GoDaddy was down altogether more frequently, and for longer episodes than I thought a “world-class” hosting service ought to be. GoDaddy’s feedback to customers about the status of the outage, and the projected restoral time were “less than forthcoming” – without so much as a banner on the support splash page, the chat greeting, or the IVR greeting message saying something like, “We are aware of the issue and we’re working to resolve it.”
- Performance on the site was poor, and getting worse.
- While editing blog posts, I noticed that each character entered in the Gutenberg editor (not noted for its stellar performance to begin with) was taking a second or even more to be displayed. This got so bad, I took to doing my typing in Notepad and uploading paragraphs of text from the clipboard.
- Editing performance was bad enough, but I noticed that page loads were taking way too long – sometimes upward of 30 seconds. Obviously, few visitors are patient enough to wait around that long for a requested page to load.
- Autosaves frequently failed, which sometimes led to data inconsistencies between a published post and a version being edited on-the-fly to correct typos or broken links. It was getting time-consuming correcting these inconsistencies.
- GoDaddy’s “managed” WordPress support – although responsive enough to meet the SLA – rarely found a solution to my reported issues. In fact, the last truly satisfying interaction I had with them was when I migrated The Surly Curmudgeon’s e-mail from Ionos.
All the while, I was putting up with this nonsense because I still had over half of my 3-year commitment to GoDaddy “managed” WordPress hosting left, and I didn’t want to lose a couple hundred bucks by moving. But finally, GoDaddy’s failings (particularly the issues with site speed and scheduled tasks) got to be “more than me job’s worth,” and I went looking for another host.
Searching for a New Home
After deciding to leave GoDaddy, my first inclination was to move The Surly Curmudgeon to Flywheel. I use Local by Flywheel as my local machine’s website development and testing platform. In fact having that local running copy of The Surly Curmudgeon saved my bacon during the migration process to SiteGround, which this post is allegedly about. I’ll get to that later. Flywheel’s push/pull integration between the local development environment and the “live” hosted site appealed to me greatly, as did the reports on their performance. Although reviews of Flywheel’s technical support weren’t altogether shiny, I was about to make the leap until I took a look at Flywheel’s managed WordPress hosting costs which were easily triple those of some other hosting services that came highly recommended. So I decided to shop around.
Anyone who’s been around the WordPress block a few times can tell you that shopping based on Internet reviews is fraught with minefields. My favorite example is WPBeginner. Please don’t misunderstand. I love WPBeginner. They do great work with tutorials on a wide variety of WordPress topics, and their reviews of WordPress plugins, themes, etc. are fair and informative. But… WPBeginner is also run by the same folks who publish the WPForms WordPress plugin and a number of other WordPress-related products like OptIn Monster. Unsurprisingly, their own products always show up in WPBeginer’s reviews of “best” ones in their various categories. This isn’t to say that the products are bad. In fact, I use their WP Mail SMTP plugin on The Surly Curmudgeon. It’s just that IMHO the reviews themselves should always mention up front and prominently that the reviewer has a vested interest in the reported review results and recommendations.
That said, WPBeginner’s reviews of best WordPress hosting services narrowed down my search to two – bluehost and SiteGround – both of which are also recommended hosting providers by WordPress.
An Abortive Flirtation with bluehost
Bluehost comes highly recommended. In fact, it is one of the WordPress forum’s own recommended hosting providers. It seemed like a no-brainer. The cost was low, and the reviews were sterling. I signed up for three years of their Plus WordPress hosting plan, and began the migration process.
The bluehost migration process begins with an evaluation of the candidate site for automigration. If the site passes those compatibility checks, the subscriber is sent a link to download and install the bluehost migration plugin. Once the plugin is installed and activated, what’s supposed to happen is that the plugin makes a backup copy of the site’s files and database, and then uploads the backup to bluehost for installation on one of their host servers. When I tried to do this at The Surly Curmudgeon, I almost immediately got a notification that the process had failed and that I should call the bluehost migration team at the telephone number given.
That I did. The bluehost support person I reached was very helpful and personable, but also just barely understandable. No worries. I know folks gotta make a living, and God knows telephone technical support and sales are not the most pleasant ways to do that. So I committed to working through the issue with her despite the communication difficulties, hoping she would point me to an article on bluehost’s support forum with detailed instructions for manual site migration.
After all, I had a fair amount of experience doing that with the move from 1&1 to GoDaddy, and the creation of local copies of the website on various local development environments. In fact, I already had a fresh copy of the wp-content files and the site database I had just downloaded to my local machine for that very purpose. Instead of pointing me to instructions for a “roll-your-own” manual migration though, the sweet but virtually undecipherable technical support person sent me to the bluehost Manual Migration Team.
The Manual Website Migration Team person who I then talked with offered to create a manual migration appointment ticket for me in exchange for another hundred or so bucks. This would have been almost half of what I had paid for 3 years of hosting service! Also, he was careful to point out that the site might be down for up to 48 hours during the migration, which might begin sometime within the next 10 business days. So I politely declined, and asked for a refund of the hosting charge. After all, The Surly Curmudgeon was still safely (if not optimally) running over at GoDaddy. I was then connected with sales who promptly (and incorrectly) processed my refund request. I abandoned the bluehost migration, deleted the migration plugin, and went back to searching for new hosting.
BTW – The refund from bluehost did eventually make it onto my credit card account after a few e-mails and telephone calls a little over a week later.
On to SiteGround
I had almost decided to go with SiteGround before I signed up with bluehost, so the decision to go with them after the migration failure at bluehost wasn’t hard. I signed up for SiteGround’s GrowBig hosting plan using a discount code from WPBeginner, and started the migration process. As with bluehost, the automigration process involves downloading and installing a migration plugin which packages up a backup of the site’s content files and database, and then uploads the package to SiteGround for installation on a SiteGround-hosted WordPress site the subscriber creates when signing up for hosting.
I started the plugin, and it gave a message saying the backup was being created and started displaying a GIF spinner… for the next 15 hours. When I looked at it the next day, and nothing had changed, I got in touch with SiteGround on their tech support chat. This is where SiteGround stands head and shoulders above any other hosting service I have ever used. The chat response was quick and friendly, but most importantly it was effective in resolving the issue. I asked a simple question, “How can I tell if a migration is still in progress?” The support chat person pointed me to a siteground-migrator.log file in the wp-content directory at GoDaddy. Unfortunately, the log was unhelpful. I decided to restart the migration.
First though, I eliminated all inactive plugins, and deleted three old site backups still lingering around in the old wp-content directory. Those backups would have effectively quadrupled the size of the archive file the automigration plugin would need to create. I also temporarily disabled my site security plugin – All-in-One WordPress Security & Firewall. Once I did that, I restarted the automigration plugin. This time, it displayed a progress bar in addition to the spinner GIF that indicated about 25% completion – a hopeful sign (or so I thought). After staring at that for another few hours, I got back in touch with the SiteGround support chat folks. They pointed out the following error in the siteground-migrator.log…
[20-Apr-2021 02:17:13 UTC] ERROR: Array
(
[type] => 1
[message] => Allowed memory size of 134217728 bytes exhausted (tried to allocate 925696 bytes)
[file] => /var/www/wp-content/plugins/siteground-migrator/shuttle-dumper.php
[line] => 102
)
I did a Google search for this error message, and found a helpful article on WPBeginner. The article recommended that the following line be added to the (GoDaddy) site’s wp-config.php file…
define( 'WP_MEMORY_LIMIT', '256M' );
After making that change, I re-launched the SiteGround migrator plugin. This time I got no indication of progress at all just as I had on the first attempt. Looking at the siteground-migrator.log I found a similar memory allocation error reported, but this time the amount of memory that had failed allocation was higher. So I increased the defined WP_MEMORY_LIMIT to 512M, and relaunched the plugin. This time, the file and database archive process completed successfully. Without any further actions needed from me, the automigrator installed my files and database onto my new SiteGround site, and e-mailed me a temporary link to the new site so I could check functionality. Everything seemed to be working fine, so I pressed on to the final step of the migration process.
Two Hours of Panic Following the DNS Change
Once the site was up and running on SiteGround, the last step in the migration was to go over to GoDaddy, and change the DNS nameservers for The Surly Curmudgeon’s domain from the GoDaddy name servers to the SiteGround servers. Before I did so, I decided it would be a good idea to put the old site into maintenance mode. I also failed to disable the login reCAPTCHA on the old site. THOSE WERE TWO VERY BAD MISTAKES which almost locked me permanently out of both sites. I made the nameserver change in the GoDaddy DNS management panel, and after a few minutes the new site began operating fine using its native domain name. So I turned on the All-in-One WordPress Security & Firewall plugin on the new site. I logged out, and tried to log back in, but couldn’t. I tried logging into the old site using the GoDaddy server address, and couldn’t log in there either. I ended up having to use FTP to re-name the site security plugin at GoDaddy. That allowed me to log in, and eliminate the login reCAPTCHA requirement from the GoDaddy site. I also completely wiped out the security plugin from the new site using SiteGround’s file manager. Once I was able to access the new site’s back end, I then re-installed the security plugin, and set it up from scratch without the login reCAPTCHA. In retrospect, I believe I may have been able to simply leave the new site running until the nameserver propagation completed to Google. After Google’s DNS got updated, I believe the login reCAPTCHA on the new site would have worked fine. But I was in panic mode, and that’s never a good state in which to troubleshoot problems. In the meantime, the new site was up and running. I was able to log into the back end using a local CAPTCHA function built into the security plugin, and everything seemed to be okay. But then I noticed another problem.
Database Character Encoding SNAFU
None of the Hebrew and Greek characters in any of the new site’s pages and posts was displaying properly. Instead, they were displaying as question marks. I got onto SiteGround’s support chat again. They pointed me to an article on the WordPress forum that detailed an issue with MySQL database text field character encoding. SiteGround’s MySQL database management system only allows UTF-8 encoding. Over at GoDaddy the tables were using utf8mb4_unicode_ci and utf8mb4_unicode_520_ci. The SiteGround chat person opened a ticket for me with SiteGround technical support who contacted me by e-mail within a short time. Their suggestion was that I go over to GoDaddy, perform a manual database export using UTF-8 encoding, and then manually import that database into the SiteGround site. I tried that using GoDaddy’s version of PHPMyAdmin, but was unable to figure out how to export with UTF-8 encoding. I informed the SiteGround support person about that, and he suggested I get with GoDaddy technical support and get them to help me with the database export.
In the meantime, I discovered that if I manually edited the Greek and Hebrew references on pages and posts, they would display properly after saving the edit. Nearly getting locked out of both sites had scared me. Also, having had no lack of experience with GoDaddy technical support, I had little hope of a desirable outcome from working with them on the issue. I decided that – painful as it might be – I would just go through all the site’s pages and posts to eliminate the question marks. Unfortunately this turned out to be a lot more labor than I expected, because not only were the Greek and Hebrew characters being mis-rendered, so were special characters like ä, ö, ü, —, and ° as well as all the smart quotes. It was going to take many hours of labor to get is all cleaned up. Thankfully, I had that local copy of the site running in Local by Flywheel on my machine, meaning I wouldn’t have to do all the cutting and pasting using GoDaddy’s servers. Because of that, I was able to leave the GoDaddy site in maintenance mode until my GoDaddy subscription expires. But then…
KaBONG!
After the new site had been up and running for almost a day, and I was busy doing the special character edits on the pages and posts, I got bored and decided to make a styling tweak to the success and error messages associated with The Surly Curmudgeon’s contact and subscription forms. While testing that, I noticed that the contact form was no longer working. It had been working fine right after the migration, but it apparently stopped a few hours later. I tried sending a test e-mail from the site using the WP Mail SMTP control panel, but that didn’t work either. Thinking the issue was with the MS-Outlook API key set up in WP Mail SMTP, I decided to re-install my mail plugin and restore its configuration from scratch. That didn’t work, and even worse, I was unable to reconfigure the MS-Outlook mailer configuration. I was about to send an e-mail to the WP Mail SMTP support folks when I realized I wasn’t receiving e-mail from anyone to my personal mailboxes and neither was the site’s e-mail box.
When I migrated the site from GoDaddy, my intent was to migrate just the site hosting, not re-point the e-mail-related DNS records to SiteGround. I still have an Office 365 Email Essentials subscription at GoDaddy that’s valid for another 2 years. However, the SiteGround automigration process takes it upon itself to change not only the migrated domain’s A record and other TXT records and CNAMEs associated with the hosted website, but also the MX records, and mail-related TXT and CNAME records. Those changes take a while to propagate, but once they made their way back to GoDaddy, all my mail stopped working! I got onto GoDaddy’s technical support chat and reported the issue. They pointed me to an article on their support forum detailing exactly what DNS records need to be entered into a “foreign” DNS server to make GoDaddy e-mail work. I can’t share that link because it can only be accessed if I am signed into my GoDaddy account.
I copied the page contents from the link the GoDaddy folks sent me into a text file, and sent the .txt to the chat support folks at SiteGround who helped me work through the instructions to get the SiteGround MX records and CNAME records pointed back toward GoDaddy’s mail servers and to enter the required TXT records. Once the DNS changes propagated over the next few hours, our personal e-mail started working again. I then re-installed WP Mail SMTP and configured it to use its MS-Outlook API to send e-mail using my website’s Office 365 account, and the site was once again able to send e-mail in response to submission of the contact and subscription forms.
It’s Baaaccckkk!!!
So The Surly Curmudgeon is back up and running on SiteGround, and I couldn’t be more pleased. Performance is much improved thanks to SiteGround’s integration with Cloudflare website performance and security services. SiteGround’s technical support is nothing less than sterling – much better than any I’ve had experience with over nearly 50 years in the IT business. The SiteGround website tools and control panel are a BIG improvement over both GoDaddy (not that difficult) and Ionos. Hopefully, popularity won’t spoil SiteGround like it has GoDaddy. Only time will tell.
Calling All Proofreaders – HELP!!
Over the last couple of weeks, I finished up editing The Surly Curmudgeon’s pages and posts to correct the special character rendering issue. I finished that up last night, so I need a favor…
If you find a typo in any of the site’s content – particularly queerly placed question marks and incorrect Hebrew, Greek, or German snipets, please let me know by either commenting on the page or post where the typo was found or sending me a comment using the contact form. If you send the contact form, please select “Reporting a Content Issue” from the Subject pull-down list.
THANK YOU! – I can use all the help I can get.