Why I Left Bluehost and You Should, Too

Web Hosting Support Nightmare

It’s been several years since I left Bluehost web hosting. Even before it was bought by EIG and officially went to shirt. I remember back then I was having a very long discussion with a support rep who simply wouldn’t understand what I was asking and kept pushing the conversation in the wrong direction. I had saved the chat to write a post about it but decided I wouldn’t waste my time.

I changed my mind about not writing when recently a client was having trouble setting up his recently purchased Reply By Email (a.k.a. RBE) plugin. He reached out for support and I found that his server was not able to connect to Gmail via IMAP.

Full disclosure: at the end of this post (and in this paragraph) I have an affiliate link to CloudWays, my current favorite host. If you’re at all amused or terrified by the (entirely, and sadly, true) story below, feel free to join me and countless others who have moved away from EIG companies into really good hosts like this one.

The Issue

You see, the RBE add-on for bbpnns connects to an IMAP or POP3 server looking for messages that are meant to be posted to a given topic thread. When using Gmail, it defaults to IMAP at port 993 over SSL. The issue with Bluehost is that the Gmail host (imap.gmail.com) or port were being blocked. How do I know? Simple: I logged in via SSH and ran the usual telnet command to test connectivity:

$ telnet imap.gmail.com 993

Now, if you’ve ever played around with Linux or worked in an ISP, you probably know what telnet is. Heck, before I dove into full time programming I would play around with the command line and even send emails using telnet – just for fun. If you’ve never heard of it, suffice to say it’s a command that connects to the server through a given port (the number part) and lets you talk to that server. It’s not really secure and nobody uses it nowadays for anything other than checking if a port is open (receiving connections).

But I digress…

The Troubleshooting

I told the client what the issue was and that he had to talk to Bluehost to get them to open the port. What ensued is bizarre, to say the least.

The client said he was having trouble answering the support rep’s questions, and asked if I could call him on skype and he’d put the support rep on speaker phone. We had our makeshift conference all set up. I explained the issue to the rep who would actually type our conversation to another tech rep over a chat window.

For clarity, let’s call the phone guy The Rep and the chat guy The Tech.

When I mentioned the telnet, The Rep actually asked me to speak a bit slower because the line was cutting out. So I typed the command to the Skype chat so that the client could read it out for him.

Client: It’s t-e-l-n-e-t space imap.google.com space 993

The Rep: Ok, let me read that back: t-e-l-M-e-t…

So, yeah, that happened. The Rep had never heard of telnet before. After learning the correct spelling, The Rep typed it over to The Tech, who replied that the port was open. After a brief moment of happiness, thinking that The Tech had realized the issue and quickly opened the port, I saw that my test was still failing.

# telnet imap.gmail.com 993
telnet: connect to address Connection timed out
telnet: connect to address Connection timed out
Trying 2607:f8b0:400e:c00::6c...
telnet: connect to address 2607:f8b0:400e:c00::6c: Network is unreachable

For those of you not very familiar with telnet testing, this is what a successful connection looks like (real example, against google.com port 80).

# telnet google.com 80
Connected to google.com.
Escape character is '^]'.

I told The Rep as much, who relayed it to The Tech.

Down The Rabbit Hole, on LSD

What happened next really baffled me. The Tech said that the IP I was trying to connect to was wrong. That it was supposed to be 50.xx.xx.xx (IP hidden on purpose). However, that’s actually the IP of the Bluehost box. And this was actually AFTER I had repeated multiple times that the plugin had to make an OUTGOING connection to Gmail IMAP.

And if things couldn’t get worse, The Tech then starts asking which directory the form is in.

Wait, what?!

I thought I had misheard ‘forum’, which may have had something to do with his reasoning, but he really did ask about ‘form’. Gravity Forms form, to be exact. And what email address was set up to receive the notification (??). It’s like they were talking to a different client about a completely different issue.

After explaining once again that Gravity forms had nothing to do with the issue, that it’s a totally different and unrelated plugin trying to make a server-to-server connection and the originating server was blocking said connection, The Rep told us that The Tech was going to have to open a ticket to continue working on it. Ticket is good when it comes to opening firewalls, as it’s really not something anyone should be able to do without approval.

So I asked that they copy my email address to the ticket in order for me to answer any technical questions they might have. And that was the end of the call. The client and I decided to wait patiently until Bluehost support gave us an update.

But Wait, there’s more!

The Followup

The next morning the client forwards me the followup email from Bluehost – of course I was NOT CC’d in it like I’d asked, but that was kinda expected. In the followup email, they again talk about… no, you wouldn’t believe it if I just said it. Let me paste the entire email (sensitive information redacted) and you see for yourself.

From: cases@support.bluehost.com <cases@support.bluehost.com>
Date: <<REDACTED>>
Subject: Support Followup

Hello <<REDACTED>>,

Thank you for contacting customer support, I am following up on your ticket regarding your mail ports. While looking in to this issue for you I was able to validate that your email port 993 for outbound emails is open and is open to google email accounts.
It seems that your form is currently attached to and is sending emails to <<REDACTED>>. If you wanted to use a separate email like a gmail account this will need an admin email update. I was able to find some helpful documentation on setting a notification email address for you to assist in this set up.


If you have any other questions or concerns please feel free to contact us at your convenience by either calling <<REDACTED>> or using our live chat at <<REDACTED>>. Thank you very much!

Thank you,
Technical Support


HOLY INSISTENCE BATMAN! Are you forking kidding me? Still with the Gravity Forms crab?! I didn’t even risk hoping that someone had actually opened the port when I got to the GF part. But I tested it anyway, and of course it was still blocked.

