I have ran this website of mine on Drupal since 2005 starting with Drupal 4.6. This past week I upgraded bryanruby.com from Drupal 9 to Drupal 10. This being a Drupal upgrade, I'm happy to report the experience was an average event for me. After installing countless versions of Drupal over the years since then, the upgrades have not always gone well.
Effective immediately, CMS Report has been shutdown with socPub designated as the website's full replacement.
Two months ago, I introduced CMS Report "Lite" as a slimmed-down version of the original website. Since our rebranding from CMS Report to socPub earlier this year, a number of content management professionals expressed the need to cite reputable CMSReport.com for their information and were uncomfortable with referencing an "unknown" website like socPub. With limited success since bringing this nostalgic website back online, I decided this it was time to: let the past go; redirect all remaining traffic from CMSReport.com to SocPub.com; and to shutdown the website for good.
Your hosting account was found to be causing an overload of MySQL resources. What can you do? Upgrade your Drupal 8 website to Drupal 8.4 or higher.
One of my goals in rebranding my website from CMS Report to socPub was to write diverse articles beyond the topic of content management systems. Yet, here we go again with another CMS related article. The Drupal open source project recently made available Drupal 8.4 and for me this version has been a long time coming as it addresses some long standing frustrations I've had with Drupal 8 from the perspective of a site administrator. While Drupal 8.4 adds some nice new features, I'm just as excited about the bug fixes and performance improvements delivered in this new version of Drupal.
Earlier this year I rebranded the website CMS Report to this site, socPub. The website's new identity has allowed me, article contributors, and our readers to explore topics well outside the norm of conversations surrounding content management systems. Although we're going through a bit of growing pains with establishing a new identity under socPub, I'm fully committed to this new website. The change has been good for me and I'm once again inspired to write on topics that interest me.
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.
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:
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.
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.