Over the years, I've told people that CMS Report is a side business. While I would never become rich from this blog, I've been lucky enough to have been able to put a little extra cash in my wallet from this website's ad revenue. In truth, what has actually sustained CMS Report is not money but my passion for information systems. I absolutely love this magical process where people, hardware, software, and infrastructure come together to improve the business or organization. A decade ago, I could find no better example of information systems in the real world than the content management system. I decided to write about CMSs and created a blog and website to host those articles. After spending ten years as this site's founder, editor, and primary writer I've decided it is time for me to move on to some new challenges.
What an amazing and crazy ride this has been for someone that started his career as a meteorologist and now works full time in government IT. This was supposed to be a one year exercise for feeding my hunger to learn more about CMSs. Instead, this became a ten year project that tapped into a community of developers, marketers, analysts, founders, executives, small business owners, and entrepreneurs. It has been a joy to have met so many creative, smart, and hardworking people through this website. I received more than I gave. But in the past few years, my passion to write only about CMS topics has diminished and I'm not happy that my articles lack the shine they once had. After considerable thought, I've decided it's time for me to pass the torch to another.
When it comes to content management systems, these two questions are the ones that I get asked the most:
- What is the best CMS out there?
- What features do I need to have in my CMS?
Over the years, I've tried answering that question in various forums. But inevitably my initial answers to the first question are almost always:
- It depends on what you want to do.
- It depend on who you're willing to work with.
This leaves us with the second question. What features do you need to have in a CMS? The honest answer is I won't know until I better understand your business goals and current workflow. But I can tell you with a straight face what is the most important feature your new CMS needs to have:
- The ability to export your content easily out of your "new" CMS.
Too often, people worry only about importing their content into a new CMS from their old CMS. But what if in a year or two you find your new CMS fails to meet your needs? Before adopting a new CMS, you should have a clear exit stategy for the day your new CMS becomes your old CMS.
With some CMSs, the process to leave from one platform to another is an easy one. We just did an Agility CMS to Drupal migration where Agility's software provided easy access to their export functionality. This didn't surprise me because three years ago I researched Agility well and confirmed they had export functionality readily available. Unfortunately, too many CMSs are not like Agility. CMS vendors don't always provide an easy method to leave their CMS and sometimes this is intentional (it's called vendor lock). Website migrations even in the best of circumstances are already difficult and you definitely don't want a CMS where exporting content is made difficult by design.
At the 2013 CMS Expo Learning & Business Conference I have the privilege of moderating a panel focused on the Cloud. That's actually a broad topic, but I think it's a topic that is increasingly becoming well understood by the CMS community. Last year, I moderated a similar panel and, in my opinion, we spent way too much time trying to define the Cloud. This year, I'm hoping we're past the "what is it" phase and spend much more time talking about real problems, real benefits, and the challenges the content management industry may be facing by moving toward a Cloud solution.
Over the past few years we've seen the Cloud, like any new technology, move from hype to business reality. We're no longer asking how the cloud is defined. Instead we're asking, is the cloud for my business? We're also asking, how do I get there? This panel will look at how best to transition a business, organization, and development team to the cloud. Better yet, this panel is geared toward helping the audience better prepare for the challenges they will be facing once you are there.
I say this with confidence that these type of questions and discussion will be provided in the panel session because of the industry leaders that will be on this panel. I'm very fortunate as a moderator to have the following people joining the panel:
It was five years ago that I posted in programmer tradition at CMS Report, "hello world". At the time, I expected CMSReport.com to be around for only a couple years which was more than enough time for it to fulfill my purpose. At the time, I had an academic interest in information systems and found that Web-based content management systems were a nice way to put theoretical ideas into practical know-how. This site focused on content management systems in hopes of meeting the few other people out there that shared my interests in CMS.
In that first post, I actually wrote more than "hello world". The full title of the article was "Hello World, New Version". The phrase "new version" was in reference to CMSReport.com not being the first site I created to focus on the CMS. A couple years earlier, I had tried to start up a website called WebCMS Forum. The online forum was intended to be a "place for those with a passion for web-based applications such as portals, blogs, and forums". I spent a lot of time and money on that site, but in the end few visitors joined in as members to talk about content management systems with me. If Twitter had existed back then I would have easily tweeted "WebCMS Forum RIP #failed".
Looking back at it now, I'm convinced CMS Report is a success because of my experience from failing so miserably with WebCMS Forum. Previously, I had tried to build a site for others to express their passion and obsession for their favorite content management systems. Here at CMSReport.com, I took the opposite approach and built the site for the sole purpose to talk about my passion for content management systems. It was a crazy idea to put my opinions at the center of CMS discussions as even now I do not consider myself an expert in content management systems. It was only by circumstance that I later realized people are attracted to other passionate people that ask questions and are willing to go at great lengths to find the answers. If you're looking for the facts you go to Wikipedia but if you're also looking for great discussion from people asking the same questions as you are; it is the blogs you seek.
Last week was a very frustrating time for me. For whatever reason, an unusually number of botnets decided to zero in on my Drupal site and created what I call an unintentional Denial of Service attack (DOS). The attack was actually from spambots looking looking for script vulnerabilities found mainly in older versions of e107 and WordPress. Since the target of these spambots were non-Drupal pages, my Drupal site responded by delivering an unusually large number of "page not found" and "access denied" error pages. Eventually, these requests from a multitude of IPs were too many for my server to handle and for all intents and purposes the botnet attack caused a distributed denial of service that prevented me and my users from accessing the site.
These type of attacks on Drupal sites and numerous other content management systems are nothing new. However, my search at Drupal.org as well as Google didn't really find a solution that completely addressed my problem. Trying to prevent a DDoS attack isn't easy to begin with and at first the answers alluded me.
I originally looked at Drupal for the solution to my problems. While I've used Mollom for months, Mollom is designed to fight off comment spam while the bots attacking my sight were looking for script vulnerabilities that didn't exist. So with Mollom being the wrong tool to fight off this kind of attack, I decided to take a look at the Drupal contributed model Bad Behavior. Bad Behavior is a set of PHP scripts which prevents spambots from accessing your site by analyzing their actual HTTP requests and comparing them to profiles from known spambots then blocks such access and logs their attempts. I actually installed an "unofficial" version of the Bad Behavior module which packages the Bad Behavior 2.1 scripts and utilizes services from Project Honey Pot.
As I had already suspected, looking for Drupal to solve this botnet attack wasn't the answer. Pretty much all Bad Behavior did for me was to take the time Drupal was spending delivering "page not found" error pages and use it to deliver "access denied" error pages. My Drupal site is likely safer with the Bad Behavior module installed, but it was the wrong tool to help me reduce the botnets from overtaxing Drupal running on my server. Ideally, you would like to prevent the attacks ever reaching your server by taking a look at such things as the firewall, router, and switches. However, since I didn't have access to the hardware, I decided it was time to look at my Apache configuration.
We lasted nine months. That's right, for nine months we hosted our Drupal site with a shared hosting account. Last January, I knew we were taking a gamble but the monthly cost savings for hosting the site was just too tempting. In this end though, CMS Report was too busy and exceeded the shared hosting provider's CPU usage policy.
So, during the past few days I've been busy moving the site onto a Virtual Private/Dedicated Server. This time, I'm going with GoDaddy but as far as self-managed VPS/VDS goes there are a lot of good companies you can go with. Although I can do Web server administration in my sleep, I think I'm going to miss having someone else doing the server management for me. I know there are better hosting options for professional Drupal sites but I don't think I'm in need for a high-end hosting plan for this amateur site of mine.
One of the common mistakes website owners make is not recognizing the growth of their site. We all try to do things as cheap as possible and often fail to recognize the increasing size of our content management system or the increasing popularity of our site. In the Fall of 2007 I made this mistake. The hosting provider locked access to my site and I spent a stressful week getting my database from the hosting company and placed onto a new server.
I have never had good luck hosting my Drupal sites on shared hosting plans. My last venture into budget hosting was a disaster with the hosting company locking me out of my own account due to too many requests to the remote database. The truth is that I've only been happy with running my personal Drupal sites on virtual private servers (VPS). However, I'm having a difficult time justifying my yearly costs of using a VPS to host my sites.
The problem is that I'm finally realizing one of the goals I set for 2007, a resolution to reduce my workload outside of work. Specifically, I've spent the last year getting rid of most of my freelance work not related to my day job or CMS Report. So now that I have less sites to host it has become less cost effective to run my remaining Drupal sites on the VPS. With my yearly VPS contract up this month, I decided to give cheaper shared hosting another chance.
A couple weeks ago, I moved CMSReport.com over to AN Hosting. My choice of using AN Hosting for CMS Report is solely based on John Forsythe's recommendation that AN Hosting provides a reliable Drupal hosting service. CMS Report has only been on AN Hosting's plan for a couple weeks and so far the site seems to be running fine. I am a little concerned during peak traffic hours my Drupal site may be to much for this shared hosting plan, but I'm hopeful that everything will be fine. One of my posts last week attracted quite a bit of attention and yet everything appears to be running smoothly.
Ironic how the world can change so quickly. Yesterday, the CIO of my organization began enforcing the use of anti-virus software on all of our Linux clients and servers. Today, I read that Apple is telling its Mac users to purchase anti-virus software. Something nasty is brewing out there.
Apple encourages the widespread use of multiple antivirus utilities so that virus programmers have more than one application to circumvent, thus making the whole virus writing process more difficult.
Yesterday, I upgraded the PHP version on my server from 5.2.4 to 5.2.5. PHP 5.2.5 brings improved "stability of the PHP 5.2.x branch with over 60 bug fixes, several of which are security related". I also reintroduced eAccelerator back onto the server. I stopped using eAccelerator last spring, not so much because I had any real issues with it, but because I spent the summer months hosting my sites on the cheap.
This time, when I compiled the new version of PHP 5.2 onto my server, I also made the decision to not load the latest version of PHP 4. Although most of the Web applications I run on the server are PHP 5 compatible, I've always made sure I also had access to a version of PHP 4. The time has finally come though where I really don't have a need or desire to host a content management system that is only PHP 4 compatible.
If your CMS is not compatible with PHP 5, I think this is the time you should begin to start asking why it isn't compatible with the latest version of PHP. Not only is there a lot of community effort going on through GoPHP5 to get hosting services to provide PHP 5 on their Web servers, PHP 4's days are coming to a close. At the end of this year (2007), the PHP development team will no longer be supporting new releases of PHP 4.4. By August 2008, no critical security fixes will be provided for PHP 4. It just makes sense to me that this is the ideal moment of opportunity to start moving your Web applications off of PHP 4 only servers.
During the past couple years I have recommended to people that they host their Drupal sites on a virtual private server (VPS) instead of a shared hosting plan. While a large number of people do not have problems running Drupal under shared hosting plans, I have always felt that there are less headaches with using a VPS to host your sites. For example, with a VPS I don't have to worry whether the shared hosting plan gives me the necessary MySQL privileges needed by Drupal (especially CREATE TEMPORARY TABLES and LOCK TABLES). From time to time, you also hear from people with "Drupal friendly" shared hosting plans eventually find that their hosting company isn't so friendly toward their Drupal site. Planet Drupal contributor, Clancy Ratliff, is one of the most recent examples for having a host provider not really happy she is using Drupal. So I often ask myself, is shared hosting for Drupal really worth the trouble?
I don't know if shared hosting is worth the trouble but a chain of events have brought me to giving shared hosting another chance for my Drupal sites. Last month, I pushed my VPS so close to the bleeding edge that it became unstable. While I was able to get my sites back online, the downtime clearly told me it was time to move my sites to a new server. While most visitors observed a performance improvement for my Drupal sites since the server migration, it's only now that I'm letting the cat out of the bag. For the past week, CMSReport.com has been under a shared hosting plan and not a VPS. I'm currently running my site using a budget shared hosting plan through my reseller site which is comparable to the hosting plans offered by GoDaddy.
I don't know how long I'll keep my site on a shared hosting plan but I am currently enjoying a break from the work, worry, and experimentation that comes with administration of a VPS. While I may go back to a VPS, I thought it would benefit some newbies and other Drupal users my experiences and thoughts on migrating my sites from a VPS back to a shared hosting plan.