The client and I are still waiting for an answer to my reply stating that they were totally off with GF and repeating my telnet tests (the same ones I provided above). Hopefully they’ll forward the message to someone who actually knows what they’re talking about and finally open the bloody port. I’ll provide an update once we get one.

In the meantime, if you’re looking for good hosting, know that Bluehost IS NOT IT. None of the EIG companies are. I highly recommend CloudWays over any of the other hosts I’ve tried over the years.

I don’t even know why Bluehost keeps sending me affiliate emails – I’ve never once used their affiliate system after leaving (and can’t remember having done so while I was still with them), and I wouldn’t dare send anyone their way. Nobody deserves it.

Update: The End Result

Several days have passed and the client has decided to leave Bluehost. He managed to reach a supervisor, who referred him to a tech from EIG (not Bluehost). The EIG Tech said he conferred with several sysadmins and they were concerned with the security implications of opening an outgoing connection to Gmail.

I pointed out that the incoming connections to 993 were wide open, and their concern was the same as the following analogy:

You have a house in a bad neighborhood. Your door is always wide open. You tell your kids to not go to the neighbor’s house because if they do, someone might come into your house (with you in it) and rob it.

Dear EIG, keeping your kids from playing at the neighbor’s will not keep attackers from robbing you if your door is always wide open. The neighbor’s security is their concern and will not affect you in any way.

Configuring the bbpnns Reply by Email Webhook

You’ve chosen to use the bbpnns Reply by Email Webhook instead of the WordPress Cron system. Smart choice. Now, every time the Webhook is called, the plugin will check your inbox for the newest replies to be added to your bbpress forums.

[vinyl scratching] Wait, what’s a webhook?

Webhook is nothing but a fancy name for an action taken by a site when a given URL is accessed. In the plugin settings you were given a web address to use.

The trick now is getting that webhook called as frequently as possible without enraging your web host.

Keep reading to learn about our recommended methods of setting up the Webhook calls.

  1. IFTTT
  2. Zapier
  3. Real Cron Jobs


IMPORTANT: On March 30, 2019, Gmail changed their API and IFTTT can no longer offer its service. We’re sorry, but it is not within our control. Please refer to the Zapier or Real Cron Jobs steps instead.

IFTTT stands for If This Then That, and is a free service which lets you connect services according to pre-defined rules, called Applets (they used to be called recipes). You can create your own applets or use any of the many available applets built by IFTTT, service providers, or users like yourself.IFTTT connects seamlessly with Gmail (and Google Apps, which essentially the same thing), and Office 365 (for paid outlook accounts) but currently does not support checking POP3/IMAP mailboxes. If you need POP3/IMAP direct checks, skip ahead to the Zapier and Real Cron Jobs sections below.

For the purpose of this tutorial, we’ll assume you’re using Gmail. Setting up Outlook 365 (if you have the paid service) should be pretty much the same (we haven’t done it ourselves, to be honest, as we don’t have the paid service).

Here’s what you need to do to get bbpnns Reply by Email running with IFTTT:

  1. Create a free IFTTT account just to use with this plugin, if you don’t already have one. Simply go to https://ifttt.com and follow the signup steps. You can also choose to connect with your Google or Facebook account.
  2. Once your account is set up, go to the Gmail service page: https://ifttt.com/gmail (or https://ifttt.com/office_365_mail if you’re setting up your paid Outlook account).
  3. You can only have one connected Gmail account per IFTTT account, so if you already have Gmail connected with your existing IFTTT account, disconnect it *. Then click the big Connect button.This will take you to the Gmail OAuth screen, where you’ll need to log in with the Gmail account you set up in your bbpnns Reply by Email settings screen, and click  ‘Allow’ when prompted.
  4. That’s it for Gmail. Now we need to tell IFTTT that we want to use Webhooks. Go to https://ifttt.com/maker_webhooks and Click connect, just like you did for Gmail.You will not get any Oauth screens or anything. Just the Webhooks screen without the connect button.
  5. Finally, set up your Applet to call our Webhook when new messages arrive. IFTTT seems to check Gmail every minute, so this is by far the best solution you can get. Click My Applets > Create, or go directly to https://ifttt.com/create. You’ll see the new applet screen:
    Click on the big blue “+ this” link (yes, it’s a link – I was a bit lost way back when I first tried it).
  6. Enter Gmail in the “Choose a Service” screen, and click the Gmail icon.
  7. In the Trigger screen that comes up, select the box that says ‘Any new email in inbox’. You’ll be taken back to the New Applet screen with the ‘+ that’ now linked and the Gmail icon replacing the ‘+ this’. Click ‘+ that’ and type Webhooks. Click the Webhooks icon.
  8. Click the ‘Make a web request’ action box (the only one available at the time we wrote this tutorial).
  9. Enter the bbpnns Reply by Email Webhook URL you were given in the plugin’s settings screen in the URL field. Leave the other fields as they are, as they are not important. Finally, click the ‘Create Action’ button at the bottom of the box.
  10. You’re almost there! You can now choose to change the description of your action and whether to receive notifications when the applet runs. Just click ‘Finish’ to complete the applet creation.

Once your applet is created, you can turn it off or on, and also force check the Gmail account.

* You can take a more complicated approach and share a gmail account by setting up labels for messages that contain <you>+usc_ as the beginning of the “to” field, and have the Gmail trigger run when a message gets labeled, but that’s beyond the scope of this tutorial.


Zapier is another service like IFTTT, where you get to create “Zaps”. Like IFTTT, you can connect to service providers and create triggers. Unlike IFTTT, it lets you connect to IMAP so you can use it for free Outlook/Hotmail accounts and even your hosting provider’s email service if you’re using that. The downside of using Zapier is that it only checks your mailbox in 15 minute intervals instead of every minute, so your forum participants are likely to think something went wrong and re-send the replies over and over. Each email reply will be translated into a forum reply, even if it’s a duplicate.

