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.
Last week, I received an email inviting me to take a sneak peak at a press release that became public today. In the email, I was asked if I would be interested in hearing "news from new open source startup, DRUD Tech, founded by a couple of long-time Drupal contributors". According to the email, the company has been in "stealth mode" quietly working on their new product which is ready for launch this week. Given that I'm a long time fan of the Drupal content management system of course I said yes.
The new product is ddev (pronounced Dee-Dev) Community which is an open source solution intended to automate a number of web development tasks that frustratingly takes too much time and resources to manually accomplish. Having already mentioned Drupal, I should probably also mention that this toolkit is also intended for other CMSs including open source favorite WordPress. I've attached below a copy of the latest version of the press release I received. I also did a little digging around DRUD's website and found a video I placed under the press release which shows off some of the features in an earlier version of ddev.
DRUD Tech Releases ddev Community, the Premier Open Source Toolkit to Simplify End-to-End Web Development Processes
The new enterprise-grade, open source solution automates local web development processes to deliver unmatched cost and labor efficiencies
Denver, Colorado – September 19, 2017 – DRUD Tech, provider of open source development tools that automate workflows and web application development with popular CMSes including Drupal and WordPress, today announced the release of ddev Community. Web developers can download ddev Community today at https://github.com/drud.
Sometimes I get too nostalgic over computers or software that I once used in my daily life. I remember my first computer (the Commodore Vic-20), I remember my first programming language (BASIC), and I remember my first spam filtering software for user generated content (Akismet). But nine years ago, a new spam filtering service originally intended for Drupal called Mollom emerged and I quickly forgot about the other spam blocking software.
I was first introduced to Mollom by Dries Buytaert via an invitation to beta test the service on my websites. After installing Mollom, the amount of time I spent moderating anonymous comments for potential spam was significantly reduced. In less than three years, Mollom had blocked more than 100,000 pieces of spam on one of my websites. Along the way, Mollom was acquired by Acquia and would record blocking over 13.5 billion spam comments worldwide since its inception.
It was a good run for Mollom but unfortunately the end is near. An end-of-life announcement has been placed on the Mollom website notifying users that Acquia will no longer be supporting the service after April 2, 2018.
As of 2 April 2018, Acquia will no longer actively support or maintain Mollom. After that point in time, the Mollom service will no longer be available. If you still have the Mollom module enabled on your site at that point, either all comments will be approved or all comments will be denied depending on how you have the Mollom module configured . We suggest disabling the Mollom module in advance of the end-of-life date.
As was mentioned earlier this week, today is the day Drupal 8 becomes official and is released for public consumption. The last time CMS Report was given the opportunity to talk about a major Drupal release was in January 2011 with the release of Drupal 7. If you thought the three year waiting period from Drupal 6 to Drupal 7 was long, waiting nearly half a decade for Drupal 8 certainly feels like a lifetime in the world of content management. During this cycle of development, Drupal's own open source community has evolved and its developers have introduced hundreds of changes into the Drupal content management platform.
Since the release of Drupal 7, the Drupal community considered not only how they could influence the content management industry, but has also looked outward to consider how the best practices of developers, designers, and publishers could influence Drupal's own to build a better Drupal. Dries Buytaert, founder and project lead of Drupal, in a blog post remarked that "Drupal 8 has been a big transformation" for the open source community.
The pace of change in the digital world has become dizzying. If we were to ignore these market forces, Drupal would be caught flat-footed and quickly become irrelevant.
I admit it. When looking at the calendar my eyes have been focused on November 19, 2015. This is the date that Drupal 8, under development since 2011, is expected to be released. But for Drupal 6 users, the beginning of Drupal 8 also marks the beginning of the end for Drupal 6 support. Announced on Drupal.org, Michael Hess writes that Drupal 6 will reach end-of-life on February 24 2016.
As announced in the Drupal 6 extended support policy, 3 months after Drupal 8 comes out, Drupal 6 will be end-of-life (EOL).
On February 24th 2016, Drupal 6 will reach end of life and no longer be supported.
What this means for you:
- Drupal 6 will no longer be supported by the community at large. The community at large will no longer be creating new projects, fixing bugs in existing projects, writing documentation, etc. around Drupal 6.
- There will be no more core commits on Drupal 6.x to the official tree. (see What if I have a Drupal 6 site still)
- The security team will no longer provide support or Security Advisories for Drupal 6
All Drupal 6 releases on project pages will be flagged as not supported.
- At some point in the future update status may stop working for Drupal 6 sites.
The policy of the Drupal community is to support only the current and previous stable versions. (When Drupal 8 is released, Drupal 7 will continue to be maintained but Drupal 6 be marked unsupported.) This policy was created to prevent Drupal's core and module maintainers from having to maintain more than two active major versions of Drupal.
On March 24, 2015, the Drupal community lost Aaron Winborn who was diagnosed with ALS a few years ago. In honor of Aaron, the Drupal Association and Angie Bryon recently announced the Aaron Winborn Award. The announcement reads as is:
Announcing The Aaron Winborn Award to honor amazing community members
In honor of long-time Drupal contributor Aaron Winborn (see his recent Community Spotlight), whose battle with Amyotrophic lateral sclerosis (ALS) (also referred to as Lou Gehrig's Disease) is coming to an end later today, the Community Working Group, with the support of the Drupal Association, would like to announce the establishment of the Aaron Winborn Award.
This will be an annual award recognizing an individual who demonstrates personal integrity, kindness, and above-and-beyond commitment to the Drupal community. It will include a scholarship and stipend to attend DrupalCon and recognition in a plenary session at the event. Part of the award will also be donated to the special needs trust to support Aaron's family on an annual basis.
Thanks to Hans Riemenschneider for the suggestion, and the Drupal Association executive board for approving this idea and budget so quickly. We feel this award is a fitting honor to someone who gave so much to Drupal both on a technical and personal level.
Thank you so much to Aaron for sharing your personal journey with all of us. It’s been a long journey, and a difficult one. You and your family are all in our thoughts.
When I talk about Drupal, information technology and the weather all in the same breath, I get a little excited. I can't help myself. I'm biased toward Drupal as it is one of my favorite content management systems. I'm also a former meteorologist working in information technology for a very large organization that is heavily involved with the weather. Needless to say, a year or two ago when I heard that The Weather Channel started using Drupal to meet the needs of it's customers and meteorologists, it caught my attention. I think the use of Drupal is a win-win for everyone around and given my background, I wish my own employer had adopted a similar solution. I think organizations miss out on a lot when they don't utilize open source or even proprietary systems in favor of an in-house CMS.
The news keeps getting better if you're a Drupal fan. Last month, both Acquia and Mediacurrent announced that The Weather Channel is standardizing on the Acquia Platform for Weather.com. Weather.com started using Drupal last year to increase the agility of its content creation and publishing. Now, the company has moved the entire website, which serves more than 20 million pages of content, to the Acquia Platform, which brings together Drupal and Acquia’s solutions for digital engagement and experience management. The team at Weather.com worked with Acquia and digital agency partner Mediacurrent for its site development and migration from its legacy web content management system Percussion.
For the first time in 15 years, my family doesn't have a website to call their own. In January 2000, I registered the domain Bryansplace.com. This was the first website I ever built outside of work and it became a sandbox for me to express my interests as well as a way to seek personal growth. From handwritten HTML pages into Frontpage to a number of CMSs, the software and content at Bryansplace evolved as my life evolved.
Bryansplace.com was the website where my girlfriend and I announced our marriage to the world. As a married couple, we eventually publicly announced the birth of our son via the site. This domain was the site where I talked about camping, computers, and my latest beer recipes. It wasn't all about me either. My wife showcased her photography for the first time online via Bryansplace. This was also the website my son learned how to navigate the Drupal content management system and talk about his gaming skills. Bryansplace.com was synonymous with "family news". Despite how much I valued the domain, last week I unceremoniously killed the website.
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).
Well, this certainly wasn't on my radar. Gábor Hojtsy, Drupal 6 lead maintainer, announced that starting March 1, 2014 support for PHP 4 in Drupal 6 will end. I wasn't surprise to hear about Drupal developers dropping support for PHP 4. Instead, I was in shock to hear that Drupal didn't drop support for this ancient version of PHP sooner.
To put this announcement in perspective, the PHP project developers said their goodbyes to PHP 4 back in 2008 and I personally said my "see ya later" back in 2007. Needless to say, I don't think anyone with merit can complain Drupal is dropping PHP 4 support. In Gábor Hojtsy's words:
Drupal 6.0 was released almost 6 years ago in February 2008. The Drupal community is committed to release Drupal 6 bugfixes until Drupal 8.0 is released and with recent changes provide security fixes much longer.
The hosting and development landscape was very different in 2008 though. PHP has gone a long way since we released Drupal 6. While Drupal 6 is still supported on PHP 4.x, the PHP developer community itself end-of-lifed PHP 4 just half a year after Drupal 6.0 came out. According to public statistics and data available to us about Drupal 6 sites, we estimate that there is a very small number of Drupal sites which may still run on PHP 4. We also don't believe it is in our best interest to support Drupal 6 on a possibly insecure but definitely unsupported base system, so we discussed and decided to drop support for PHP 4 on March 1st 2014.
Typically, Drupal has dropped support for an older versions of Drupal when a new version of Drupal is released. The expectation was Drupal 6 support would be dropped when Drupal 8 becomes an official release. I suspect the delay in dropping Drupal 6 support is postponed partially due to a change in Drupal 8's new site migration approach. There is a new workflow for site migration that has the potential for site owners to migrate their content not only from Drupal 7 to Drupal 8 but also allow Drupal 6 sites to migrate directly into Drupal 8. Until the new migration approach is proven, it is in everyone's interest to continue support for secure Drupal 6 sites. For the "secure" mandate to be supportable no website should be running on PHP 4.