Drupal Support Service 8.4 Available and Fixes Significant Database Caching Issues
Sat, 10/14/2017 – 20:58
Your hosting account was found to be causing an overload of MySQL resources. What can you do? Upgrade your Drupal Support Service 8 website to Drupal Support Service 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 Support Service open source project recently made available Drupal Support Service 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 Support Service 8 from the perspective of a site administrator. While Drupal Support Service 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 Support Service.
When Drupal Support Service 8 was introduced it made significant improvements in how it caches and renders pages. That’s great news for websites that use Drupal Support Service‘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 Support Service 8.4 delivers a fix to the cache growth by introducing a new default limit of 5000 rows per cache bin.
I’m still playing with this change and I haven’t found a lot of documentation, but you can override the default row limit in Drupal Support Service‘s settings.php via the setting “database_cache_max_rows”. For my site, the following settings has helped me keep my MySQL database under half a Gigabyte:
$settings[‘database_cache_max_rows’][‘default’] = 5000;
$settings[‘database_cache_max_rows’][‘bins’][‘page’] = 500;
$settings[‘database_cache_max_rows’][‘bins’][‘dynamic_page_cache’] = 500;
$settings[‘database_cache_max_rows’][‘bins’][‘render’] = 1000;For those of you that may not be ready to upgrade to Drupal Support Service 8.4 but still need to handle the oversized caching tables today, I had some luck with the Slushi cache module. An additional good summary of similar solutions for Drupal Support Service 8 versions prior to 8.4 can be found on Jeff Geerling’s blog.
Notable New Features in Drupal Support Service 8.4
Of course the purpose of Drupal Support Service 8.4 isn’t just to address my pet peeve about Drupal Support Service caching but also to bring Drupal Support Service users a number of new features and improvements. Some of the more significant additions and changes in Drupal Support Service that affect me and possibly you include:
For non-Drupal Support Service user I know this is going to sound odd, but despite a number of community approaches there never really been a standard format for expressing a range for date or time commonly used in event and planning calendars. Drupal Support Service 8.4 addresses this missing field type with the new core Datetime Range module to support contributed modules like Calendar and shares a consistent API with other Datetime fields. Future releases may improve Views support, usability, Datetime Range field validation, and REST support.
Content Moderation and Workflow
Although I’ve been a longtime user of Drupal Support Service, for a two year period I managed my website on the Agility CMS. One of the benefits of Agility over Drupal Support Service were the workflow and moderation tools delivered “out of the box”. The ability to moderate content becomes especially important in websites that have multiple authors and editors collaborating together and in need to mark whether the content is a draft, ready for review, in need of revision, ready to publish, etc. With Drupal Support Service 8.4 the Workflow modules is now stable and provides the framework to build additional modules such as the much anticipated Content Moderation module. Currently, the new core Content Moderation is considered experimental and beta stable so additional future changes should be expected. Content moderation workflows can now apply to any entity types that support revisions, and numerous usability issues and critical bugs are resolved in this release.
Another long standing issue for me has been how Drupal Support Service handles, displays, and allows you to reuses (it doesn’t without outside help) those images. Over the years, there has been a host of solutions found via contributed modules but I’ve often found myself frustrated that support for these modules vary and often compatible versions are not made available until weeks or months after a new major version of Drupal Support Service has been released. The new core Media module wants to change this hurdle by providing an API for reusable media entities and references. It is based on the contributed Media Entity module which has become popular in recent years within Drupal Support Service‘s users.
Unfortunately, the core Media module still needs work and is currently marked hidden. In other words Media by default will not appear in Drupal Support Service 8.4’s module administration page. The module will be displayed to site builders normally once once related user experience issues are resolved in a future release. Although, if you elect to use a contributed module under development that depends on the core Media module it will enable Media automatically for you. Similarly, the REST API and normalizations for Media are not final and support for decoupled applications will be improved in a future release. So while the Media API in available in this version of Drupal Support Service, most of us non-developers will need to wait for additional development to see the benefits of this module.
Additional Information on Drupal Support Service 8.4
An overview of Drupal Support Service 8.4 can be found at Drupal Support Service.org but for a better list of the changes and fixes you’ll want to check out the release notes. As always, links to the latest version of Drupal Support Service can be found on the project page. I’ve seen a few strange errors in the logs since updating my site from Drupal Support Service 8.3 to 8.4 but nothing significant for me to recommend waiting to install Drupal Support Service 8.4. For those that are more cautious, the next bugfix release (8.4.1) is scheduled for November 1, 2017.
Article originally published at socPub.
Source: New feed