Twitter seems to have lit up today with complaints of web hosting downtime. I sympathize but am happy to say that none of my sites went down today. Why? Because I migrated from BlueHost.
Is it that easy?
To be perfectly honest, switching from your cPanel host (HostGator, BlueHost, etc.) can be a real pain especially if your host is also managing email for you. The cost of migrating can also be pretty daunting and can skyrocket if you move email to a service like Google Apps (which charges $10 per account).
So you have chosen to migrate away from your cPanel host but are unsure what direction to go, let me shed some light. Hosts that offer cPanel or other all-in-one solutions to email and web-hosting (looking at you GoDaddy) can offer a great feature set at a reasonable price, a one stop shop for email, hosting, domain purchasing, certificates, you name it! The consequences, however, of these bloated systems can really have disastrous consequences as your site grows. You can experience pretty serious performance issues, and like we are seeing today, even extended downtime that not only affects your website but also your email! For the growing blog or small business, this can really be a blow to your reputation.
My solution here will probably end up costing you a little more, but will be well worth it as you start experiencing the speed and reliability.
I recently used the built in WordPress protected visibility status in a project where information security was very important. This handy and little used feature does a great job securing content and providing user access on a basic level but has some pretty serious security holes if you hope to use it for anything more advanced. These include:
- The identification cookie is stored in the users browser insecurely
- The identification cookie is stored for 10 days without requiring the user to re-enter the password
- Only the post content is protected, any additional meta on the page will be visible to unauthenticated users
This is a quick post today. I had been struggling for a while with strict warnings popping up all over my projects since I upgraded my Vagrant box to PHP 5.4. Your initial reaction might be to fix the strict warnings, and you would be right except when you can’t.
It seems that a lot of very popular plugins and even WordPress core throw strict errors. The temptation then is to turn off WP_Debug to avoid scrolling through a long list of errors that you can’t fix anyway.
Before you do that, let me introduce you to a better way. Read more
Workflows with Git from Tanner M
I am neither a command line wiz or a git expert, but learning a few commands in the terminal and learning the basics of Git has changed my workflow forever!
Here is the scenario that I’ve run into more times than I care to count. While working on a new feature for a project you find it necessary to submit a patch that conflicts with the files you are modifying for the new feature. What is the solution? In the past, this meant undoing all the progress on the new feature request so that nothing is accidentally deployed, writing the patch, deploying, and then try to paste in or rewrite all of the work you just undid. This is uncool and very inefficient.
Or how about this: your client requests a new feature that spans several files, but once it is completed decides that the site audience is not ready for it. Now what do you do? There are more features that need to be developed but how do you continue on without trashing the feature that is now on hold?
Let me introduce you to a better way.