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.
Over the years, I've made it an unwritten policy not to sensationalize bug fixes and security vulnerabilities in content management systems. While there may be great interest in such stories, I believe such stories have a tendency to cause more harm than good. When sensationalized, such articles tend to cause customers to address security concerns with emotion instead of logic which is never a good thing. So, when the security vulnerability known as "Drupageddon" broke and Drupal developer Bevan Rudge posted "Your Drupal website has a backdoor", I knew this story was going to eventually reach mainstream media. In the meantime, I've been struggling on how best to write this article and what story need to be told.
For those that don't know, Drupageddon is the highly critical SQL injection vulnerability in Drupal 7 core and was fully disclosed by the Drupal Security Team in SA-CORE-2014-005. Since the dawn of time when databases were introduced to websites, SQL injection vulnerabilities have been discovered and in the majority of cases when found are patched by their developers and system administrators. What makes Drupageddon particularly nasty is the vulnerability can be exploited by users not even logged into your site (in Drupal they're called anonymous users). Worse, if you didn't update your site quickly enough, your site may still be compromised even after applying the fix (in Drupal 7.32 or later versions).
While Drupal 8 has been been under development for two and a half years, I haven't talked much about it. I learned long ago that it doesn't do much good to talk about an upcoming release of a CMS until the software crosses over from what most of us would consider "vaporware."
The software needs to be close to beta, allowing for normal folks to actually be able install for testing purposes with a reasonable amount of certainty we don't need to be a developer. If you're a loyal reader of Planet Drupal, by now you should be getting a sense that the time has come to finally talk about Drupal 8.
There are a great number of changes coming with Drupal 8. So many, that I'm bound not to understand them all at this point. However, if you take a look at the core initiatives you can see where the core developers are working their hardest in improving Drupal 8.
Some of the great things planned for Drupal 8 include better HTML5 and mobile support, improved multilingual features, and setting up Drupal 8 on a modern web development framework (Symfony). Additional focus includes configuration management improvements and support for Views in the Drupal 8 core. While there is still work to be done, the core developers are starting to see the finish line in their sight.
Sitting on my desktop the past few weeks has been an eBook from the Aluent Group, Drupal and Joomla!: A Comparison of Project Processes and Costs. I probably would have not read this eBook if it wasn't for an acquaintance of mine, Justin Kerr, letting me know that he was a co-author of the book. I'm lucky to have read the book because I think Justin Kerr as well as co-authors Robert Nowak and Jet Pixel have hit a home run in their review and comparison of Drupal and Joomla.
Writing a comparison of any two content management systems can be challenging. This is especially true when the CMSs in the comparison are open source and each CMS has a legion of followers ready to pounce on anything you write that they perceive as false. For the reviewer, there is probably no better two open source CMSs to compare that can provide so much reward or risk than Drupal and Joomla. If you're lucky, have your facts in order, and the mood is just right then you too can take the Internet by storm just like I did in 2006. Don't do your homework and you will fail a miserable writers death.
I do not know when it exactly happened, but a number of years ago I decided to become a pacifist. I am a pacifist that is in the war of open source versus proprietary. In my opinion, the debate over licensing and software development processes is only mildly interesting as it is the quality of the end product that matters to me most. I walk the fine line of being an advocate for open source and a defender of proprietary software. Admittedly I've confused a lot of people that have chosen to take sides in this war. However, there is always room for reasonable civil discussions of any topic when new data and new perspective is given. This is perhaps why within the past week I enjoyed reading a commissioned study conducted by Forrester Consulting on behalf of Acquia that shows the value of open source without necessarily attacking the value of proprietary software.
The independent study conducted by Forrester is titled “Is It Time To Consider Open Source WCM For Digital Experience?”. Given that the study is being promoted by Acquia, an open source Drupal company, it shouldn't be surprising to you that this paper highlights the benefits of open source web content management systems (WCM). However, the author of the paper does this in way that that doesn't also dismiss the value of proprietary systems. This paper is an invitation with business reasons given for IT shops that for one reason or another remain proprietary to start considering using open source solutions. That soft sell in my opinion will win over more customers than the doomsday ideologies we often hear from both open source and proprietary proponents.
Two years ago I began a process to consider how best to evolve CMSReport.com beyond where it is today. I've known for some time that I needed to take some risks, get out of my comfort zone, and perhaps change how I maintain and run the site. Given the opportunity and in the spirit of taking risks I've decided to no longer run CMS Report on Drupal. That's right, after running this site on Drupal for more than six years on Drupal I've decided to use another content management system.
For those that don't want to be left hanging, I mention the CMS I've chosen to run the upgraded site on toward the end of this article. In a separate article I'll get into the specifics for why I decided on this other CMS and discuss the strengths and weaknesses of both information systems.
My primary objective with this post isn't to talk about another CMS, but instead to focus on Drupal and reflect on how much I owe a debt of gratitude to the Drupal community. I also want to make it clear that my decision to use another CMS is not a reflection of my opinions regarding Drupal. On the contrary, I have a number of past and future projects where Drupal remains the solution for my content management needs.
Although, I like to consider myself unbiased when I blog about content management systems, it is no secret that Drupal holds a special place in my heart. Drupal was one of the first CMSs I used that didn't "dead-end" me on a project I was required to support. Over the years, the Drupal community has treated me well, even during those times when I was very wrong in my judgment of Drupal. If Drupal was not a part of my world, I'm not sure I would even be blogging about content management systems. Drupal is the open source standard for which I judge other CMSs.
So, it should come to no surprise to anyone that when John Coonen inquired if I would moderate a Drupal in the Clouds panel at CMS Expo, I jumped at the opportunity. I am excited about the high caliber people that will be on this Drupal in the Cloud panel. The panelists include Joni Klippert from Standing Cloud, Kieran Lal from Acquia, and Jeff Walpole from Phase2 Technology. If you're trying to figure out what is involved in getting your Drupal site, services, and support to the Cloud, these are the people you want to have in the room answering your questions.
As I mentioned in a previous post, I'm currently playing catch-up in discussing all the good books sent my way this past year. Many of the books have been sent by the authors and publishers themselves for review and some of the books I've bought on my own dime. There should be no further evidence that I'm a procrastinator in posting book reviews than this particular review of Todd Tomlinson and John K. Vandyke's Pro Drupal 7 Development. This book was published almost a year ago, and I'm only now finding the time to blog about this book.
While it has been close to a year since this book was published (about just as long since Drupal 7 was released), I marvel how relevant Pro Drupal 7 Development remains as a valuable resource to me. This book and its previous versions have saved my hide so many times that I have lost count. This book may have been sitting on my desk for a year but I assure you it hasn't been collecting dust.
A couple weeks ago my family spent some vacation time at Disney World in Orlando, Florida. If you have ever been to a Disney theme park then you know full well that it takes a lot of work in those parks just to have fun. Some of the most popular rides in these parks have waiting periods of up to two hours due to the long lines of people wanting to get on board. Luckily, my wife brought a Disney tourist guidebook that gave our family the helpful hints, recommendations, and information we needed to beat those long lines. In the end, we ended up with a very enjoyable trip (so enjoyable that we got to ride Space Mountain twice!). That travel guide was a valuable asset to my family's vacation.
Mastering Drupal is very similar to visiting a theme park as it takes some effort on your part to ensure you get rewarded for your effort. If Drupal is the amusement park then consider Drupal's modules as the park's attractions you're wanting to ride. With this line of thinking, I easily recommend that you let Earl and Lynette Miles' book, Drupal's Building Blocks, be your valuable tourist guide into the wonderful world of Drupal. I only review a few books each year and this is a book I gladly invested my time reading.
Drupal's Building Blocks is a tutorial, reference, and cookbook for some of Drupal's most valuable modules including CCK (Content Construction Kit), Views, and Panels. The primary purpose of this book is to give you the quickest route to mastering the modules as quickly as you can in order to help you create more powerful, flexible, usable, and manageable Web sites. The audience for this book isn't only for Web developers or designers, but also site administrators, content architects, and consultants. There is some code in this book, but what is there isn't the scary code you often find in a developer's library.
Although I've worked with Drupal for more than half a decade, I am still among the newbies who struggle with how best to use Drupal's contributed modules. I've built several sites using CCK and Views but I've always ran into hurdles that keep me from fully discovering what these modules can do for me and my sites. This book will provide you the information you need to realize the full potential of these modules. Anybody who has seen Drupal, CCK, Views, and Panels mature over the years can't help but read this book and enjoy not only the author's technical expertise but also the author's cultural and historical understanding for how the module came to be in Drupal.
In the first chapter of the book, "Introducing CCK and Nodes", there is a section titled "Quest for the Grail: How CCK Was Born". This section alone reads like an adventure story that starts by talking about the challenges site administrators originally had with Drupal needing to acquire development skills just to control the form content would take in Drupal. The story continues with Drupal 4.4 and how a contributed module named Flexinode gave non-developers the ability to create new content types yet limitations remained. I was reminded that with Drupal 4.7 CCK became Flexinode's replacement and with each successive release of Drupal the module continues to improve. For someone like me who started with Drupal 4.6 and watched Drupal 5, 6, and now 7 evolve this book spoke to my inner geek. I simply found this book to be good bridge to the more technical aspects of CCK, Views and Panels.
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.