While I was experimenting with a client solution, I had a lot of considerations to take in account for a scale-able solution that allows for easy content management for client “web presence” needs. Since my old hosting provider has never been keen on the idea of allowing me elevated privileged for the shared hosting package I purchased at a discount for a 3 year term, I’d been kicking around the idea of migrating to a new hosting provider that would allow me to play with newer front-end Frameworks that use Node.js, and keep my process and memory intensive WordPress sites to a separate host.
I have almost always preferred a “use the less resource intensive options” approach. It’s served me well, for the most part. But now that you can get 20GB of data stored on a Solid State Drive (SSD) with your pick of OS installation, 1 TERABYTE of Monthly Bandwidth Transfer, 512MB RAM, 99.8+% Uptime, & more, all hosted remotely for $5 a month, I’ve changed the way I look at it (but only a little).
When I self-hosted all my client content in the early 2000’s the amount of bandwidth that I needed to support my growth was constantly capped out. When I wasn’t using my server clusters bandwidth for a few days, I noticed I was getting even MORE traffic to my sites. It was kind of revelation of how important resource management is for a server. My in-house server hardware is VASTLY superior to what I have been paying for on the remotely hosted solution, but these days… the bandwidth and reliability of a remote host provider are what I prefer to consider. I still use my own in-house machines for staging and development, but if you want to be a real “brand”, you’re going to have to cough up the $5 a month or more to have a “true production environment” for your final product. There’s nothing more embarrassing than trying to show a finished product to a client and having your server hiccup because of a power-flicker, automatic server updates that reboot, internet service provider issues, Apache/nginx crashes or countless other situations.
A few colleagues of mine turned me on to DigitalOcean (DO) during a discussion about the costs and disadvantages of self-hosting your own projects from a home office. After seeing the packages and billing structure, it became obvious that I was going to be much better off with the options to scale different projects than try to work around the limited access of a share host, and also have my choice of custom configurations.
I used to say that I am more of a fan of CentOS than Ubuntu, but as a Linux Distribution, the Ubuntu Community is VERY strong, and the applications I wanted to leverage from my experimental Virtual Machine (VM) Installations have mostly favored Ubuntu over CentOS & Red Hat. With DigitalOcean, however, I can have 10 or more “Droplets” that are the equivalent to a Remotely Hosting Virtual Machine at a trivial cost than what it was 15 years ago. There are dozens of Operating System (OS) distributions and pre-configured solutions available to select from during the creation of your Droplets (Check out the MEAN Stack! VERY COOL!). Having the ability to spin up a new VM was a VERY nice bonus to the DO account infrastructure. This means that even if I wanted to use multiple Operating Systems for different projects, I could pay just $5 a month for the most basic package. Even this basic package was actually FAR more generous in resources than my previous hosting solution. It was even slightly less expensive, though at the sacrifice of the slightly less storage pace and the familiar CPanel Dashboard for domain management.
UPDATE: I have since branched out and also started using Linode in addition to DigitalOcean for certain projects that need more “power” on a budget, without all the frills of DigitalOcean. Linode offers more “server juice” at a lower price, but doesn’t include things like backups and snapshots (they cost extra). Still, its a great value for those savvy enough to manage their own data and patient enough to navigate through the clunky Linode UI.
Managing Your TLD Domains From a Control Panel
While I do think CPanel is “the best” domain management tool on the market (and written in Perl!), it is NOT free to use. The benefits of having a less developed and Open Source product are usually found in cost savings, flexibility (with the right skills applied), and DRASTIC performance benefits after you demo a few applications find what suits your needs. This typically means if you know what language the CPanel alternatives are code with, this provides an opportunity to learn about the Web Hosting Control Panel product industry, and its pivotal features. Even so, you ultimately trade the time it would take for changing the layers of system configurations in CPanel, with debugging and changes to code or databases. I have found that I prefer not to “Hack” through a hardened infrastructure to create custom features and functionality for myself or my clients though. Having root-level access with a DigitalOcean Droplet gives the ability to manipulate New Linux Users & Groups, SSH Keys, FTP settings, File Permissions, you name it. Until I have a greater client base with the technical knowledge that generates the need for such a powerful and robust Web Hosting Control Panel, I prefer to use something Open Source.
Such As… Easy Host Control Panel (EHCP):
There are at least a dozen Open Source Web Hosting Control Panel products available, but what I like about EHCP, is its not shy on new feature development. It is still VERY ugly, in terms of the default themes that are provided in the default installation, but all the functionality is there. It does have it’s quirks, and it will take some knowledge about how to fix certain bugs with some installations, but with PHP & MySQL skills, you could very easily create your own theme and give it a look and feel that makes the most sense to you and your usage and the Open Source Community will love you for it if you make it available in a Pull Request or Fork!
Speaking of Forks… There is a greatly enhanced EHCP-Forked version that I decided to try out when I upgraded to Ubuntu 14 on a test VM.
EHCP Force Edition:
The enhancements in the EHCP Force Edition (Force) are vast, and the installation process for getting everything working together on an Ubuntu 14 install was MUCH easier than the the “EHCP Vanilla” version. I ran into some issues with a Force installation on Ubuntu 15, but the version upgrading process that is posted prominent on the main web site for EHCP Force is also MUCH nicer and simplified (even though it requires use of SVN, instead Git). If you are starting from a Clean Ubuntu Installation, the EHCP Installer will go through the setup steps for things like Database, FTP, Email and DNS. It has worked very well for the most part, but there have been some tweaks and fixes related to symlinks and *.conf files for MySQL and FTP I had to sort out.
EHCP is definitely not for the faint of heart when it comes to Linux System Administration, but it performs very well and provides me with the options to make the configuration changes I typically use in a very “You know what you are doing. Go on with your bad self!” kind of way. It gives me the tools I wish I had at my day job, instead of being handcuffed by the more commercial solutions! CPanel seems to often assume you only need to do things like adding new domain names or adding / removing email address every once in awhile. I LOVE that I can migrate a client to a new domain name in a matter of hours rather weeks of migrating, testing, tweaking & freaking the configurations of your environment..
UPDATE: While there are many reasons to stick with using EHCP or EHCP Force Edition, many people might find that WebMin fits their needs in a more “lightweight” software suite and domain management UI. WebMin is a terrific tool for customizing each individual component of your domain management tools, though the learning curve is roughly the same for how to add, remove and edit packages and configuration edits for your hosting servers and tools.
Everybody Knows About WordPress:
“Why WordPress? Don’t you know how to write code?”
WordPress can be very bloated and cumbersome. I completely agree with most of what the WordPress-haters have to say about its infrastructure and the lack of coding skills that many of its user base has. It can be challenging to implement something from the VAST library of jQuery plugins, or display custom data from an external source in a consistent way. This is similar to problems that most application developers run into when inheriting a fully functional and mature codebase. Things work… but in the specific WAY they work. If you start doing things like trying to add a custom login panel, or showing a slick data table of important information in WordPress, you might feel like chucking it out the window and building your own custom content management system solution.
I have done that myself in the past with WordPress…
Twice. (Ok, maybe more than twice.)
But here is the nice thing about WordPress: It’s Open Source, incredibly well documented, and extraordinarily robust. I do find it to be a royal pain to make edits to a theme or create your own custom theme templates and plugin modifications, but rather than just hacking away on something you made in your own little silo, you can add features, skins and functionality that is custom to your application and someone else may find that feature useful and help you enhance it so they can use it too. With WordPress, you are the part of something bigger. Sure, it’s awesome to build something all your own. But if you think about it… You didn’t write jQuery.js, Angular.js, Ember.js, Backbone.js, or the PHP, Java, Python, Perl or Ruby source code either. 😉
When I have a client that wants something “special” and “not cookie cutter”, I usually develop something based off my past experiences with developing custom content management systems. But 95% of the people or small businesses that I deal with just want a web presence. They want something that they can add, edit and update content on their own with. WordPress is perfect for that.
If the client is more of a “just do everything for me, but give me these specific features” mindset (and with much deeper pockets), I break out the custom work. So I feel like it is important for a web services provider to have a WordPress solution locked and loaded. I like to use WordPress as an “incubator”, and grow into something else.
Having the WordPress installation ready to go, either means spinning a handful of “Single Site” WordPress installations, or…
Leveraging WordPress Multisite:
What is WordPress Multisite? Aside from the oodles of info you can search for with your favorite search engine, here is my synopsis: It’s a way of managing multiple WordPress sites in one convenient dashboard that can share customization, themes and plugins between multiple web sites.
Websites aren’t necessary not separate “domain names”. There are a few really convuluted and hokey ways to serve up different content from your server using the “default” sittings in a WordPress Mutlisite installation that are redirected from sub domains like http://wordpress.justinmerrill.com or from a directory like http://justinmerrill.com/wordpress. But there is a free and fantastic plugin that handles the mapping of domain names VERY well (albeit, not always perfectly).
To configure a WordPress Network (aka Multisite), you will need to edit the wp-config.php file of your WP installation with the following line:
/* Multisite */
define( 'WP_ALLOW_MULTISITE', true );
Add this line above where it says /* That’s all, stop editing! Happy blogging. */. If it doesn’t say that anywhere, then add the line somewhere above the first line that begins with require or include:
For more in-depth information about how all this works, you can visit the WordPress Codex page directly at: https://codex.wordpress.org/Create_A_Network as there is a chance things could change in later releases of WordPress.
Information for the plug-in you need to correctly associate your own purchased top level domain names to a particular site that you have created can be found at: http://ocaoimh.ie/wordpress-mu-domain-mapping/
You can download the above plug-in here: https://wordpress.org/plugins/wordpress-mu-domain-mapping/
There ARE more instructions, this is not just as simply as Network activating the plug-in. BUT you DO need to activate the plug-in! So do that now.
Next, you will need to move the sunrise.php file from the plug-in files directory to the “[webRoot]/wp-content/” of the WordPress installation that you are working with.
The following are the instructructions that you can find directly on the plug-in page. I’m totally ripping them off and placing them here for your convenience:
- Install the plugin in the usual way into the regular WordPress plugins folder. Network activate the plugin.
- Move sunrise.php into wp-content/. If there is a sunrise.php there already, you’ll just have to merge them as best you can.
- Edit wp-config.php and uncomment or add the SUNRISE definition line. If it does not exist please ensure it’s on the line above the last “require_once” command.
define( ‘SUNRISE’, ‘on’ );
- As a “super admin”, visit Super Admin->Domain Mapping to create the domain mapping database table and set the server IP address or a domain to point CNAME records at.
- Make sure the default Apache virtual host points at your WordPress MU site or WordPress 3.0+ network so it will handle unknown domains correctly. On some hosts you may be required to get a dedicated IP address. A quick check: in a web broswer, type in the IP address of your install. If you are using CPanel, use the Park a Domain menu to set the mapped domain to your main installtion.
- Do not define COOKIE_DOMAIN in your wp-config.php as it conflicts with logins on your mapped domains.
That’s really all there is to getting your very own “free” custom server setup going for WordPress. The longest part of the setup is EHCP Force Edition. There are quiet a few changes happening with development of this Open Source Control Panel so installation instructions in this page should be considered “flexible”. Though, given the comparison between EHCP “original” versus EHCP “Force Edition”, I certainly recommend going with Force Edition. The developers of EHCP Force Edition seem to be leading the way in that “vanilla” EHCP incorporates features and ideas after they have already been implemented in the Force Edition version releases.
If I get some solid feedback on this article, I will likely add more details all the really cool stuff EHCP can do. The content here is just enough to get you started out and able to get your server put together in a way that can get your websites off the ground. The BEST reason I’ve found to use EHCP rather than piecing everything together on your own is the “adequate” management of email addresses and multiple webmail interfaces. I REALLY wish they would include Horde email management to the list, but SquirrelMail does give your users a method to check emails through a web interface, which is pretty cool.
Give me some feedback, let me know what you think and what you’d like to know more about!