IMPORTANT: The bbpnns Reply by Email plugin requires an email server that supports “plus aliases”, i.e. sending messages to foo+bar@domain.com is the same as delivering to foo@domain.com. To our knowledge, the only large hosting providers that currently support this are Gmail and Outlook/Hotmail. The plugin will NOT work without it. Only go the IMAP route if you tested “plus alias” support manually or via the plugin settings screen. You’ve been warned :). Continuing…

To set up a Zap to trigger the webhook, follow these steps:

  1. Create a free zapier account if you don’t have one;
  2. Search for IMAP by Zapier app and select it;
  3. Search for Webhooks by Zapier app and select it;
  4. Click the ‘Use this Zap’ button in the box that says ‘Create Webhook post from new IMAP emails’.
  5. Follow the instructions to create the Zap. When prompted to connect an IMAP account, use the IMAP settings that your hosting provider gave you;
  6. Click Save+Continue;
  7. Select Inbox when prompted to select an IMAP folder. Click Continue;
  8. Click Fetch+Continue to test the connection;
  9. If the test is successful, click Continue to set up the Webhook;
  10. The only option now is to “Fire off a single POST request as a form or JSON”. Click Continue;
  11. Enter the Webhook URL you were given in the bbpnns Reply by Email plugin’s settings screen in the Zapier URL field. Click Contiue;
  12. Click Send Test to Webhooks by Zapier. Don’t worry if it says that the test was successful but no data was available. That’s intentional.
  13. Finally, click finish.

Zapier will check the mailbox for new messages every 15 minutes and call our plugin to do the processing.

Real Cron Jobs

The Cron system was designed to let people run programs at given dates/times or intervals (called jobs). It is essential in any Unix or Linux environment, and all decent hosts will let you create new jobs.

WordPress tried its best to create a faux Cron system for those who can’t or don’t want to deal with real Cron systems. However, because it needs to keep its performance good, it can’t simply run indefinitely in the background waiting for whatever date/time there are jobs to run. It only runs when someone visits your site, so even if you have a job that was set to run at, say, noon every day, and your site only receives a visitor at 5PM, that’s when the noon job will run.

You can (and, for bbpnns Reply by Email to work effectively, should) replace the Cron functionality that’s bundled with WordPress with a real Cron job. It’s quite simple and jsut requires editing wp-config.php to disable the internal WP Cron before running your own.

There are several tutorials available on how to do that. I like the one at SiteGround.

Feel free to follow that tutorial to the letter if you want to (to replace WP Cron), especially if you chose to not use the Webhook.

To get bbpnns Reply by Email to work as a Webhook, you’ll need to add the Webhook command that you got in the Settings screen as a new job in the Cron Job screen in cPanel – you don’t need to replace WP Cron at all.

Set it to run as frequently as possible without enraging your hosting provider. SiteGround asks that you don’t run any jobs in intervals smaller than 30 minutes. This is obviously not frequently enough for any good user experience (where’s my email reply? should I send it again?), which is why using Cron Jobs is last on our list.


This concludes our tutorial on how to set up bbpnns Reply by Email to work with Webhooks. We strongly believe that setting up IFTTT with Gmail is the best option to get the smoothest email to reply user experience.

If you still don’t have the bbpnns Reply by Email plugin,




Why You Need Website Care

So you got yourself a car. Congratulations! Now you can commute to work a bit more comfortably and not have to rely on transit timetables. But with the car comes new situations that you didn’t have to deal with before – like taking care of a flat tyre. Sure, you can replace it with the spare, but what do you do with the punctured one? Unless you’re in the tyre repair business, you wouldn’t try to fix it yourself, would you? You could try to Google how to do it and buy the tools, but heck, you have more important things to worry about in your life/work/business than fixing a puncture. You take it to a professional – a person who knows the trade and is quite good at it.

It’s not much different when it comes to your website, WordPress or otherwise.

Your website’s importance varies depending on the role it occupies. If it’s just a hobby blog where you write about some of your deepest thoughts and feelings (Facebook pretty much made that kind of site obsolete), then website technical issues really won’t mean much to you. On the other end of the spectrum, if you’re in the retail business and your e-commerce site goes down, that’s akin to locking the doors on a physical store in the middle of the day. You can’t let that happen. But just like in our punctured tyre example, your main focus should be your business, not your website.

It’s a lot of work to put up an effective and pretty website. What many people don’t realise is that once it’s up, it needs to be looked after. What can possibly go wrong, you ask? Keep reading and try not get too scared.


Website Security

The vast majority of people want to make money. It’s part of our survival instincts. Also, everyone wants to have fun, whatever fun may mean to them. Whether it’s for the money or for fun (or in a perfect world, money-paying-fun), some people will try to take advantage of your website. That’s the internet for you. This can go from stealing your client’s credit card information, down to placing their ads on your pages so that your traffic makes money for them.

Back in the early 1990’s, when I was just dipping my toes in the computer world, I asked my then mentor how to keep computers safe. His answer: turn it off, unplug it from the power grid, and store it in a safe. And even so it won’t be 100% safe. The internet was in its infancy then, with no such thing as broadband and the fastest modems you could get would download at a top speed of 5 bytes per second.

The number of users since then has multiplied enormously and with that, the number of hackers (or crackers, or whatever you want to call them). And the sad reality is that there isn’t a single piece of software that can be truly safe from attack. It’s not necessarily because the software itself has flaws, but because it depends on a whole ecosystem for it to work – other pieces of software, hardware, and even users (many attacks are successful because they manage to scam users out of their passwords).

