Goodbye, web.com. Hello, greengeeks.com

With hopes that this doesn't come back and bite me when something big breaks, a quick post to note that somewhereville.com is, after 23 years on interland.com (which I selected to go along with the land/ville theme way back when) and then web.com, now being hosted on greengeeks.com.

I can't speak to the actual numbers, but a number of us folk sitting on "legacy" services on web.com and checking their website umteen times a day had a very long mid-May when a poorly-planned php 7.4 to 8.3 upgrade brought websites offline for nearly two weeks (kicking and screaming into the future, as it were).

It went from horrible…

To bad…

To stuff I've seen plenty of times thanks to bad Jetpack updating…

To the point of at least seeing the site…

With that problem resolved, a historical restriction of 300 MB to MySQL databases for legacy accounts resulted in my being frozen out of my WordPress Dashboard for yet another week.

This locked-out issue had to be self-diagnosed because there were no red flags on the web.com support side (despite several asks), but a simple flipping on of WP-DEBUG in wp-config.php:

// Enable WP_DEBUG mode
define( 'WP_DEBUG', true );

// Enable Debug logging to the /wp-content/debug.log file
define( 'WP_DEBUG_LOG', true );

… produced the following:

WordPress database error: [INSERT, UPDATE command denied to user 'adminaccount'@'IP.IP.IP.IP' for table 'wp_wfConfig']
INSERT INTO wp_wfConfig (name, val, autoload) values ('lastPermissionsTemplateCheck', '1716472207', 'yes') ON DUPLICATE KEY UPDATE val = '1716472207', autoload = 'yes'

WordPress database error: [INSERT, UPDATE command denied to user 'adminaccount'@'IP.IP.IP.IP' for table 'wp_wfConfig']
INSERT INTO wp_wfConfig (name, val, autoload) values ('serverDNS', '1716472207;407;209.17.116.160', 'yes') ON DUPLICATE KEY UPDATE val = '1716472207;407;209.17.116.160', autoload = 'yes'

WordPress database error: [INSERT, UPDATE command denied to user 'adminaccount'@'IP.IP.IP.IP' for table 'wp_options']
INSERT INTO `wp_options` (`option_name`, `option_value`, `autoload`) VALUES ('_transient_doing_cron', '1716472208.0914690494537353515625', 'yes') ON DUPLICATE KEY UPDATE `option_name` = VALUES(`option_name`), `option_value` = VALUES(`option_value`), `autoload` = VALUES(`autoload`)

Warning: Cannot modify header information - headers already sent by (output started at /data/50/5/86/11/5086011/user/6116905/htdocs/swv/wp-includes/class-wpdb.php:1850) in /data/50/5/86/11/5086011/user/6116905/htdocs/swv/wp-includes/pluggable.php on line 1435

Warning: Cannot modify header information - headers already sent by (output started at /data/50/5/86/11/5086011/user/6116905/htdocs/swv/wp-includes/class-wpdb.php:1850) in /data/50/5/86/11/5086011/user/6116905/htdocs/swv/wp-includes/pluggable.php on line 1438

Which indicated an inability to write to the database. And how does a personal blog fill 300 MB of text with less than 200 posts over 23 years? And why was the sum total of my database under 100 MB when checking inside of phpMyAdmin?

Those are great questions. I asked those questions, and also asked why cnyo.org was sitting at 222 MB when my database backup file peaked at 8 MB.

The answer, from five different call/chat attempts, was MyTime Support – a pay service that offered the opportunity of getting reimbursed if the problem was legitimately web.com's, but which required forking over $59.99 for the privilege of a one-time call for an answer that any reasonable support service should have provided ("Thank you for letting me know. The My Time Support price for database issues is $59.99. Shall I add it for you?").

And that was the last plastic straw.

I looked at three hosting companies – dreamhost.com, nixihost.com, and greengeeks.com based on a bunch of frantic "We gotta get outta this place, if it's the last thing we ever do" searches. This was when I also learned about the animosity some folks have for the parent company EIG (? See wikipedia. Then take a look at reddit).

