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.
While I had hopes that mirroring the content would be a win-win for both website...the analytics showed otherwise. I was prepared to see a decrease of visitors at one website in favor of another but in reality most of my intended audience targeting North America, Europe, and Australia continued to view content their content at socPub. CMS Report on the other hand attracted less than 12% of my targeted audience with instead 85% of the audience coming from India in the form of bots trying to look for weaknesses in my content management system.
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.
When Drupal 8 was introduced it made significant improvements in how it caches and renders pages. That's great news for websites that use Drupal's built-in caching to speed up delivery of pages or page elements. But there was one unwanted side effect to the cache enhancements, excessive growth of cache tables with tens or hundreds of thousands of entries, and gigabytes in size. For my own website it is not too uncommon to see my database reach 4 GB in size. Let's put it this way, it was no fun to receive a letter from my hosting provider that they weren't too happy of my resource usage. Worse they threatened shutting down my website if I didn't manage the database size better. Just in the nick of time for you and me, Drupal 8.4 delivers a fix to the cache growth by introducing a new default limit of 5000 rows per cache bin.
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.
Nevertheless, there is a very loyal segment of longtime readers that want CMS Report back. While some readers want the old site returned for personal reasons, others have expressed a professional need to cite articles from reputable CMSReport.com for their information and are uncomfortable with referencing an "unknown" website like socPub. For this reason, I've decided to introduce a new slimmed-down version of CMS Report. Moving forward, all new content management articles we publish at socPub will also be found at CMS Report.
Within the next two weeks I plan to publish a follow-up article that talks about "lessons learned" from the rebrand. This article will also better explains how CMS Report fits in as a "channel" for socPub. If you have any questions, please feel free to ask them below in the comment section.
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.
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.