The best we can do is make it hard for attackers to succeed. Software bugs and vulnerabilities need to be fixed as soon as they’re disclosed, as many attackers rely on outdated software to gain access to servers and other systems.

When it comes to website hosting, we also need to choose our host company well. It’s really no use to have your website nice and up-to-date if the server that your files are in has insecure software that you can’t control. For example, if you’re on a shared server that doesn’t have its file permissions set correctly, you’ll be vulnerable from other people’s insecure software. If they get attacked, then your site is as good as dead, too.

So what’s the solution? Besides keeping your site up to date: remediation.


Back to our flat tyre analogy, you wouldn’t drive without a spare, right? The same can be said for websites, especially those that change frequently, like a blog or ecommerce site.

When things go wrong (and mind you, they will go wrong at some point in time), you’ll be relieved if you have a recent snapshot of your website.

This is what we call a backup and it’s saved many a business’ bacon time and again. When backing up a site, we store a copy of all files and the database on a separate server, so that if the server itself blows up, your backups are safe.

The frequency with which you backup your site can depend on how often your site changes. Daily backups are fine, but some sites can go to extremes like getting immediate file backups and redundant databases (where changes to the database are automatically applied to a secondary database on a different server).

Malware Scanning

OK, so you managed not only to get backups done frequently, but also to recover your lost files and data. Next thing you know, your site is attacked again. You’d be surprised as to how common this really is.

The problem is that when you backup your site, you’re probably doing the attackers a favour and backing up their means of attacking as well. So when you restore the files, they’ll still have the front door wide open for them.

That’s why it’s important to, as well as keeping your site up to date, scan your site periodically for malware and clean it up. Malware are the files and data that attackers are able to embed into your website to let them do what they want.

Security Plugins

There are some handy WordPress plugins that assist in tying up loose ends security-wise – from hiding your admin area behind a custom address, to blocking forced entry attempts, to forcing two-factor authentication, among a plethora of other tactics designed to keep your site safe. The trick is choosing the best one and making sure it won’t conflict with any other functionality of your site.

Pretty daunting, right? Sure, there’s Google to help you take care of all that, but do you really want all that weight on your shoulders when you could be focusing on reaching your quarterly goals? Oh, and speaking of Google, they’re not always your friend! Now you have to also worry about Performance.


Google is hands down the largest and most popular Search Engine in the world. No argument there. The problem is that businesses are so dependent on getting the best positioning in search results that they have to abide by the ever changing rules that Google imposes (always claiming improved User Experience). A while back, thousands of information-based websites were negatively impacted by Google policy changes (Google gave these changes cute fuzzy animal names, perhaps in an attempt to soften the blow) and these people had to scramble to get back on their feet. Some never did.

Not satisfied, Google decided that sites should be mobile friendly, and then needed to be fast, and recently that sites should be encrypted. I’m not complaining – they’re all perfectly valid requirements when you look at it from a visitor’s perspective. But that also means that you, as a business owner, need to give much more attention to a tool (your website) than to your overall business.

Getting a site to be fast is not usually an easy task. There are many moving parts involved and getting all your ducks in a row can be quite frustrating. Remember the flat tyre analogy? Consider achieving and maintaining good performance as not only fixing the puncture but also balancing and aligning the wheels. And recapping the asphalt while you’re at it!

Professional Help

Taking care of a website shouldn’t be taken lightly. You’re better off hiring a professional who has that as their business so you can focus on your own.

We at UseStrict Consulting take pride in caring for our clients’ websites. With almost 20 years of experience developing websites, and over 5 years customizing and developing WordPress plugins, we know how to secure and optimize your site, and recover it when disaster strikes. It’s a scary world once you know all the dangers, but we’re there to help you through it.

Click here to learn more about our plans.

This post was originally written for TourismTribe.com by UseStrict Consulting.

Fix Hyphens in WordPress Media Titles

Minor WordPress version updates are fairly safe to apply. I had never seen a serious bug being introduced in a maintenance release – heck, that’s what the releases are for, right?

That is, until a friend reached out saying that all Media uploads that had spaces in their file names started getting hyphenated titles. Sure, she could manually fix the titles after the upload, but with image-intensive sites, that’s just not practical.

I did some digging and it turns out that this is a known bug introduced in WP v4.6.1. The fix is ready for WP 4.6.2, but as of this writing there is no date scheduled for that release.

There is, however, a workaround in the ticket, and I’m adding it here for your benefit. Just copy the code below and paste it at the end of your theme’s functions.php file. Make sure to paste it before any closing ?> tag. Actually, if your functions.php has a closing ?> tag at the end of the file, feel free to remove it. It’s bad practice to keep them lying around that way.

Kudos to @SergeyBiryukov for the fix.

function wp37989_fix_encoded_attachment_titles( $data ) 
    if ( empty( $_FILES ) ) 
        return $data;

    $file = current( $_FILES );
    $ext  = pathinfo( $file['name'], PATHINFO_EXTENSION );
    $name = wp_basename( $file['name'], ".$ext" );

    $data['post_title'] = sanitize_text_field( $name );

    return $data;
add_filter( 'wp_insert_attachment_data', 'wp37989_fix_encoded_attachment_titles' );

Remember to remove it after you install WordPress 4.6.2. It won’t break anything if you don’t, but it’s redundant and will just take up some un-necessary CPU cycles.



P.S. Check out our Website Care Services and let us help you keep your site up and running.

The Latest Rumors About WordPress Are Wrong

Calypso has been the hottest topic in the WordPress community over the past week, following this announcement from Matt Mullenweg. While many have praised the development as genius, and a long time in coming, others have been less generous in their comments. In fact, there are some rumors and ideas being fervently discussed in various WordPress groups that are flat out wrong.