If you want to know, the primary selling point for the move to GreenGeeks was in the email. The catch-all email, to be exact. One of the perks of running your own domain name is you can have an email address for everything you want, meaning everything I sign up for can have its own email address associated with it (then let email client filters do the busy work for you. Either by selling or hacking, you'd be amazed where these custom email addresses end up over the decades). If you don't have a catch-all, and have been doing this for two decades, you risk having to remake N^M unique email addresses to get access to them all again. This might have forced staying with web.com (because providers don't much like the spam risk associated with this) and that took dreamhost and nixihost out of the running (according to official word from one instance of each of their chat supports. Your mileage may have varied).

Migration was almost flawless – on mine and GreenGeek's sides. They currently offer a free migration service, but it would have taken longer to find all the login information than just run UpDraftPlus (just the free version!) to backup my site on web.com and then restore it on greengeeks.com.

To make life easy, I decided to create a new WordPress site on GreenGeeks with their one-click installer and just restore my old copy with UpDraftPlus. I had an issue with the Default theme during the initial install, so picked a different theme from the one-click install list. When I initially created the WordPress site for my other moved legacy website cnyo.org and ran the restore from the Dashboard, my first visit ended as below:

Not ideal. And not ideal in 6 browsers, 3 machines, with and without a VPN turned on. A possible solution, as proposed by support, was a server-side cache clearing, as they would have cached the created site upon creation but not the migrated site upon initial migration (so I could get full access to the Dashboard, could go to most any other link on the site because the initial installation didn't have any links to play with, but would always land on the front page of the one-click install version until their cache was cleared out).

A clean-out on their side and I was good to go (which would have happened anyway, but not over the 15 minutes it took to diagnose and resolve).

Same problem with somewhereville.com – except the site loaded completely fine on the browser I was migrating in but not any other (?). 15 minutes and two quick chats and problem resolved. On the other hand, email hand-off from web.com to greengeeks.com was flawless and completed over the course of minutes (I didn't miss that one vital email that changed everything for me. Or whatever.).


According to GreenGeeks practices, I'm 300% green with GreenGeeks. I've got two kids now, so I have to think about these things. Also, the site and email are a hell of a lot faster than they were.

Having been burned a bit by the reduction in quality support over the last five or so years, and having played with the migration of cnyo.org hosting and email first (domain name transfer to another company and hosting to GreenGeeks) to see what the process would look like, I have learned a few important lessons about web.com in the process that I provide below if you hadn't had the pleasure (not unreasonable items for the time being):

  1. do a chat first to get an official record of what you want to know and don't forget to copy + paste if problems/situations come up you're not happy with.
  2. at least for web.com, where the support doesn't seem to keep a record of the times you ask questions unless it gets to the point of a ticket, ask three or four times on chat and by phone if you don't like the answer you're getting. Despite the training, some people will dig a little deeper than others and I had gotten out of three previous issues that they tried to throw at MyTime Support.
  3. make sure your account is closed completely if/when you jump ship. I got an invoice for a forwarding service I thought was cancelled when they said "everything is closed" and had to call again to get my $2.34 back (and even more-so officially close the account).
  4. Seven-year itch – I have the following from my chat when I called to close the account, but when I called to verify, the person on the other end knew of no such thing. Watch out for differing policies over two different mediums from the same company: "Unfortunately, due to tax reasons, we are required by law to keep your account open for 7 years from the last time logged in after all products were deleted. By keeping the account open, if there is ever an audit, we can provide you all necessary invoices and documents from the account. I can assure you moving forward, there should be no unauthorized charges as I already made sure that there are no active products and credit cards save in your account."
  5. Domain name transfer is slow (5 days), but the updating of nameservers and propagation is fast (for me, 5 minutes to be getting email and website).
  6. UpDraftPlus made the whole process very easy – I would have moved providers sooner if I'd known this. Once you create the brand new WordPress site, (1) the Restore overwrites the whole damned thing and (2) your wp-config.php doesn't need you if their one-click installer works right, so you don't need to know anything about your database or login credentials. If your provider offers a WordPress install option, jumping ship might be even easier than that.

Some Recent WordPress Theme Hacking Issues (Mass Emails To Non-Existent Domain Name Addresses) And A Couple Of Things To Look For

I've spent the past few weeks making several new email client filters each day, with subject lists that look like the following:

Saturday and Sunday Only! Today's Special Buy of the Day!

One day sale event – today only, [ insert date here ]

[ insert name here ], check out this weeks specials – up to 75% off on selected items

[ Insert name here ], 10% discount for Brand or Generics for purchases placed before [ insert date here ]

We appreciate your past business with us

[ insert name here ], some of your items are back in stock now – complete your order today

[ insert date here ] deals and savings from your supplier

We're talking between 2000 and 5000 emails a day of the following mishmash, with various random email addresses used, random first names and message content (always with a link or two, plus unsubscribe links), and all to email addresses that look like

[ person's first name ] + @ + somewhereville.com

This was occurring from the website despite having many popular site-security-related PlugIns running: Including Wordfence, Sucuri Scanner, and Jetpack (not that Jetpack would protect from site problems). As it turns out, Sucuri *might* have found the problem had I installed it (at least) 6 months ago.

The amount of email has gotten so bad I the past few weeks that the site itself has been taken down thrice by my +10-year-long hosting company (web.com. Can't blame them for this one). Before telling you about where the problem eventually settled, I'll note the following attempts to find the problem, listed below.

Steps To Diagnose The Problem

1. Taking the site down – which worked

2. Running diffs on all of of the files in the WordPress install (against a freshly downloaded copy from wordpress.org) – this helped greatly

3. Deleting the many files no longer use by wordpress (having run it since 2.1.something and allowing WordPress to do auto-updates) – no affect

4. Scouring my hosting folder for hidden files, modified .htaccess files, or anything else – nothing found

5. Looking for date changes on .jpg files to see if malicious code had been embedded into one of the images that always loads with the site – nothing found

6. The big one – switching from my primary theme (a heavily modified version of relaxation 3 column from 2006) to one of the provided WordPress themes.

The Problem, Localized

The problem, then, was localized to my old theme – which could have meant one of two things

1. Something in the php was causing the problem by being too old (a piece of php that WordPress recommended removing from all themes – that I never read about)

2. Something was, despite having my permissions set for read-only on the server (because this theme is never updated by WordPress), tweaked in one of the theme files (which turned out to be the case)

In my case, a few modifications had been made to theme files over 6 months ago that sat dormant in the .php files until something eventually came along to start spitting out beaucoup spam.

NOTE: Everywhere you see "->" and "< -", these have been replaced from "<" and ">" to keep anything from being read by your browser)

1. This nasty piece of work was deposited into an index.php file many moons ago (but the file date had not changed, so it went unnoticed)

2015august27_infected_1

The following had made into ALL of the theme index.php files in my WordPress install

2015august27_infected_2

These are to be contrasted with the following, more generic look for the top of an index.php file:

?php get_header(); ?

Decidedly different.

These are both interesting, but turned out to not be the problems. Instead, my relaxation-3-column theme had its 404.php, archive.php, and index.php files modified at some point in the distant past (at least as early as November of last year) with the following new lines:

404.php

2015august27_infected_3

vs.

->?php // relaxation 3 column

->?php get_header(); ?< -

archive.php

2015august27_infected_4
vs.
->div id="content"< -

index.php

2015august27_infected_5
vs.
->?php function arphabet_widgets_init()
...

These beg the question – how does one find out that this stuff isn't supposed to be in a theme file?

The answer, assuming you know a little php, is to compare and contrast you potentially older theme files with new theme files (such as those pre-installed in WordPress). In all the above cases, available themes look like the "after" files above, with unreadable code not present in the tops of the files.

So, long-short, if you find your inbox stuffed with hundreds or thousands of spam samples coming from your own domain, a good first place to look is your running theme. Much like the BSG Episode "33", you may find yourself NOT getting spam after a certain period of time if you make a simple change from one theme to another (certainly a simple way to determine if the attack is from the theme or not).

Solution And Testing

The test for the modifications was simple:

First, backup your theme files to your local machine (or make a folder in your directory tree somewhere)

Second, after checking and (if necessary) making modifications, replace your index.php file FIRST, as this is the basis for your theme (and what WordPress looks for first in the theme). Your site will load, although it may look like hell.

Third, replace all those theme files which didn't have something odd in them (like the gobbledegook above) and reload you site. Then, WAIT to see if you get spam (for my problems above, this took about, honestly, 33 seconds). Your site may still look like hell depending.

Fourth, change other problem files and upload them 1-at-a-time, then reload and wait to see if the spam starts.

Fifth – repeat #4 until your theme is all back up

Sixth – when all uploaded, change your theme permissions to READ-ONLY (although this did not help me)

With luck, your spamming problem fit the mold of the above and google brought you to a page that would help. So say we all.