It all stems from confusion about what Calypso really is, and how it’s changing WordPress and the future development of that platform. Developers who have invested incredible amounts of time to create themes and plugins that are based on the traditional WordPress platform are understandably concerned that all of that work, and the basis for their businesses, could be going up in smoke.

We’re going to review how WordPress works today, how Calypso changes the platform, and what that really means to developers and site owners alike.

The Players

To understand how WordPress works in the background, let’s think about what happens when you go to a fast food restaurant. You order a burger and a few moments later you’re walking to your table with a tray filled with food. Is it magic? Nope. Behind the scenes, several employees were working hard to get your burger assembled to the chain’s standards. In the same fashion, when you load a web page, several things go on behind the scenes until a few moments later you see the page you requested.

HTTP Requests

There are 2 main actors in play when you access a web page. The first one, considered the front end, is the browser. When you type in the URL or click a link, the browser calls the second actor – the web server – requesting that page. The server identifies the type of file being requested and reads it into memory. Depending on the type of file, it will execute a set of instructions and then spit out the result for the browser to display. Simple enough, right? But where do PHP, MySQL, and JavaScript come into play?

PHP is considered a server-side language. It’s just one of many, but like any server-side language, it has no say whatsoever in what the browser does. The same goes for MySQL, one of many database systems. The web server calls the PHP script, which in turn calls the database, before generating the HTML code that gets sent back to the browser. That’s pretty much all that the browser reads.

However, a basic HTML page is dull and isn’t very useful by today’s standards. So browsers also have the ability to style the HTML output using CSS (Cascading Style Sheets), as well as execute predefined instructions that it gets from JavaScript blocks or linked external files.

For example, here’s what the wordpress.org site looks like with- and without CSS styling.

WordPress.org Site with CSS WordPress.org Site without CSS


Bottom line – JavaScript is for browsers, PHP and MySQL are for servers (with the exception of Node.js which is a mini web-server that runs JavaScript in the back end. Calypso runs on a thin layer of Node.js to generate the initial page, but has not dropped PHP/MySQL altogether). More on this in a moment.


REST means Representational State Transfer. It is an architecture style that relies on regular HTTP requests from the front-end to the back-end. In short, it’s basically a one page load that calls several other mini page loads during the same run. Each mini call loads a piece of information.


WordPress is a Content Management System; system being the operative word. Its strength comes from the ability to extend it with plugins and themes. All WordPress plugins and themes are written in PHP and use MySQL to fetch and store data. In WordPress.com, the number of plugins and themes are limited and users do not have the power to install new ones – only to turn on those already vetted by WP.com. Self-hosted WordPress.org users have over 10,000 plugins to choose from, again, all of which are built in PHP/MySQL.

The Problem

Now, let’s get back to Calypso. I saw a slew of incorrect reports and conclusions because of this statement on Calypso’s home page:

“The new WordPress.com codebase, codenamed “Calypso,” moves WordPress.com away from MySQL and PHP. It’s built entirely in JavaScript, and communicates with WordPress.com only using our REST API.

This statement led people to believe that WordPress.com no longer uses any PHP and MySQL. If that were true, it would mean that either they broke hundreds of plugins and themes that relied on the database, or modified them all to work with the new technology. Neither are likely. Especially since they say they use REST API.

It’s also a very confusing statement. The new WordPress.com codebase communicates with itself using their REST API? If you’re running from inside a single codebase, there’s really no reason to make an external HTTP request to yourself.

The fact is that Calypso, WordPress.com’s new Admin Interface is mostly just that – an Interface – a Client Side interface. Using our fast food analogy, to suggest that WordPress.com would no longer use PHP/MySQL is like you asking yourself for a burger, not using any bread or meat, and still expecting to get a tray filled with the same exact food as a result.

The PHP server language, and the MySQL database structure, is still a very necessary element to WordPress’s ability to deliver filling content.

This has been confirmed by WordPress:

The old WordPress.com page (or any web page, for that matter) never had any PHP and MySQL to begin with – just a ton of HTML, CSS, and lots of JavaScript. Is Calypso better than the original admin interface? Sure, it looks better and runs faster, but the announcement had misleading statements that essentially blows it out of proportions.

WP.org and Security Concerns

Calypso is the new Admin interface for WordPress.com. It can, however, work for self-hosted WordPress sites. (We recommend self-hosted WordPress, where you can use the SBI! for WP plugin. If you’ve installed WordPress from cPanel or downloaded it directly from WordPress.org, you have self-hosted WordPress.) If you have Jetpack installed and its Manage module enabled, you can use the new Calypso admin interface. However, if you follow the basics of WordPress security, then you’ll find that it won’t work at all. This is because it relies on the XML-RPC API, which many WordPress professionals agree should be turned off at all times as it has been the target of extensive attacks. WordPress 4.4 will be releasing an improved REST API, and hopefully Calypso will adopt that for communicating with self-hosted WordPress sites.

Alternatives to Calypso

So, you saw that you can manage multiple sites with Calypso and you really want to be able to do that without putting your self-hosted site at risk by enabling XML-RPC? ManageWP, InfiniteWP, and WPDash, just to name a few, provide good alternatives.

WordPress User Impact

What does Calypso mean to the average self-hosted WordPress user? Absolutely nothing. Maybe in the future, but not now. So there’s no need for alarm or action. But you should be aware of it, because it may create some changes for self-hosted WordPress in the future. And we don’t want you to be caught off guard. Trust us to give you up-to-date, ACCURATE information, without hype.

This article was written by Vinny Alves for SiteSell and originally appeared in the SiteSell Blog and has been republished with permission.

How to move a WordPress site in 10 minutes or less

WordPress Hosting

I’ve had a VPS server at Rimuhosting.com for years to host UseStrict Consulting and other websites. I really enjoyed having root access and all the liberties that come with it. It was going really smoothly until I decided to try out Bitnami instead of the native PHP + Apache installs on my Ubuntu server – “if it ain’t broke…”, right?

But I did touch it and it did break. It turns out Bitnami has some php-fpm memory leaks that I couldn’t get around, and I figured I’d had enough of having to do sysadmin work for the time being. I decided I’d move to a managed hosting company where they’d take care of those issues for me. After some digging, I heard great things about SiteGround (yes, it’s an affiliate link – I like it so much that I endorse it) and decided to try it out.

After moving a few of my sites, I thought I’d share my experience on how to move a wordpress site. Yes, the title says it’s done in 10 minutes or less – I have it down to less than 5, honestly. It depends on how much practice you have, so your mileage may vary. 🙂

The rest of this article will assume that your new host give you access to cPanel and simple one-click WordPress installs. Let me know in the comments if you want the non-cPanel version and I’ll write it up.


Here are the ingredients you’ll need for a quick and easy move:

  1. SSH or SFTP Access to both old and new servers;
  2. cPanel access on the new server;
  3. Access to your domain’s DNS settings;
  4. Remember to replace all occurrences of foobar.com below with the domain you’re moving;

If you’re not familiar with SSH, you’ll be able to do everything using SFTP and other tools like phpMyAdmin, but I find SSH faster. If you’re stuck with a Windows computer, look into getting PuTTY installed. In my days of having to use Windows, I’d also always use Cygwin.

Move a WordPress Site

The first thing you need to do is make sure your new host is ready to receive your domain. Go to your cPanel Home and set up the domain you want to move. If it’s your account’s primary domain, that’s already done. If it’s a secondary domain, create it as an Addon Domain. Let’s assume it’s an addon domain.

Creating an Addon Domain

Click on the Addon Domain icon in the domains section of cPanel. You’ll be taken to a page with a form to set up the new domain.

cPanel Addon Domains Icon

cPanel Addon Domains Icon

Fill in the form with your new domain. The rest (except for the password fields) will automatically be filled in for you. Feel free to change the default values, but for the purpose of this tutorial, we won’t change anything.

Create an AddOn Domain

Create an AddOn Domain

Click ‘Add Domain’ and this part is done. Next, we set up WordPress on the new domain.

Setting up WordPress

Back in your cPanel home, look for and click on the WordPress autoinstaller. Yes, you can choose to install WP yourself, but then you probably wouldn’t need these steps at all. But I digress…

cPanel Autoinstallers

cPanel Autoinstallers

SiteGround uses Softaculous to install applications. Granted, I don’t have much experience with cPanel (I’ve always done stuff manually) so I don’t know if it’s something every host uses or not. When you click on the WordPress autoinstaller, you’re taken to the Overview screen in the installer page. I’ve done this a few times now, and for some reason I’m wired to look for an install button at the bottom of the page. It’s not there. Look for the blue install button right next to the Overview tab.

WordPress Install Button

WordPress Install Button

Once you click on the ‘Install’ button, you’re presented with some basic fields to fill in. As you’re moving your site from your old host here, you really care about the following only:

  • Protocol (whether it’s HTTP or HTTPS)
  • Domain (select the AddOn domain that you just created)
  • Directory (leave empty to install WordPress under /home/youraccount/www/foobar.com)
  • Language (select the language of your existing WP install)

Now, you’ll have to live with the fact that the database name and credentials will be different, so if you have any third-party connections to your existing WordPress install, make sure to change them later.

Click ‘Install’ and wait until the progress bar finishes. You’re now ready to receive your old WordPress.

Export Your Old WordPress

The main thing here is that you want to export a dump of your old WordPress database. I use the terminal via SSH whenever I can. If you don’t like to use a terminal and SSH, export it via phpMyAdmin.

This is what I’d typically do via the terminal (on the old server):

$ mysqldump -u <username> -p  <database> | gzip -c > old-wp-dump.sql.gz

Adding the password to the command line isn’t safe, so we leave it out and get prompted for it after we hit enter. Note that we’re also compressing on-the-fly.

Once you’re done with the database, make sure to create a tarball of your old wp-content directory as well.

$ cd /path/to/wordpress/install
$ tar -czvf old-wp-content.tar.gz wp-content/

Download both files to your computer (or leave them temporarily in a place where you can access them via a browser on your old server).

Import Into the New Server

Now we need to get those two files into the new server. I’m still using SSH, but you can use SFTP if you want to.

First thing to do is to back up your new server’s automatically-created wp-content directory (or rename it using SFTP):

$ mv /path/to/www/foobar.com/wp-content /path/to/www/foobar.com/wp-content.orig

Back up the automatically-created database. You can find the credentials in your new wp-config.php file.

$ mysqldump -u <new-username> -p <new-database> | gzip -c > new-wp-backup.dump.sql.gz

Now move the old server’s files to your new server. If you chose to leave them in a place accessible via a browser, you can use wget (if it’s available in your new host – it is on SiteGround) to download them directly to your server. Otherwise use SCP or SFTP to upload them from your computer.

We’ll need to uncompress the files soon. Unfortunately, SiteGround doesn’t have gunzip, but you can get around that with gzip -d (and even create an alias for it in your ~/.bashrc file – alias gunzip="gzip -d ")

It’s time to do the actual move. The following commands will read the compressed information and handle them accordingly. To import the database, use mysql:

$ gunzip -c old-wp-dump.sql.gz | mysql -u <new-username> -p <new-database>

Again you’ll be prompted for the password after hitting enter. All of the old tables will be created, replacing the new ones as long as you used the correct table prefix when you ran the autoinstaller.

Now uncompress your old wp-content:

$ mv old-wp-content.tar.gz /path/to/www/foobar.com/
$ gunzip -c old-wp-content.tar.gz | tar -xf -

Replace the Auth Keys and Salts

WordPress uses several Authentication Keys and Salts. In order to avoid issues logging into your new server’s install, you’ll have to replace the salts in the new wp-config.php with the ones from your old one.

The entry in wp-config.php typically looks like this:

 * Authentication Unique Keys and Salts.
 * Change these to different unique phrases!
 * You can generate these using the {@link https://api.wordpress.org/secret-key/1.1/salt/ WordPress.org secret-key service}
 * You can change these at any point in time to invalidate all existing cookies. This will force all users to have to log in again.
 * @since 2.6.0
define('AUTH_KEY',         ';LM|C1Op{p`aE>6 FTO64{n#J2c,5KDK6:UxO.OGjHp[`<d%Wj<Fxid-Y_3}#rIn');
define('SECURE_AUTH_KEY',  '6b*K_`ie.A7b2):A-0&|arFv]+b04hT2g93TTRUJHBfp>DL=vJ-a}A9Rh:POjGg@');
define('LOGGED_IN_KEY',    'Q8853bl6ZP-F>r(>wpJhbQu>M|Jt{b6zCcUwR3oyA/6+y<~l#-~,JA-WE.L{ht+@');
define('NONCE_KEY',        'GzVYsIDpbKi%4,xVODWZRE3w?}ez9He@p7wD>I=cM VF[u6AuQF20Cta)Hr9s<hh');
define('AUTH_SALT',        'FmSUv`pq2|%K}yb~r*e)+(,G1}:7I7;/TBxg>h_Ejm0HDD:Y^G&x,yf9t9IRD$3p');
define('SECURE_AUTH_SALT', 'C,QO;+Iu0xw&U}x7}+O_2PS#wn:&z?zh5:75Ys}b[emM2W@.0RT|;dgR+R<u8%[B');
define('LOGGED_IN_SALT',   'T_[R}qRiDS2Ye2z|V:A8?ogn,nU[}[+!wcD#W!X.2)ZC8n5*)sC*Y%Ks*&vo++eT');
define('NONCE_SALT',       '[lP_CFP70&i6l- )z(6Cw <o<0ZDG?sxJ&o&.t|m!xkX!z3$QLB.[dG9XRHE^ yd');

Test It

Your migration is now ready for testing. Pull up your new server’s IP address from your cPanel home and add it to your /etc/hosts file (C:\Windows\System32\Drivers\etc\hosts in Windows) foobar.com

Save the file and test your website. You should not see any difference at all when viewing it or logging in.

Once you’re satisfied, change the DNS A entry to point from the old IP to the new IP and that’s it! You’ve moved your website successfully. Allow for a couple of days of DNS propagation before taking your old one down.

As an added bonus, if you’re dealing with a high-traffic site that gets lots of database changes, you can set up Remote MySQL connections in cPanel, whitelisting your old server’s IP for incomming connections, and then change your old server’s wp-config.php to connect to your new server’s MySQL database. That way changes coming from people who still have a cached DNS entry pointing to the old server will be made on the new database automatically.

A Technical SBI! for WordPress Review

SBI! for WP

It’s no secret that I spend my days working for SiteSell. I joined the SiteSell developer team as a Perl programmer in 2010 to work on their SBI! product. This was shortly before starting to develop WordPress plugins during my free time.

SBI! is a suite of tools to help entrepreneurs build online businesses, regardless of the niche – from cat pictures, to everything asphalt, birthday cakes, costumes – you name it, I’ve seen it! And they’re all very happy campers. SBI! offers them the Action Guide (a huge online book containing steps to follow to get their business up and running), hosting, a site builder, and a ton of other support tools. Perhaps one of the most important is Brainstorm It! – a keyword tool that helps people find their niche and decide which keywords to use in their content, based on interest (monthly searches) and competition (number of sites using the keyword).

One thing SBI! wasn’t prepared to do, however, was help struggling WordPress users with their own sites. So I took it upon myself to try and convince management to address this problem, due to my love of WordPress and its plugin interface.

Fast forward a few years and I find myself as the lead developer for SiteSell’s WordPress division, working on SBI! for WP, an adaptation of the tried and tested SBI! product.

Mike Allton, Susanna Perkins, and myself made up a team tasked with using The Lean Start Up methodology to find out how to best supply SBI! tools to a WordPress audience. After several months talking to bloggers and infopreneurs, we came to the conclusion that adapting Brainstorm It! to work within WordPress would be the best way to get started. And so SBI! for WP was born.

Review of the SBI! for WordPress Initial Process

When a user signs up for SBI! for WP, they get access to a fully revised Action Guide (aka the AG), especially tailored for WordPress users – from choosing hosting to how to select the best plugins . The AG was structured as an online course for ease of use, with completion progress and even a points system.

Once the user is familiar with the steps he needs to take, he can go to the Brainstorm It! tool (on SiteSell’s servers) to set up his niche and Master Keyword List  (the MKL) – a list of up to 5000 keywords related to the business, along with the numbers for interest, competition, and potential.

Review of the SBI! for WP Technical Background

The next step is to download and install the SBI! for WP plugin on their own site (my pride and joy). It’s hard not to get too technical, but this is a technical site so bear with me. I used the MVC Starter Plugin for WordPress (by yours truly), so the code is clean and concise, neatly separated into Models, Views, and Controllers. Communication with SiteSell’s servers is done via back-end API calls, and only when absolutely necessary.

For performance purposes, and as this is purely an Admin tool, it doesn’t even get instantiated on the front end. Once the user installs it, they receive a Welcome admin pointer with the option to take a tour of the settings. When the user connects to SiteSell’s servers, their MKL is downloaded to their site so that they have quick access to the keywords while writing posts or pages (or whatever other Custom Post Type they choose to use the keywords on).

If they want to use a keyword that is not in their MKL, they have the option to add it from the WordPress admin, and both systems are kept in sync. For larger systems that have multiple roles creating/editing content, the admin can choose which roles will have access to the keywords.

When using the keywords in the Edit Post/Page screen, the user also has access to Competitive Insights – a list of sites that use the selected keyword, offering opportunity to reach out and make partnerships. We also keep track of all posts and pages using that keyword within the user’s site.

All in all, SBI! for WP is an awesome service/plugin and I’m tremendously proud to be a part of it!

How to Identify Good WordPress Plugins in 4 Easy Steps

How to Identify Good WordPress Plugins in 4 Easy Steps

Over the past few months I’ve been working with Mike Allton and Susanna Perkins on a project that will try to give info-preneurs using WordPress an edge on creating content for their audience. On one of the less busy days, I wrote the post below detailing how I choose plugins for my clients.


How to Identify Good WordPress Plugins in 4 Easy Steps


So you’ve finally decided what the focus of your website should be and are ready to set up your WordPress install. You now need to select your theme and a series of plugins to build upon the core functionality you get from WordPress out of the box. With thousands of options to choose from, getting a plugin or theme that will not blow up and bring your site down is a challenge.

There are a few steps you can follow to ensure you have good quality WordPress Plugins for your site. Even if you aren’t a developer and can’t understand a single line of code, using these guidelines as a rule of thumb will give you some level of security.

These are the steps I take when helping my clients decide whether to adopt a plugin or not.

1. Check What Others Have To Say

With close to 40,000 plugins at the time of this writing, WordPress.org offers the ability for users to rate plugins. In the early days, it was possible to select the number of stars for a plugin without commenting on it. To make things fair for authors, people now have to state why they are casting their votes and the authors have the chance to defend themselves, if needed. Plugins with too many low-star ratings should raise a red flag, as long as the comments actually make sense. Be careful of detractors that are only out to troll authors without actually trying to provide constructive criticism.

2. Authors Should Provide (Fast) Support

WordPress.org also offers support forums where users can ask authors for help. Some authors choose to provide support on their own sites. Personally, I think this is valid for paid plugins, but free plugins support should be kept where the free plugins are downloaded. Look for how many resolved topics there are in the recent past, and the time it takes for authors to reply. Authors get notified of new topics immediately, and should have a good reason to not reply within a reasonable time frame.

3. Plugins/Themes Should Be Updated Frequently

Let me take a poetic license here… Code is a Living Entity. There’s seldom such a thing as writing a plugin and never touching it again. It is virtually impossible for any piece of code to not need updates from time to time. With the wide variety of environments out there, there’s bound to be a scenario where a bug patch is needed. Also, WordPress.org is always releasing new updates to the core, and plugins and themes need to keep up. The plugin page will tell you when it was last updated, and up to which version of WordPress it has been tested with.

4. Check For Coding Best Practices

Granted, this part is a bit harder to do if you are not a developer. There are, however, a few things you can look for to identify a well written piece of software. You can find the source code in the “Developers” section of the plugin page in WordPress.org.

Code is like a house – Keep it clean or it’ll become full of bugs. Proper spacing and indentation helps developers to easily understand what each part of the code does, as well as the intention of the previous developer when writing that piece. Another thing that helps understand code is commenting. If you look at the core WordPress files, you’ll see that they went to great lengths to properly document what each piece should do. No author remembers EVERYTHING they had in mind when writing code. If they say they do, run away – they’re either lying or they’re dangerously smart and might try to take over the world.

Object Oriented code is a Good Thing– Gone are the days when people could write code without structure. If you see words like class, static, public, private, protected, or extends, it is quite likely that the developer knew what s/he was doing. For the simpler plugins, this might be overkill as it usually comes hand-in-hand with more files and folders and it might be like killing a fly with a shotgun, but the danger of PHP is that it is so easy to use that it becomes easy to write BAD code.

Closing PHP tags are tricky – PHP comes with open and close tags, <?php and ?> respectively. Any white space after a close tag will be rendered by the web server, many times prematurely. If you see errors such as ‘headers already sent’, the culprit is likely to be white space after a closing PHP tag. Using closing tags at the end of a PHP file is not only unnecessary, but frowned upon. It’s better to see a comment indicating the end of file, than an actual closing tag.

Code should be tested – There are several techniques to test software. WordPress comes with a suite of test files that run via phpunit, a robust PHP testing tool. Plugins and themes should be tested, too. Look for a directory called ‘test’, or simply ‘t’ containing at least one PHP file.


Even if you follow all of these steps to the letter, you might still come across a bug. However, it is much less likely to happen and, if it does, you should be able to get fast support from the author. After all, you did follow step 2, right?

Important Changes to USC Plugin Sales and Support

When I started selling WordPress plugins at UseStrict Consulting, I planned to provide life-time updates and free support for all. As it turns out, there are a few fundamental flaws with this business model:

  1. There’s no control over unauthorized copies;
  2. Providing free support takes time away from coding new and exciting things;
  3. There is no business growth;

Over the following weeks, I will be implementing a plugin licensing system, and support will be provided to subscribers only. I believe this will be a win-win situation, as I will be able to provide (even) faster support and better plugins.

I’m still studying how to handle old clients, and will post updates as soon as I have more information.